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 .
Notice to Applicant
The following is a Final Office action. In response to Examiner’s Non-Final Rejection of 5/13/25, Applicant, on 8/6/25, amended claims. Claims 1-3, 5-10, 12-17, 19-21 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
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 a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
“A method comprising:
receiving user input including a selection of a source backlog from a set of backlogs;
identifying, based on the user input, user account data associated with a user account, the user account data including one or more of a user's security clearance, profession, job title, and division of an enterprise;
determining a subset of target backlogs from the set of backlogs through operations comprising:
comparing the user account data to metadata labels for each backlog of the set of backlogs, wherein the metadata labels include requirements indicating an authority of the user account to access each backlog of the set of backlogs;
responsive to determining the user account data matches the requirements of a matching backlog of the set of backlogs, adding the matching backlog to the subset of target backlogs;
receiving a selection of a target backlog from the subset of target backlogs;
generating a list of tasks from the selected source backlog;
receiving a selection of a task; and
cloning the task to the target backlog and editing the target backlog metadata labels to indicate the task has been cloned to the target backlog.”
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity” (“managing personal behavior (including social activities, teaching, and following rules or instructions)) as here we have creating receiving a selection of a source backlog (that has tasks), identifying a user account (e.g. job title, division/workgroup of person), determining a subset of target backlogs, comparing user account data (e.g. job title/workgroups) for user account to be able to access each backlog of tasks, and if allowed adding matching backlog of tasks, and then manually selecting one as “target”, generating tasks from the source backlog, selecting a task, and cloning/copying the task to the “target” backlog (e.g. a list of tasks for people to perform), and indicating the task was copied/cloned. Accordingly, claim 1 is directed to an abstract idea because it is a process for following rules for a user for copying tasks from one list/backlog to a second/target list/backlog.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. In particular, the claim 1 does not recite any additional elements at this time; at most we have “user input”, but no explicit computer. As an initial starting point, Examiner suggests Applicant recite a “computer”, though this alone won’t make the claim eligible. It will move prosecution forward at least. A “computer” or “user input” is viewed as MPEP 2106.05f applies – each limitation in claim involves a computer and is considered “apply it” – applying the abstract idea on a computer).
Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. See 84 Fed. Reg. 55. The claim is directed to an abstract idea.
Step 2B in MPEP 2106.05 - As discussed above with respect to integration of the abstract idea into a practical application, even once a “computer” is added, the additional elements of a computer are MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235).
Independent claim 8 is a “system” which is a statutory category at step 1. It is directed to an abstract idea for the same reasons as claim 1. It recites “one or more processors configured to” which at step 2a, prong 2 and step 2B is considered “apply it [abstract idea] on a computer” (MPEP 2106.05f), for reasons outlined above.
Independent claim 15 is an “article of manufacture” which is a statutory category at step 1. It is directed to an abstract idea for the same reasons as claim 1 and claim 8. It recites “A non-transitory computer readable medium comprising instructions that when executed by one or more processors cause the one or more processors to” which at step 2a, prong 2 and step 2B is considered “apply it [abstract idea] on a computer” (MPEP 2106.05f), for the same reasons as outlined above.
Claims 2, 9, and 16 narrow the abstract idea by having a metadata label giving meaning to a human user.
Claims 3, 10, and 17 narrow the abstract idea by dividing tasks into subtasks for users to select/add/exclude others from/edit.
Claims 5, 12, and 19 narrow the abstract idea by giving details on label for significant to a human reader – user that cloned it, when/timestamp, and backlog/list task came from.
Claims 6, 13, and 20 narrow the abstract idea by recommending backlogs based on considering search history and user account. This is also considered a mathematical relationship – as it can match/score similarity between search strings/words [see Applicant’s [0038-0040] as published] and a backlog/list of tasks.
Claims 7 and 14 narrow the abstract idea by generating a report based on a label that includes things to help a user (guide/description/notes). Having a “hyperlink” available is considered an additional element and at step 2a, prong two and step 2B is considered “apply it [abstract idea] on a computer” (MPEP 2106.05f) and “field of use” (MPEP 2106.05h). At step 2B, it is also considered a conventional computer function (MPEP 2106.0d(II) “ i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321.”)
Claim 21 narrows the abstract idea by creating a relationship between task and cloned task and tracking progress of tasks.
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-6, 8-9, 11-13, 15, and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Bar-on (US 2020/0210934) and Hamid (US 2014/0236649).
Concerning independent claim 1, Bar-on discloses:
A method (Bar-on – See par 14 - Some example embodiments are directed to a computer-implemented method of operating an issue tracking system on a host service that is in communication with multiple client devices over a computer network.) comprising:
receiving user input including a selection of a source backlog from … backlogs (Bar-On – See par 29 -An issue request system may be a hosted service that is specially configured to monitor and track various tasks and progress of software development tasks that are assigned to a development team or a project group. See FIG. 2A, par 48 - In one example embodiment, the issue tracking system 100 is configured for use by two software development teams (that can access the issue tracking system 100 from separate client devices) supporting two separate code bases that correspond to two separate software products executable on two separate computing or processing platforms; See par 58 - In response to the foregoing determinations that the Apple iOS® software development team is opening issues that are substantially similar in both content and categorization to issues previously opened by the Google Android® software development team, the issue tracking system 100 can suggest to the Apple iOS® software development team to duplicate the other related issues already opened by the Google Android® software development team…. Thereafter, one or more of the seed issues in the ranked set of seed issues can be used by the issue tracking system 100 to suggest one or more issue requests to the members of the Apple iOS® software development team to initiate the creation of one or more new relevant issues).
Bar-on makes “suggestions” to a user to “duplicate” a related issue (See par 48, 58). However, it is unclear if Bar-on discloses selecting “from a set of backlogs” as recited.
Hamid discloses:
receiving user input including a selection of a source backlog from “a set of” backlogs (Hamid – see par 205-207, 215 - In this example, if a user wants to copy and move something, the first step is to determine if the user is permitted to do so; The View Issue page is refreshed and the user sees the issue, e.g. in an issue bundle, and the issue can be moved or copied, for example via a drag-and-drop user interface tool.)
Bar-on and Hamid disclose:
identifying, based on the user input, user account data associated with a user account, the user account data including one or more of a user's security clearance, profession, job title, and division of an enterprise (Bar-On – see par 31 - An issue tracking system, as described herein, may increase the efficiency of a team of individuals working on a common goal or project by facilitating the organization of the assignment of discrete items of work to the individual or team of individuals most suited to perform that work (disclosing a division of an enterprise).
Hamid – see par 206 - Another embodiment of the invention allows a user to copy issues from one issue tracking system site to another. In this embodiment of the invention, once an application link is established (see the discussion below) between the local issue tracking system site and another, a new issue action, Remote Copy, appears in a view issue page. The user can limit this action to a particular user group);
determining a subset of target backlogs from the set of backlogs through operations (Bar-on – See par 58 – the issue tracking system 100 can suggest to the Apple iOS® software development team to duplicate the other related issues already opened by the Google Android® software development team which as noted above may include, but may not be limited to, issues related to: data fetching; data parsing; data validation; persistence layer implementation; documentation updates; and so on.. By way of example, the issue tracking system 100 may identify one or more seed issue records that are associated with a group or cluster related to the Google Android® software development team that also satisfy a similarity score with an issue record associated with a group or cluster related to the Apple iOS® software development team. Using the seed issue record, the issue tracking system 100 may suggest an issue request to the members of the Apple iOS® software development team to initiate the creation of a new relevant issue;
See also Hamid – par 216, FIG. 3 - Once a user has authenticated with the remote instance, the user must first choose the destination project for the issue to be copied and/or moved. It is the issue type and/or project combination that allows the destination issue tracking system instance to describe its requirements fully for successful issue creation to the source issue tracking system instance) comprising:
comparing the user account data to metadata labels for each backlog of the set of backlogs… (Bar-On – see par 46 - the issue tracking system 100 can be configured to track issues reported in other projects having similar or identical tags, groups, or categorizations (e.g., different groups having a similarity score exceeding a threshold). Upon recognizing a pattern of issue reporting in the first project (e.g., a first issue report typically precedes a second and third issue report, each having a particular categorization or tag), the issue tracking system 100 can provide suggestions for issue reporting to a user of a second project that reports an issue in the second project in a manner that matches or corresponds to the previously-detected pattern. see par 48 - the issue tracking system 100 is configured for use by two software development teams (that can access the issue tracking system 100 from separate client devices).
Bar-On discloses teams can “have access” to an issue tracking system (See par 48).
Hamid discloses:
comparing the user account data to metadata labels for each backlog of the set of backlogs “wherein the metadata labels include requirements indicating an authority of the user account to access each backlog of the set of backlogs” (Hamid – see par 192 - custom rendering plugins can also make permissioning and security decisions, i.e. when they contact the remote system, they can use the user context to decide what amount of information should be rendered. If, for example, the current JIRA user does not have permission to see the remote object or page, the custom renderer can choose to display information which indicates that the user does not have permissions. See par 215 - If the user is set up as trusted, then the user never notices anything because he has permission to proceed immediately. If the user is set up on an OAuth system, then there is human intervention where the user, while in one instance, gives himself permission to act as himself on the other instance. Once this is done, the system looks at what is being copied).
Bar-on and Hamid disclose:
responsive to determining the user account data matches the requirements of a matching backlog of the set of backlogs, adding the matching backlog to the subset of target backlogs (Bar-On – see par 47 - the duplicable issue detection server 110 may be configured to analyze previously created issue records stored in one or more repository servers 108 and initiate suggested issues that may be transmitted back to one or more client devices 104. See par 55 - In this example, one or more users associated with the software development team working on the Google Android® mapping application may report or open a series of issues in the issue tracking system 100 related to integration with a third-party point(s) of interest API; In response, the host service 102 (including the issue tracking server 106 and duplicable issue detection server 110) may associate each of the series of incoming issue requests with a cluster or group that corresponds to a classification related to the Google Android® software development team. In some cases, the series of incoming issue requests may be further clustered or grouped based on sub-classifications related to one of sub-teams, labels, epics, linked user stories, or other groupings of related issues; Based on similar categorization, inter-issue linking, and/or the sequence or succession in which these issues were opened, the issue tracking system 100 can determine that the actions taken by the Google Android® software development team constitute a pattern that can be used to suggest similar issues to a separate or distinct software development team or group;
Hamid – see par 192 - custom rendering plugins can also make permissioning and security decisions, i.e. when they contact the remote system, they can use the user context to decide what amount of information should be rendered. If, for example, the current JIRA user does not have permission to see the remote object or page, the custom renderer can choose to display information which indicates that the user does not have permissions. See par 216 - Once a user has authenticated with the remote instance, the user must first choose the destination project for the issue to be copied and/or moved. The local instance receives the requirements from the remote instance and then, as the instance is trying to copy and/or move an issue, provides information back to the user: "successful," "need more information," "just not possible; you don't have permission.");
receiving a selection of a target backlog from the subset of target backlogs (Bar-on – See par 38 - In some cases, the dynamic threshold may be adjusted or modified based on prior user activity including, for example, acceptance of previously suggested issues. see par 58 - a user known to regularly accept recommendations of the issue tracking system 100 can be shown a higher number of issue request suggestions than a user known to typically reject recommendations of the issue tracking system;
See also Hamid – par 216, FIG. 3 - Once a user has authenticated with the remote instance, the user must first choose the destination project for the issue to be copied and/or moved. It is the issue type and/or project combination that allows the destination issue tracking system instance to describe its requirements fully for successful issue creation to the source issue tracking system instance; see par 217 - One of the first steps when trying to perform a remote copy is to pick a destination for that issue in the remote instance, both in terms of the project and issue type.);
generating a list of tasks from the selected source backlog (Bar-on – See par 31 - Example “issues” can relate to, without limitation: a task to identify the cause of a software bug; a task to perform a feasibility assessment for implementation of a new feature; a task to fix an identified software bug; and so on. See par 60 -e. In these examples, issues opened by the Apple iOS® software development team may be suggested to, and modified to suit, the Google Android® software development team and, additionally, issues opened by the Google Android® software development team may be suggested to, and modified to suit, the Apple iOS® software development team. In this manner, a comprehensive set of issues related to a particular task (e.g., having similar categorizations across different projects) can be reported to the issue tracking system 100, by both teams, in a substantially more time and resource efficient manner);
receiving a selection of a task (Bar-On – see par 97 - In many cases, the duplicable issue detection server 110 is further configured to determine similarity between issues reported in different projects (e.g., in order to determine, in one example, whether a previously detected pattern of issue reporting can be leveraged to provide one or more suggestions of additional issues; Examples include, but are not limited to: determining cosine distance or similarity of content of two or more issues; …; determining semantic similarity of text content of two or more issues; and the like. Example content of an issue that can be compared in the course of determining whether two issues are similar can include, but may not be limited to: issue description; issue summary; project name; issue type; a name or identity of a user who reported the issue; a name or identity of a user assigned to the issue… one or more labels, tags, or categories of the issue; See par 99 – determined similarity by issue detection sever 110; With such information, the duplicable issue detection server 110 can be leveraged by the issue tracking system 100 to provide one or more recommendations of issues to open. See par 131, FIG. 3 - As a result of this determination comparing issues in Project B and Project A…, the duplicable issue detection server 306 can recommend that the other two issues previously reported in Project A also be reported in Project B. In response, the user can operate the client application 308 (e.g., interact with a graphical user interface of the client application 308) to report the suggested issues to the issue tracking server 304.).; and
cloning the task to the target backlog and editing the target backlog metadata labels to indicate the task has been cloned to the target backlog (Bar-On - see par 59 - the issue tracking system 100 can modify the issues previously opened by the Google Android® software development team with content, phrasing, vocabulary, tagging, and/or taxonomy specific to, or otherwise associated with, the Apple iOS® software development team. For example, the issue tracking system 100 may substitute the categorization of “points of interest” used by the Google Android® software development team for “POI” as used by the Apple iOS® software development team. Similarly, the issue tracking system 100 may replace occurrences of terms in a description of an issue opened by the Google Android® software development team with terms specific to the Apple iOS® software development team (e.g., replacing occurrences of “JAVA” with “Swift,” replacing occurrences of “Android” with “iOS,” and so on; par 63 - In these examples, the issue tracking system 100 can be configured to maintain a queue of issues opened by the Apple iOS® software development team, each of which may be suggested to the Google Android® software development team. see par 67 - The system can leverage any detected patterns in issue reporting in particular projects or having particular categorizations to, among other actions, suggest and/or autonomously duplicate (with or without modification) issues in other projects or for the benefit of other users of the same or a different issue reporting system.); see par 69 - stem 100 may anticipate or predict that the user also intends to—or would otherwise be advised to—open another issue substantially similar to the second issue of this example. In response, the issue tracking system 100 can generate a suggestion and display or otherwise transmit that suggestion to a user of the issue reporting system to open another issue having properties and contents substantially similar to the second issue of the preceding example. see par 97 - the duplicable issue detection server 110 is further configured to determine similarity between issues reported in different projects (e.g., in order to determine, in one example, whether a previously detected pattern of issue reporting can be leveraged to provide one or more suggestions of additional issues); See par 131, FIG. 3 - the duplicable issue detection server 306 can be configured to compare the issue request 302, which is associated with a cluster of records designated as Project B, to previously reported issue requests, such as those associated with a cluster of records designated as Project A... In response, the user can operate the client application 308 (e.g., interact with a graphical user interface of the client application 308) to report the suggested issues to the issue tracking server 304 (see how after 306, there are now two issues in project B);
see also Hamid – See par 205-206 – Remote issue copying – copy issues from one issue tracking system site to another; par 207, FIG. 6; see par 219 - That is, when two issues are linked in a way that designates them to be copies, then actions taken on one issue can affect the copy of the issue in the remote instance. Note, this is not restricted to just two copies of an issue. Some example use cases include: [0220] Keeping comments in sync between the copies of the issue.).
Both Bar-on and Hamid are analogous art as they are directed to issue tracking systems and tasks for people/developers/teams (see Bar-on Abstract, par 3, par 61; Hamid Abstract, par 17). Bar-on makes “suggestions” to a user to “duplicate” a related issue (See par 48, 58). Bar-On discloses teams can “have access” to an issue tracking system (See par 48). Hamid improves upon Bar-on by disclosing that it can have copies of tasks, and users can “choose” what to select and can use a drag and drop user interface for source and destination projects (par 215-217) and to have permissioning for users for information they can see (See par 192) to allow copies of issues for local instances (See par 216). One of ordinary skill in the art would be motivated to further include allowing users to select from multiple projects/lists/backlogs and have permissioning and security to efficiently improve upon the presentation of suggested tasks for duplication in Bar-on.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the creating of recommending tasks of similarity for issue tracking to a second cluster in Bar-on to further allow users to select sources/destinations for copying issues as well as giving permissions to users as disclosed in Hamid, since the claimed invention is merely a combination of old elements, and in 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 and there is a reasonable expectation of success.
Concerning independent claim 8 Bar-on and Hamid disclose:
A system comprising: one or more processors configured to (Baron – See par 42-44, 84 - a processor; a memory; non-volatile storage; networking connections; and the like. As used herein, a processor of the host service 102 may refer one or more physical processors or processing units implemented on one or more physical computing system that, alone or together, can be configured to implement the functionality described herein):
The remaining limitations are the same as claim 1 above and are rejected for the same reasons. Obvious to combine Bar-on and Hamid for the same reasons as claim 1.
Concerning independent claim 15, Bar-on and Hamid disclose:
A non-transitory computer readable medium comprising instructions that when executed by one or more processors cause the one or more processors to (Baron – See par 42-44, 84 - a processor; a memory; non-volatile storage; networking connections; and the like. As used herein, a processor of the host service 102 may refer one or more physical processors or processing units implemented on one or more physical computing system that, alone or together, can be configured to implement the functionality described herein).
The remaining limitations are the same as claim 1 above and are rejected for the same reasons. Obvious to combine Bar-on and Hamid for the same reasons as claim 1.
Concerning claims 2, 9, and 16, Bar-on discloses:
The method of claim 1, wherein cloning includes adding a metadata label associated with the task to the target backlog (Bar-on – See par 71 - Example content of an issue (e.g., issue request and/or issue record) that can be compared in the course of determining whether two issues are similar can include, but may not be limited to: issue description; issue summary; project name; issue type; a name or identity of a user who reported the issue; a name or identity of a user assigned to the issue; a priority of the issue; one or more labels, tags, or categories of the issue; one or more linked issues; one or more epic links; one or more user story links; and the like.) and copying the task to a list of tasks of the target backlog (Bar-on – see par 75 - In this manner, and as a result of the defined causal relationship between reported issues, an issue related to adding a feature to a software development project reported by a user can trigger the issue tracking system 100 to anticipate or otherwise predict that the same user also intends to—or would otherwise be advised to—open another issue related to updating documentation for that software development project. Upon making such a determination, the issue tracking system 100 can provide a suggestion to that user to provide input to open a software documentation update issue; See par 131 - As a result of this determination, the duplicable issue detection server 306 can recommend that the other two issues previously reported in Project A also be reported in Project B. More specifically, the duplicable issue detection server 306 can send a signal to a client application 308 operated by the user suggesting two additional issues be reported).
Concerning claims 5, 12, and 19, Examiner first notes that the content of the metadata labels here have no functional relationship with the method in claim 5. See MPEP 2111.05 – “where the claim as a whole is directed to conveying a message or meaning to a human reader independent of the intended computer system, and/or the computer-readable medium merely serves as a support for information or data, no functional relationship exists” and is not entitled to patentable weight.
Nonetheless, for purposes of compact prosecution, art is still applied:
Bar-on discloses:
The method of claim 2, wherein the metadata label indicates that a task was cloned to a backlog, …, and the backlog from which the task was cloned (Bar-on – See par 129 - The issue request 302 can include content such as, but not limited to: a project name or identity (e.g., Project B); an issue type; a name or identity of a user reporting the issue; one or more categorizations or labels associated with the issue (disclosing “task cloned to a backlog); and so on)); See FIG. 3, par 131 - In the illustrated example, Project A is associated with three previously reported issues, one of which may be determined by the duplicable issue detection server 306 to be similar to the issue request 302. As a result of this determination, the duplicable issue detection server 306 can recommend that the other two issues previously reported in Project A (disclosing backlog from which task cloned also be reported in Project B) a user that cloned the task (Bar-on – See par 137; FIG. 3, 302 – “issue reporter” for issue; see also Hamid – see par 29 – FIG. 1 shows implementation in JIRA report for issue tracking; par 30 – Fields in FIG. 1 include… with par 36 statuses - [0047] Reporter (16): The person who entered the issue into the system; [0049] Watchers (18): The number shown in brackets indicates how many people who are watching this issue. ),
Bar-On discloses having various information for an issue (See FIG. 3, 302; see par 129, 131).
Hamid discloses:
when the task was cloned (Hamid – see par 30 – many fields in FIG. 1; see par 39 – versions for which issue is or was manifesting; see par 47 – Reporter – person who entered issue into system; par 49 – Watcher – people who are watching this issue; see par 51 - Created (20): The time and date on which this issue was entered into the issue tracking system).
Obvious to combine Bar-on and Hamid for the same reasons as claim 1.
Concerning claims 6, 13, and 20, Bar-on discloses:
The method of claim 1, further comprising:
generating a list of recommended backlogs, wherein the list of recommended backlogs is based on one or more of a backlog search history of the user and user account (Bar-on – See par 39 - The issue tracking system may use prior interactions to determine a likelihood that the user may benefit from a suggested issue and, in response, trigger the identification of a seed or similar issue record. See par 46 - Generally, the issue tracking system 100 can be configured to analyze issues in a particular project assigned a particular tag, cluster, group, or categorization for one or more patterns (collectively, herein, “categories” or “categorization”). Additionally, the issue tracking system 100 can be configured to track issues reported in other projects having similar or identical tags, groups, or categorizations (e.g., different groups having a similarity score exceeding a threshold). See par 57, 62 -In response to the Apple iOS® software development team requesting to open an issue related to authentication management, the issue tracking system 100 can compare that issue to other issues previously received by the issue tracking system 100. In this example, the issue tracking system 100 may determine that the authentication management issue opened by the Apple iOS® software development team is substantially similar to (e.g., satisfies a similarity criteria using similar terms and language, similar phrases, and so on) to an authentication management issue opened by the Google Android® software development team referenced above).
Concerning claim 21, Bar-on and Hamid disclose:
The method of claim 1, further comprising:
creating a relationship between the task and the cloned task (Hamid – see par 181 - When a link is created, globalId: can optionally be supplied, which is an identifier that uniquely identifies the remote application and the remote object within the remote system. This globally unique identifier can be used to update or delete existing links on an issue, title [in table publication] – “crazy customer support issue (RESOLVED)”; see par 218 - in embodiments of the invention a copy operation which copies an issue to a destination issue tracking system instance also establishes a remote issue link between both copies of the issue; see par 219 - Other embodiments of the inventive remote linking functionality disclosed herein include the notion of linking with intent. That is, when two issues are linked in a way that designates them to be copies, then actions taken on one issue can affect the copy of the issue in the remote instance.); and
tracking the progress of an implementation of the task (Bar-on – see par 85 - In addition, the issue tracking server 106 of the host service 102 can be configured to communicably couple to the client device 104 via the network 105 in order to exchange information with and/or receive input(s) from the client device 104 in the course of tracking and/or documenting progress of completion of one or more issues of one or more projects tracked by the issue tracking system 100;
see also Hamid - par 220 - keeping comments in sync between the copies of the issue; see par 221-222 - When one copy of an issue goes through a workflow transition, then other copies of the issue may go through the same transition or some equivalent transition. Thus, the status of the copies of an issue is kept in sync. [0222] When some change is made to an issue, then that change event is broadcast to all instances that have a copy of the issue).
Obvious to combine Bar-on and Hamid for the same reasons as claim 1. Bar-on discloses documenting progress of completion for issues of “one or more projects” (See par 85). Bar-on also discloses having duplicate issues (See par 67) and a causal relationship of a dependency between issue records (See par 68). Hamid improves upon Bar-on by disclosing having copies of issues and keeping statuses in sync even if versions are kept locally and remote.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bar-on (US 2020/0210934) and Hamid (US 2014/0236649) as applied to claims 1-2, 4-6, 8-9, 11-13, 15, and 18-21 above, and further in view of Frankel (US 2021/0326793).
Concerning claims 3, 10, and 17, Bar-on discloses having tasks associated with a software development project and “discrete tasks” (See par 30). Hamid discloses having tasks are part of a project and issue (See par 59-63).
Frankel discloses:
The method of claim 1, wherein one or more tasks from the list of tasks are divided into subtasks which a user may select, add, exclude from selection, or edit (Frankel – see par 100 – user can add a subtask ; can have task information including start date, user, assigned user, user status; see FIG. 10 – can add notes, comments to “subtask” in user interface as selected; in upper right is “Add Subtask”).
Bar-on, Hamid, and Frankel are analogous art as they are directed to issue tracking systems and tasks for people/developers/teams (see Bar-on Abstract, par 3, par 61; Hamid Abstract, par 17; Frankel Abstract, par 58 – Kanban board with team dashboards, tasks, projects; See FIG. 7 – can view backlog; par 99, FIG. 9 – backlog lane). Bar-on discloses having tasks associated with a software development project and “discrete tasks” (See par 30). Hamid discloses having tasks are part of a project and issue (See par 59-63). Frankel improves upon Bar-on and Hamid by disclosing having various selections for subtasks (See par 100, FIG. 10). One of ordinary skill in the art would be motivated to further include allowing users to select from multiple aspects for subtasks to efficiently improve upon the presentation of suggested tasks for duplication in Bar-on and the copying of tasks between different projects in Hamid.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the creating of recommending tasks of similarity for issue tracking to a second cluster in Bar-on to further allow users to select sources/destinations for copying issues as disclosed in Hamid, to further change information associated with subtasks as disclosed in Frankel, since the claimed invention is merely a combination of old elements, and in 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 and there is a reasonable expectation of success.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bar-on (US 2020/0210934) and Hamid (US 2014/0236649) as applied to claims 1-2, 4-6, 8-9, 11-13, 15, and 18-20 above, and further in view of Doan (US 2009/0276728).
Concerning claims 7, 14, this claim still does not provide functional relationship for the various items in claim 5 (e.g. user that cloned the task, when the task was cloned, etc). Instead, this claim states that “based on the metadata label” a report is generated. Nonetheless, art will be applied for compact prosecution purposes.
Bar-On discloses that issues relate to a “task to fix” a software bug (See par 31).
Hamid discloses “Users can search for a page within a separate application from an issue within the issue tracking system and add an issue link to that page. Thus, in an embodiment of the invention users can add an issue link from an issue tracking system issue to any Web page URL, such as a page of documentation, a technical note, or any other page on another Web site” (See par 89).
Doan discloses:
The method of claim 5, further comprising:
generating a report based on the metadata label, wherein the report includes one or more hyperlinks to one or more of a user guide, description, and user notes for performing the cloned task (Doan – see par 6-7 – service desk; ticket with issue to be addressed; system can accept problem keywords, and locate at least one solution to address issue/ticket; See par 9, 19 - A technician can then link this "captured solution" to one or more issues, problem types, assets, asset configurations, etc. via links and associations. see par 42 - The solution can be linked in a relational manner, possibly using a relational database to one or more types of queries or one or more tickets. A ticket that has a query describing a problem that has been solved can be archived. When it is determined that a new, unresolved ticket has similarities to an archived ticket, this new ticket can "subscribe" to, or be associated with, one or more archived tickets.
Bar-on, Hamid, and Doan are analogous art as they are directed to issue tracking systems and tasks for people/developers/teams (see Bar-on Abstract, par 3, par 61; Hamid Abstract, par 17; Doan Abstract, par 6-7). Bar-On discloses that issues relate to a “task to fix” a software bug (See par 31). Hamid discloses “users can add an issue link from an issue tracking system issue to any Web page URL, such as a page of documentation, a technical note, or any other page on another Web site” (See par 89).
Doan improves upon Bar-on and Hamid by disclosing having links for solutions for different problem types, issues that can be linked in a relational manner to issues/queries/tickets (See par 9, 19, 42). One of ordinary skill in the art would be motivated to further include links to solutions to issues to efficiently improve upon the goal of fixing a bug in Bar-on and the documentation/notes for an issue in Hamid.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the creating of recommending tasks of similarity for issue tracking to a second cluster in Bar-on to further allow users to select sources/destinations for copying issues as disclosed in Hamid, to further link to solutions that can be related to other queries/tickets/issues as disclosed in Doan, since the claimed invention is merely a combination of old elements, and in 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 and there is a reasonable expectation of success.
Response to Arguments
Applicant's arguments filed 8/6/25 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With regards to 101, Applicant argues the claim is eligible similar to the Bascom decision for being “significantly more” [2B] for how it filters content. Remarks, page 9. In response, Examiner respectfully disagrees. Bascom was eligible because “ the Federal Circuit concluded that the district court erred by failing to recognize that when combined, an inventive concept may be found in the non-conventional and non-generic arrangement of the additional elements, i.e., the installation of a filtering tool at a specific location, remote from the end-users, with customizable filtering features specific to each end user. 827 F.3d at 1350, 119 USPQ2d at 1242.” See MPEP 2106.05(I)(B), 2106.05f. There is not a similar situation here with details on technology for filtering.
Applicant then argues with regards to step 2A that the claims are not directed to an abstract idea because they are not directed to certain methods of organizing human activity and instead since the claims are directed to manipulating metadata to track user accounts and control access to backlogs. Remarks, page 9-10. In response, Examiner respectfully disagrees. The backlogs here are tasks for workers (people), the accounts can be the team/title of the workers. This is not a technological improvement of “natural language analysis” or “filtering at a specific location” in the manner of Bascom.
Applicant then argues with regards to step 2A, prong two that the claims are similar to the TecSec decision, reciting “object-oriented key manager, labeling the encrypted object, reading the object label, and how the application here improves security as well by use of the metadata labels for “controlling access” as in Applicant’s [0003, 0049]. Remarks, page 11-12. In response, Examiner respectfully disagrees. First, [0003] does not make any use of metadata a “practical application.” The claims here cover having tasks corresponding to the title or position of a group of workers. Second, claim 1 does not even require a computer. Third, portions of [0049] are not even required by the claims – there is no “authenticating.” Fourth, even if it states “authenticating”, it is unclear what technical aspect the improvement is referring to, as a manual process of having certain tasks for certain groups/titles of employees operates in the same manner, where often different workers will only work on “some” or a subset of tasks. Fifth, the TecSec decision states that it is “labelling files or messages or messages that are sent from a sending user to a receiving user over a network” is used “in addition to cryptographic protection” as well as discussion on multilevel security. See slip op. at page 26-27. Accordingly, TecSec does not appear to be similar to the current claims either.
With regards to 103, Applicant’s arguments are moot in view of the revised rejections above, citing new portions of the prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pechacek (US 2020/0301700) – disclosing issue tracking with sprints and backlogs (See FIG. 3) and having backlog issues dragged and dropped, where “in progress” 404 status can be given for issues placed in a sprint 302 (See par 46-47)
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
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, Anita Coupe can be reached at 571-270-3614. 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.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619