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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 31, 2025 has been entered.
Status of Claims
Claims 1, 6, 10, 16 and 18 – 19 have been amended and are hereby entered.
Claims 4 – 5, 11 – 14, 17 and 20 were cancelled.
Claims 1-3, 6 - 10 and 15 – 16 and 18 - 19 are pending and have been examined.
This action is made NON-FINAL.
Response to Arguments
Applicant's arguments filed October 31, 2025 have been fully considered but they are not persuasive.
Regarding the applicant's arguments against the 101 rejection for the pending claims on pages 12-15: Applicant’s arguments directed to the 101 analysis were considered. However, these arguments are not persuasive and the examiner respectfully disagrees for the following reasons:
For Step 2A-Prong 1 starting in p. 13: Applicant argues that the pending claims are not directed to any of the abstract ideas identified since “claims are directed to specialized computer functions that are used to generate, query, receive and parse issue data to automatically generate update requests for specific user accounts”. However, the Examiner find this argument unpersuasive because the claim recitation for using and “parsing” (i.e. analyzing) of “issue data” requires the management of commercial interactions between people wherein their work activities are actively tracked or monitored to confirm whether the issues were updated or not to further send/report those updates. Similarly, the recited functions performed by the computer are merely following instructions requested by API calls in order to display sets of summary updates to users that are further involving the management of business relations when the tickets are resolved.
For Step 2A-Prong 2 and Step 2B starting in p. 13: The Applicant alleges that the claims integrate, the judicial exception identified, into a practical application at Step 2A Prong 2, because the claimed invention “improves the functioning of issue tracking systems, by identifying a specific subset of user accounts thereby reducing unneeded data transmissions and/or generating fewer application programming interface calls when requesting updates for issues managed by an issue tracking system”. However, the Examiner respectfully disagrees and finds these arguments unpersuasive because the significance of the computer to the performance of the method and system recited in the claims are not significantly more than the abstract idea. Rather, the claims are reciting a computer at a high level of generality such that it is no more than mere instructions to perform the method on a generic component or machinery and do not qualify as an improvement to an existing technology (see MPEP 2106.05(a)(II)). Further, the additional elements, individually and in combination, while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). Thus, the claim steps further describe the end result for generating and sending API calls and update requests for updating programmed workflows and generate and display sets of update summaries, without providing details on how this alleged “improvement” to the computer functioning (i.e. “improvement to the relevant computer capability and technical field” as alleged in p. 15 from Remarks) and/or to the existing technology of “issue tracking systems” is achieved, as alleged by the Applicant.
Applicant further argues and compares the claims to claim 2 from Example 21 (see pp.13 – 14 from Remarks) for having “unconventional steps” that “amounted to significantly more that an abstract idea”. However, the Examiner respectfully finds this unpersuasive and disagrees since updating requests per respective user account and generating sets of update summaries based on respective responses do not amount to “significantly more” since these claim limitations are an end result of utilizing and performing the claimed functions with a computer to request for updates. Also, because “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept” (see MPEP 2106.05(f)(2); TLC communications). Thus, the claim limitations invoke the use of a computer as a tool to perform an abstract idea (see MPEP 2106.04(d)(I) and MPEP 2106.05(f)) and hence, cannot provide an inventive concept at Step 2B.
Finally, for the arguments in p.14, related to the Examiner to establishing “preponderance evidence that claim 1 is directed to patent ineligible material under 35 U.S.C. § 101”. The Examiner respectfully disagrees since the “preponderance evidence” test is always applied wherein the “examiner should reject a claim if, in view of the prior art and evidence of record, it is more likely than not that the claim is unpatentable” (see MPEP 706 (I)). Moreover, the Examiner did consider the “claim[s] as a whole” throughout the 101 analysis as dictated in the MPEP 2106, contrary to Applicant general allegations.
Thus, for all the reasons stated above, the Examiner respectfully disagrees, and maintains 35 USC § 101 rejection for these pending claims.
Regarding to Applicant's arguments of rejection under 35 USC § 102 and § 103 for the claims on pages 10 – 12: The Applicant’s arguments regarding the amended limitations for claim 1 are unpersuasive. Regarding the 102 rejections of the claims, the rejections are withdrawn because the Colafrancheschi reference does not teach all the newly amended claim limitations. However, Examiner finds the previously cited combination of Colafrancheschi and Sundin does teach all the limitations of the claims as amended for the following reasons: Firstly, to provide clarity in regards to arguments in p. 11, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to general allegations that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the cited references. Applicant’s assertions are focusing on each prior art teaching, rather than focusing on the actual language claimed in each claim limitation and how their corresponding limitation steps are different from the prior art teachings.
Secondly, the Examiner also respectfully disagrees with Applicant allegations regarding Colafrancheschi not teaching the amended steps directed in part to “in response to a timing condition satisfying the schedule parameter, initiating the project update and in response to receiving the project update request” and “issues, the system parses issue data of the identified issues to identify a respective user account associated with the respective issue, and automatically generates an update request for each respective user account”. Because Colafrancheschi teaches examples for closing “the updated digital ticket upon confirming that one or more tasks have been completed by the second user” (see ¶0123; Colafrancheschi) and another example in ¶0152 – 153, wherein the system initiates project updates (i.e. sharing “checklist ticket” information via notifications with the first user upon a second user flags each task once completed that may be furthered scheduled and set with reminders). Even if the Applicant does not concede with Colafrancheschi teaching, Sundin also teaches that “contact event updates 420” can be sent to the user even when “events in user contact event updates 420 reach a threshold number” (see ¶0157).
As for the step of “generating and executing an application programming interface call to the issue tracking system, that includes the unique project identifier causing the issue tracking system to identify a first set of issues associated with the unique project identifier”, is still taught by Sundin as user devices can programmatically make API calls directly to content management system 110 when a user either “provides authentication credentials, to read, share, or otherwise manipulate content” (¶0075; Sundin) and teaches that the “user contact event updates 420 can include alerts or notifications provided on a graphical user interface of client device 150” wherein event updates can include “event identifiers associated with the filtered events, content item information associated with the filtered events” such as “content item identifiers, namespaces” (see ¶0149 - ¶0150; Sundin) which is directed to the receiving issue data associated to the unique project identifier provided in the API call. See Figs. 5A and 5B from Sundin. Please, refer to the Claim Rejections - 35 USC § 103 section for further details. Therefore, for the reasons stated above the Examiner respectfully disagrees, and maintains the corresponding 35 USC §103 rejection for these pending claims.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-3, 6 - 10 and 15 – 16 and 18 - 19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1, 10 and 16 are directed in part to limitations that involves the computer processing including "for each issue of the first set of issues, parse respective issue data to identify a respective user account associated with the respective issue”. However, this particular function for “parsing” data, as underlined, was not properly described in the application as filed and therefore is considered as introducing new matter (see MPEP 2163 (I)(B)). Applicant has not pointed out where the amended claim is supported, nor does there appear to be a written description of the claim limitation in the application as filed for the type of parsing technique. Therefore, the support for the limitation is not apparent, and applicant has not pointed out where the limitation is supported (see MPEP 2163.04). Instead, Applicant specification in ¶0020, generally disclose the identification of recent updates made by a user by “analyzing issue data”, but lacks sufficient detailed information or discussion about all the possible steps or procedures taken to perform such “parsing” as claimed. Given the fact that the definition of “parsing” can include processing text data into tokens, the Applicant has no support for this limitation. Therefore, the disclosed claim limitations are considered to be lacking possession of the subject matter claimed and indicated above which is not sufficiently supported by the specifications as originally filed on June 30, 2022.
To overcome this rejection, Examiner suggests amending the claims to recite “analyzing” instead of “parsing”. For the same reasons stated above, claims 2-3, 6 - 9, 11-12, 15 and 18 - 19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ) based on their dependency to claims 1, 10 and 16.
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-3, 6 - 10 and 15 – 16 and 18 - 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of claims 1 and 10 as the most representative of the independent claims set 1, 10 and 16, as follows:
At Step 1: Claims 1 – 3, 6 – 9, 10 and 15 fall under statutory category of a process, while claims 16 and 18 - 19 are directed to method considered a system.
At Step 2A Prong 1: Claim 1, 10 and 16 recite an abstract idea in their respective following limitations:
For claim 1:
causing display…for generating a project update request…displaying…a project managed…and including an issue data section displaying one or more issues that meet a defined criteria with respect to the project;
…defining one or more parameters for the project update request, the [one] or more parameters comprising a schedule parameter and a time window parameter;
in response to a timing condition satisfying the schedule parameter, initiating the project update, the project update request including a unique project identifier that is associated with the project managed…the project including issues, each issue processed…in accordance with a respective programmed workflow defining a series of issue states;
in response to receiving the project update request:
…the [[an]] application programming interface call comprising a unique project identifier thereby causing…to identify a first set of issues associated with the unique project identifier:
in response to providing the application programming interface call…receiving issue data for each respective issue of the first set of issues…;
for each issue of the first set of issues, parse respective issue data to identify a respective user account associated with the respective issue;
generating an update request for each respective user account, each update request comprising an issue identifier and an update input field for the respective issue;
in accordance with a completion of a time window determined using a time window parameter associated with the project update request, and in accordance with receipt of fewer responses to respective update requests than the set of user accounts, cause generation of a set of subsequent update requests for any user accounts for which a respective response to an update request was not received;
in accordance with a completion of the time window determined using the time window parameter associated with the project update request, and in accordance with receipt of each respective response for each user account of the set of user accounts:
generating a set of update summaries based on the respective responses,
each update summary of the set of update summaries comprising an update to an issue, an issue identifier, and a user account identifier, each corresponding to a respective issue of the set of issues, each respective issue satisfying the issue update condition;
in response to determining that a particular response of the respective responses corresponds to a state change for a particular issue, cause…to update the respective programmed workflow for the particular issue from a first state to a second state…
For claim 10 (representative of claim 16):
in response to a timing condition satisfying the schedule parameter, initiating the project update on issues managed…, each issue processed by the issue tracking system in accordance with a respective programmed workflow defining a series of issue states;
in response to receiving the request:
…thereby causing the issue tracking system to identify a first set of issues associated with the unique project identifier;
in response to providing the application programming interface call…receiving issue data for each respective issue of the first set of issues…;
for each issue of the first set of issues, parse respective issue data to identify a respective user account associated with the respective issue;
generating an update request for each respective user account, each update request comprising an issue identifier and an update input field for the respective issue; and
sending each update request…associated with a respective user;
in accordance with a completion of a time window determined using the time window parameter associated with the project update request, and in accordance with receipt of fewer responses to update requests than the set of user accounts, cause generation of a set of subsequent update requests for any user accounts for which a respective response to an update request was not received;
in accordance with a completion of the time window determined using the time window parameter associated with the project update request, and in accordance with receipt of each respective response for each user account of the set of user accounts:
in response to determining that a particular response corresponds to a state change for a particular issue, cause…to update the respective programmed workflow for the particular issue from a first state to a second state;
generating a set of update summaries including an update summary for each user account the update summary comprising an issue identifier for a respective issue and a user input to the update request, the set of update summaries comprising an update summary for the particular issue…
Generally, these limitations, describe the identification of a user account information with associated issues that are assigned to each user to efficiently automate and process business workflows and receive updates to keep track of issues’ status progress and inform their respective business users. Thus, these limitations recite the abstract idea of a certain method of organizing human activity in the forms of “commercial or legal interactions” and “managing personal behavior or relationships or interactions between people” as these claims recite the steps of receiving and identifying business user’s account information and their input requests associated to project update “issues”, including updates from API requests generated/sent, to determine and identify an “issue assigned to a user and an option to provide user input” to the “issue” along with the corresponding issue status by updating the “the respective programmed workflow for the particular issue” to further generate a “set of update summaries” and send the API request and its subsequent updates to their respective user to that is later displayed as “graphical icons” that can be selected to display “set of update summaries” for a “particular issue” and user. That is, the claims recite an abstract idea essentially because the claims encompass steps in the project management process (i.e., tracking issues with the project). Thus, these limitations encompass interactions between people (i.e. users involved in project tasks/issues that are being updated) that further involve the monitoring of user’s social activities, following instructions based on users being assigned to a particular issue, and managing business relations to handle business issues through the application system. As disclosed in the specification in ¶0018, this invention allows “managing asynchronous updates for issues that are managed by an issue tracking system” and “may manage projects, which may include one or more issues”.
Specifically, certain steps in claims 1 and 10 (representative of claim 16) recite in part: that when “generating and executing an application programming interface call”, causes “…to identify a first set of issues”, “identify a respective user account associated with the respective issue”, after parsing “respective issue data”, and the “generating” of a “set of update summaries” which fall under the abstract idea of mental processes that can be practically be performed in the human mind or in pen and paper (See MPEP 2106.04(a)(2), subsection III). Because identifying set of issues and their corresponding user accounts to generate the set of update summaries encompass observation, evaluation and judgement. Also, these steps can either be done with the help of physical aid such as pen and paper or can be performed by humans without or with the assistance (e.g. tool) a computer. Thus, the steps do not negate and further still reads in the mental nature of the limitation(s), when identifying and/or generating such respective information, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of updating issues per issue update requests to be satisfied for a related project and generating issue update summaries as well (see MPEP 2106.04(a)(2)(III)(B & C)).
Further, Examiner does not find the presence of these two abstract ideas in the claims renders the claims non-abstract, see MPEP 2106.04.I discussing Recognicorp, LLC v. Nintendo Co., Ltd., 855 F. 3d 1322, 1327 (stating combining “one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract”).
Step 2A Prong 2: For independent claims 1, 10 and 16, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of issue tracking system, a client application, a first client device, a first graphical interface, a second graphical interface, third graphical interface and an application programming interface call (from claims 1, 10 and 16); a memory allocation; a data store, one or more executable assets, a processor allocation, and a first mobile device (from claims 10 and 16). These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). Because these element features are recited as being performed by the computer. Moreover, the computer used is recited at a high level of generality that is being used as a tool to perform the generic computer functions for generating and sending API calls and update requests for updating programmed workflows and generate and display sets of update summaries. Thus, these steps mentioned above are further describing and applying the abstract idea without placing any limits on how the technological components are being improved, while distinguishing in the claim language, the performing limitations from functions that generic computer components can perform.
Further, the step of “for each issue of the first set of issues, parse respective issue data to identify a respective user account” in the claims, this step is also broadly recited is performed generally to apply the abstract idea without placing any limits on how the “parsing” of the issue data is performed distinctively from generic computer components and without the function being generally be invoked as an “apply it” to a computer.
As for the steps directed in part to “receiving” user inputs, issue data and requests related to updates, as well as “sending” update requests, “update” of “programmed workflows” and requests and “display” interfaces with “graphical icons” and “set of update summaries” in the claims are really nothing more than links to computer implementing the use of ordinary capacity for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)).
Additionally, these limitations are “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)). In this case, the use of API calls and its updates are broadly recited and lacks details on how they are generated and simply are limited to generating, receiving and sending the API calls and requests on a online network between applications installed in computer devices that attempts to limit the use of the abstract idea to computer environments (see MPEP 2106.05(h) for examples (vi), (viii) and (x)).
Step 2B: For independent claims 1, 10 and 16, these claims recite the additional elements: issue tracking system, a client application, a first client device, a first graphical interface, a second graphical interface, third graphical interface (from claims 1, 10 and 16); a memory allocation; a data store, one or more executable assets, a processor allocation, and a first mobile device (from claims 10 and 16), including the steps of “parsing” data. These additional elements are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Also, the recitation of a computer to perform the claim limitations amounts to no more than mere instructions to apply the exception using a generic computer component. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 2-3, 6 - 9, 15 and 18 - 19, the same analysis is incorporated. Due to their dependency to the independent claims analyzed, these claims cover or fall under the same abstract idea(s) of a certain method of organizing human activity at Step Prong 1. They describe additional limitations steps of:
Claims 2-3, 6 - 9, 15 and 18 - 19: further describes the abstract idea of the issue tracking method and the further description of user input options related to issues of text/audio/video updates, that in response are associated and are sent as responses and indications that are displayed as “graphical icons” comprising of selected “predefined responses” with a user “avatar”. The “update requests” are further described as being notified to the corresponding users and the display of “the set of update summaries” for each user with their respective status of completion. Thus, being directed to the abstract idea groups of “commercial or legal interactions” and “managing personal behavior or relationships or interactions between people” as it is involving user’s social activities and following instructions to resolve, track and update the issues to manage business relations related to collaborative projects between users.
Step 2A Prong 2 and Step 2B: For dependent claims 18 and 19, these claims recite the additional elements: application programming interface (API) call (from claims 18 and 19), calendar application (from claim 18), which are also recited to be merely used as a tool to perform the abstract idea to generate a “set of update summaries” regarding the issues assigned. Thus, it amounts no more than mere instructions to apply the exception using a generic computer component (MPEP 2106.05(f)) and/or links to computer implementing the use of ordinary capacity for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (MPEP 2106.05f (2)). Accordingly, these 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.
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.
Claims 1 – 3, 6 – 10, 15 - 16 and 18 – 19 are rejected under 35 U.S.C. 103 as being unpatentable over Colafrancheschi (U.S. Pub No. 20190287188 A1) in view of Sundin (U.S. Pub No. 20190124169 A1).
Regarding claim 1:
Colafrancheschi teaches:
causing display, on a first client device, of a first graphical interface for generating a project update request, the first graphical interface displaying a project interface for a project managed by an issue tracking system and including an issue data section displaying one or more issues that meet a defined criteria with respect to the project; (In ¶0140; Fig. 1A (106) and Figs.25B, 26A and 33 – 34: teaches a window interface that displays different requests related to farm tasks included as tickets/issues (i.e. directed to a business project; see ¶0123 for general details) for a second user to either “count a number of cattle in the fields”, “wait until a pre-defined date and time in order to send invoices”, “wait until a pre-defined date (for example, the end of the day) in order to transmit the invoice” or “wait until a pre-defined date and time to have a staff meeting” as shown in Figs. 33 for the interface board and Fig. 34 for showing tasks per board which are directed to an issue data section with issues that meet a defined criteria. Refer to ¶0120 and Fig. 1A for more details of the “data processing system 106” (e.g. directed to issue tracking system) that includes “a server 110, an application programming interface (API 112)”. Refer to ¶0147 for an example of “task messages” transmitted and displayed and to ¶0180 for dashboard showing the status of the tickets.)
receiving one or more user inputs to the first graphical interface defining one or more parameters for the project update request, the or more parameters comprising a schedule parameter and a time window parameter; (In ¶0178; Figs.13B – 13C, 23B – 23D, 26A and 33 – 34: teaches “When a particular ticket is displayed on the dashboard 2302, the user may press on a ticket name, and access detailed information associated with the particular ticket” which can be further managed by clicking the “manage ticket” button 2304” to edit any information associated with the ticket such as distance parameters and due dates as shown in Figs. 23B and 23D (refer to ¶0168 for more details of editing and scheduling parameters related to time window/frame).)
in response to a timing condition satisfying the schedule parameter, initiating the project update, the project update request including a unique project identifier that is associated with the project managed by an issue tracking system, the project including issues, each issue processed by the issue tracking system in accordance with a respective programmed workflow defining a series of issue states; (In ¶0123; Figs. 24C, 25A – 25B and 34: teaches an example wherein “first computing device 102 may close the updated digital ticket upon confirming that one or more tasks have been completed by the second user” which is directed to initiating requests for the project updates. As for the project update request including unique project identifier and related series of issue states, this is illustrated in Figs. 25A – 25B which shows project updates as “to do’s” with tasks as tickets for a board with a project name identified as “Johan”, in accordance to the unique project identifier example given in ¶0020 from Applicant disclosure. Refer to ¶0152 – 153 for another example wherein the system initiates project updates (i.e. sharing “checklist ticket” information via notifications with the first user upon a second user flags each task once completed that may be furthered scheduled and set with reminders).)
for each issue of the first set of issues, parse respective issue data to identify a respective user account associated with the respective issue; (In ¶0198 – 199; Fig. 28 (2804 and 2812): teaches that in “step 2812, the application associated with the second computer may determine a status of the farm task associated with the digital ticket based upon the continuous updates to the digital ticket” wherein “the application associated with the second computer may parse data associated with the updated digital ticket” to further “compare the parsed data with the information associated with the farm task” and determine “that the second user has completed the farm task based on the results of the comparison operation” which is directed to identifying the user account associated to the respective issue. Refer to ¶0180 for board information which contains “name of users who have completed tasks associated with the tickets” and to ¶0187 – 188 for more parsing data examples.)
generating an update request for each respective user account, each update request comprising an issue identifier and an update input field for the respective issue; (In ¶0198 – 199; Fig. 28 (2812 and 2814): teaches in “step 2812, the application associated with the second computer may determine a status of the farm task associated with the digital ticket based upon the continuous updates to the digital ticket” which is directed to generating the update request per user account and respective issue (see ¶0191 and ¶0193 – 194 for more continuous updates examples). Then, in “step 2814, the application associated with the second computer may generate a final updated digital ticket” that includes “a message that the farm task is completed by the second user” with “information associated with the completed farm task”.)
in accordance with a completion of a time window determined using a time window parameter associated with the project update request, and in accordance with receipt of fewer responses to respective update requests than the set of user accounts, cause generation of a set of subsequent update requests for any user accounts for which a respective response to an update request was not received; (In ¶0181; Figs.25A and 26A; Fig. 21B (2102) and Figs. 34 – 35: teaches that the system can display “all pending tasks” once the user interacts with the “To-do” button (see Fig. 26A). But also, the user can receive and see if there are any “Overdue” tasks in their feed as notification which is illustrated in Figs. 25A and 34. Refer to ¶0153 wherein users with assigned tasks based in a due date or time interval can receive and “set reminders for themselves or other selected users”. Finally, in ¶0123 the “communication application of the second computing system 104 may transmit the updated digital ticket to the communication application of the first computing device 102” which “may review information associated with the updated digital ticket” that upon the confirmation that the tasks were completed, closes the “updated digital ticket”. Meaning that otherwise, the ticket will be open with continuous updates via constant user data tracking (see ¶0191), which is another example of causing the generation of a set of subsequent update requests for any user accounts for which their response was not receive for an update request.)
in accordance with a completion of the time window determined using the time window parameter associated with the project update request, and in accordance with receipt of each respective response for each user account of the set of user accounts: generating a set of update summaries based on the respective responses, (In ¶0143; Fig. 7A and 7B; Fig. 33, Fig. 37F (3718) and Figs. 38A – B: teaches that the claimed system “upon the creation of the digital board, a first user may be provided a summary of the information associated with each digital board. For instance, a first user may select a button 3718 on the graphical user interface associated with the communication application, as shown in FIG. 37F, to view a summary of the digital board (associated with yield for field 17). In some cases, a first user may be provided a history of operations associated with each digital board. For instance, a first user may select a button 3802 on the graphical user interface associated with the communication application, as shown in FIG. 38A, to view a history of summary of the digital board (associated with yield for field 17)”. Finally, “The historical data displayed in the snapshot 3804” can also include “historical data” that may “display the productivity of various workers in the farm”. Refer to ¶0199 – 200 wherein after all tasks are completed by the second user the computer may “generate a final updated digital ticket” with a “message” that includes “information associated with the completed farm task(s)” and a notification that these task(s) are finished which is an example of a set of update summaries based on the respective responses as well. These updates are used as “recordkeeping” by the system as shown in Fig. 7A.)
each update summary of the set of update summaries comprising an update to an issue, an issue identifier, and a user account identifier, each corresponding to a respective issue of the set of issues, each respective issue satisfying the issue update condition; (In ¶0152; Figs. 26A – 26C, 27A – 27D, 34 and 37F, 38A – 38B and 38F; Fig. 28 (2814): teaches that “each task once completed” can be flagged in the “checklist ticket” and the second user can “share the information” with the first user wherein such information includes “identification information of a second user (receiver)” (e.g. directed to the user account identifier), “name of the ticket” (e.g. directed to an issue identifier ), “date of the ticket creation, and checklist with description of items” that relates to the “tasks requested to action”. Refer to ¶0143 – 144 and Figs. 37F, 38A – 38B and 38F for details of a provided “summary of the information associated with each digital board” and the “history of operations” per digital board and a “snapshot” that can include information of tasks done by each user as shown in Fig. 38B.)
in response to determining that an a particular response of the respective responses corresponds to a state change for a particular issue, cause the issue tracking system to update the respective programmed workflow for the particular issue from a first state to a second state; (In ¶0123; Fig. 34 – 35: teaches “the first computing device 102 may review” and “parse” information associated with the updated digital ticket” to “review the information” wherein the system can then “close the updated digital ticket upon confirming that one or more tasks have been completed by the second user”. Similarly, for this limitation wherein the system’s determines that an update has occurred and cause the programmed workflow to be updated based on the state change of the particular issue, from a first state to a second state, is also satisfied and directed when “the second user may flag each task once completed in the checklist ticket and share the information, via the checklist ticket, with the first user, who will receive a notification in the home screen of the application” (see ¶0152).)
causing the client application operating on the first client device to display a second graphical interface comprising graphical icons corresponding to update summaries in the set of update summaries; and (In Figs. 33 – 35: teaches an interface with different “digital boards” or projects in which a team of users and their graphical icons appear and correspond to the summary of each “digital board” or project as shown in Fig. 33 while in Fig. 34 it shows a summary of the tasks per project or “digital board”. See ¶0140 for more details. Finally, in Fig. 35 there’s a “share” icon to input data when sending an update of the task issue assigned.)
in response to a selection of a particular graphical icon, causing the client application to display a third graphical interface comprising the set of update summaries for a particular user associated with the particular graphical icon, the set of update summaries comprising the update summary for the particular issue, the update summary indicating the update to the respective programmed workflow for the particular issue. (In Fig. 32: teaches an interface with a user and their graphical icon or avatar in which the user can see their assigned tasks, boards and general announcements. See ¶0139 for more details.)
Colafrancheschi does not explicitly teach the abilities of specifically generating and executing an API call with a project identifier to identify the set of issues associated and receive issue data per issue from the system. However, Sundin teaches:
in response to receiving the project update request: generating and executing an application programming interface call to the issue tracking system, the [[an]] application programming interface call comprising a unique project identifier thereby causing the issue tracking system to identify a first set of issues associated with the unique project identifier: (In ¶0075: teaches “a software package such as an application running on client device 150, can programmatically make API calls directly to content management system 110 when a user either “provides authentication credentials, to read, share, or otherwise manipulate content”. Moreover, the user can query the system to obtain “the set of identifier(s) of authorized namespace(s) the user is permitted to access” based on input of “identifier(s) of namespace(s) that the user wishes to search” (see ¶0118 – 121), wherein these examples are in accordance with the API call examples given in ¶0045 – 46 and ¶0051 – 52 from Applicant disclosure. Refer to ¶0157 wherein “Content management system 110 and/or collaborative content management service 126 can send user contact event updates 420 as events occur, as updates are calculated, as updates are requested by the user or pulled from client devices 150, periodically based on a particular time interval, when the events in user contact event updates 420 reach a threshold number, as the user interacts with user content event updates previously sent, etc.” which is another example of API calls being generated and executed to identify issues related to a unique project identifier.)
in response to providing the application programming interface call to the issue tracking system, receiving issue data for each respective issue of the first set of issues from the issue tracking system; (In ¶0150; Fig. 4A (410) and Figs. 5A – 5B: teaches that “user contact event updates 420 can include alerts or notifications provided on a graphical user interface of client device 150” wherein event updates can include “event identifiers associated with the filtered events, content item information associated with the filtered events” such as “content item identifiers, namespaces” (see ¶0149) which is directed to the receiving issue data associated to the unique project identifier provided in the API call. Refer to ¶0157 – 158 for general details of “event updates” that are received by the user and ¶0175 for details of these functions shown in interfaces as illustrated in Figs. 5A and 5B.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Colafrancheschi to provide the abilities of specifically generating and executing an API call with a project identifier to identify the set of issues associated and receive issue data per issue from the system, as taught by Sundin in order to provide greater “visibility into what modifications have been made to a shared collection by other users” and to “track collaboration events and user activity from other users.” (¶0017; Sundin). But also, provide a system with the purpose of “efficiently track activity and events from a user's contacts in a collaboration environment, and provide the user with filtered and sanitized updates of activities and events from the user's contacts.” (¶0018; Sundin), see also MPEP 2143.I.G.
Regarding claims 10 and 16:
This independent claim set is represented by claim 10
Colafrancheschi further teaches:
causing display, on a first client device, of a first graphical interface for generating a project update request, the first graphical interface displaying a project interface for a project managed by an issue tracking system and including an issue data section displaying one or more issues that meet a defined criteria with respect to the project; (In ¶0140; Fig. 1A (106) and Figs.25B, 26A and 33 – 34: teaches a window interface that displays different requests related to farm tasks included as tickets/issues (i.e. directed to a business project; see ¶0123 for general details) for a second user to either “count a number of cattle in the fields”, “wait until a pre-defined date and time in order to send invoices”, “wait until a pre-defined date (for example, the end of the day) in order to transmit the invoice” or “wait until a pre-defined date and time to have a staff meeting” as shown in Figs. 33 for the interface board and Fig. 34 for showing tasks per board which are directed to an issue data section with issues that meet a defined criteria. Refer to ¶0120 and Fig. 1A for more details of the “data processing system 106” (e.g. directed to issue tracking system) that includes “a server 110, an application programming interface (API 112)”. Refer to ¶0147 for an example of “task messages” transmitted and displayed and to ¶0180 for dashboard showing the status of the tickets.)
receiving one or more user inputs to the first graphical interface defining one or more parameters for the project update request, the or more parameters comprising a schedule parameter and a time window parameter; (In ¶0178; Figs.13B – 13C, 23B – 23D, 26A and 33 – 34: teaches “When a particular ticket is displayed on the dashboard 2302, the user may press on a ticket name, and access detailed information associated with the particular ticket” which can be further managed by clicking the “manage ticket” button 2304” to edit any information associated with the ticket such as distance parameters and due dates as shown in Figs. 23B and 23D (refer to ¶0168 for more details of editing and scheduling parameters related to time window/frame).)
in response to a timing condition satisfying the schedule parameter, initiating the project update on issues managed by the issue tracking system, each issue processed by the issue tracking system in accordance with a respective programmed workflow defining a series of issue states; (In ¶0123; Figs. 1A and 2B: teaches that the system of the “communication application of the first computing device 102 may share the digital board and the digital ticket with the communication application of the second computing device 104” that was assigned to, in which “communication application of the second computing device 104 may process information associated with the status of the one or more machines and the location data of the second user to determine whether the one or more tasks are completed. Upon determining that the one or more tasks are completed, the communication application of the second computing device 104 may update the digital ticket. Updated digital ticket may include a message that the one or more tasks are completed”)
for each issue of the first set of issues, parse respective issue data to identify a respective user account associated with the respective issue; (In ¶0198 – 199; Fig. 28 (2804 and 2812): teaches that in “step 2812, the application associated with the second computer may determine a status of the farm task associated with the digital ticket based upon the continuous updates to the digital ticket” wherein “the application associated with the second computer may parse data associated with the updated digital ticket” to further “compare the parsed data with the information associated with the farm task” and determine “that the second user has completed the farm task based on the results of the comparison operation” which is directed to identifying the user account associated to the respective issue. Refer to ¶0180 for board information which contains “name of users who have completed tasks associated with the tickets” and to ¶0187 – 188 for more parsing data examples.)
generating an update request for each respective user account, each update request comprising an