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 .
Status of Claims
Claims 1, 6, 10, 16 and 18 – 19 have been amended and are hereby entered.
Claims 4 – 6, 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 FINAL.
Response to Arguments
Applicant's arguments filed April 13, 2026 have been fully considered but they are not persuasive.
Amendments regarding the 112(a) rejection have been entered and Applicant respective arguments from p. 12 from Remarks have been considered. Therefore, this particular rejection has been withdrawn due to the Applicant's amendments.
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 and 2 starting in p. 12: Applicant disagrees that the pending claims are not directed to any of the abstract ideas identified and additionally argues that the claims integrate the judicial exception into a practical application by improving the functioning of a computer, specifically by reciting “a new, specific manner of displaying a limited set of information to a user by simultaneously presenting and interactively connecting a first set of graphical icons” in different interfaces and after another user selection displaying in another interface the “set of update summaries for a particular user”. However, the Examiner find this argument unpersuasive because the claims are still reciting the abstract ideas identified as commercial interactions in the form of business relations as well as interactions between people in the form of social activities and following instructions since user inputs and requests for updates on project issues (i.e. including issue status) that need to be resolved are claimed. Similarly, the claims fall under mental processes as they recite identification and analysis of issues to generate update summaries that encompass observation, evaluation and judgement (See MPEP 2106.04(a)(2), subsections II and III).
The Applicant further compares the pending claims to federal case Core Wireless for claiming “an improved user interface for electronic devices that displays an application summary of unlaunched applications, where the particular data in the summary is selectable by a user to launch the respective application” (see MPEP2106.05(a)(I)). However, when looking at the instant claims and Applicant assertions in p.13 from Remarks, the Examiner respectfully disagrees. Because these limitations are still considered to be merely data display upon user selection of the graphical icons to navigate and display different interfaces that show update summaries for a first or second particular user with other graphical icons. In other words, the claims are improving the abstract idea itself of determining and generating the update summaries per user, rather than improving the functioning of the computer claimed or the “issue tracking systems” as later alleged.
As for the allegations related to improperly including “specific technical features in the alleged abstract idea rather than treating them as additional elements for Prong 2 analysis”, the Examiner respectfully disagrees and believes the analysis is proper. Because:
The steps directed in part to API calls were addressed as additional elements that are “merely indicating a field of use or technological environment in which to apply a judicial exception” (MPEP 2106.05(h));
The steps of analyzing issue data and identifying user accounts were considered part of the abstract idea of mental process because these do not negate and further still reads in the mental nature of the limitation(s), when analyzing/identifying such 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 business process. (see MPEP 2106.04(a)(2)(III)(B & C)).
The alleged technical features of (3) “conditional follow-up logic for generating subsequent update requests”, (4) “automatic advancement of the programmed workflow state based on received responses”; and (5) “the specific two-level GUI drill-down using graphical icons and per-user update summaries” were not really reflecting or were considered to be additional elements, rather the claims via the computer, simply recited in part: “generate subsequent update requests” based on a “project update request”; upon determining “particular response corresponds to a state change for a particular issue”, updates the “respective programmed workflow”; and “display” different interfaces corresponding to “update summaries” for a “particular user” upon user selection of corresponding “graphical icons” which merely are invoking instructions to apply the abstract idea of issue tracking on a generic computer (see MPEP 2106.05(f))
Also, the Examiner respectfully disagrees with Applicant allegations that these claim limitations were not evaluated “as a whole” and in their “ordered combination of the additional elements”. Because the office action (OA) clearly states and stated in the previous Non-Final OA filed on December 11, 2025 (see ¶16 from p.11 of this Non-Final OA) for the 101 rejection section, in Step 2A Prong 2, that the additional elements identified “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))”. Moreover, the Applicant alleges that such ordered combination “provides a concrete technical solution for asynchronous progress updates in distributed teams on mobile devices with limited screen space”, however, the claims recited a computer as a tool (e.g. invoking “apply it”) to track issues and provide/display update summaries of issues per user, as also explained above.
For Step 2B starting in p. 14: The Applicant alleges that the OA “contains no Step 2B analysis” and that it did not provide “no factual determination or evidence showing that any additional element or their ordered combination is well-understood, routine, and conventional”. However, the Examiner respectfully disagrees and finds these arguments unpersuasive. Because this and the previous OA filed contains a Step 2B analysis in the 101 rejection section and also such factual determination or evidence showing for additional elements that are “well-understood, routine, and conventional” does not apply. Because the Examiner did not consider that any of the claims recited “significantly more than a judicial exception”, by specifically reciting additional elements that were deemed to be “well-understood, routine, conventional activities previously known to the industry”, which requires a factual determination to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity (see Berkheimer memo and MPEP 2106.05(d)(I)(2)). Rather, the Examiner considered the claims to be invoking the use of a generic computer (e.g. “apply it”) or reciting mere instructions to implement an abstract idea on a computer used as a tool (see MPEP 2106.05 (f)), as further explained above.
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 § 103 for the claims on pages 16 – 17: The Applicant’s arguments regarding the amended limitations for claim 1 are unpersuasive and the Examiner respectfully disagrees. Because Applicant's arguments fail to comply with 37 CFR 1.111(b) as 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 discussing each prior art teaching, rather than focusing on the actual language claimed and their breadth in each claim limitation and how their corresponding limitation steps are different from the prior art teachings. Thus, in response to Applicant’s specific arguments and under the broadest reasonable interpretation (BRI) of the claim language for the reciting “unique project identifier” included in the “project update request” and used in API calls, the Examiner still believes that this element is taught at least by Sundin. Although, Colafrancheschi teaches “a unique project identifier associated with the project” as shown 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” (see ¶0180; Colafrancheschi), Sundin teaches the “unique project identifier” included in the “project update request” and used in API calls as “event identifiers” (see ¶0062; Sundin) as well as “content item identifiers, namespaces” received through alerts or notifications (see ¶0149 – 150; Sundin). But also, Sundin system’s software can “programmatically make API calls directly to content management system 110” upon user input (see ¶0075; Sundin). For example, when user is querying the system providing “identifier(s) of namespace(s) that the user wishes to search” (see ¶0118 – 121; Sundin), wherein a “namespace can be analogous in some ways to a root level of a file system directory” which is uniquely identified with a link or “path” (see ¶0164; Sundin).
Finally, the Examiner also respectfully disagrees with Applicant allegations regarding the combination of Colafrancheschi and Sundin as Sunding “because it teaches application programming interface calls to a content management system for namespace/content events”, not “to an issue tracking system to identify issues” which they do not rendering claim 1 obvious. This is unpersuasive firstly because both systems are managing “tasks” to either attend issues/tickets or “content items” (i.e. a “shared project”) in collaboration with other users (see ¶0071, ¶0090 and ¶0169 from Sundin and ¶0009 from Colafrancheschi). But also, because the rationale to modify or combine the prior art does not have to be expressly stated in the prior art; the rationale may be expressly or impliedly contained in the prior art or it may be reasoned from knowledge generally available to one of ordinary skill in the art, established scientific principles, or legal precedent established by prior case law. (see MPEP 2144(I)).
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 § 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, 7 - 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…including an issue an issue tracking section displaying one or more issues of a project managed…that meet a defined criteria and a first set of graphical icons;
receiving user input…that includes:
a schedule defining when, the project update request will be initiated, and
a time window defining when responses to the project update request need to be received…
initiating the project update request based on the schedule, wherein includes a unique project identifier associated with the project, and each issue is processed…in accordance with a programmed workflow defining a series of issue states;
in response to receiving the project update request: generating and executing an application programming interface call…, wherein the [[an]] application programming interface call comprises the unique project identifier which causes…to identify a set of issues associated with the unique project identifier:
receiving respective issue data for each respective issue of the first set of issues…in response to the application programming interface call;
identifying one or more respective user accounts associated with each issue by analyzing the respective issue data for each issue of the identified set of issues;
causing the generation of an update request for each respective user account, each update request including an issue identifier and an update input field;
causing the generation of one or more subsequent update requests to user accounts for which a response to the update request was not received upon expiration of the time window when fewer responses than user accounts are received within the time window;
following receipt of each respective response for each user account during the time window: generating, for each issue of the identified set of issues, a set of update summaries based on the respective responses,
each update summary of the set of update summaries including an update to an issue, an issue identifier, and a user account identifier, each corresponding to a respective issue of the set of issues;
in response to determining that a particular response of the respective responses corresponds to a state change for a particular issue, causing…to update the respective programmed workflow for the particular issue from a first state to a second state of the series of issue states;
in response to a selection by a user of a particular graphical icon of the first set of graphical icons…, causing…to display…including a second set of graphical icons corresponding to one or more update summaries of the set of update summaries for a first particular user associated with the particular graphical icon; and
in response to a subsequent selection by the user of another particular graphical icon of the first set of graphical icons…to display…comprising a third set of graphical icons corresponding to one or more update summaries of the set of update summaries for a second particular user associated with the particular graphical icon wherein the set of update summaries includes the update summary for the particular issue, the issue update summary indicating the update to the respective programmed workflow for the particular issue.
For claim 10 (representative of claim 16):
causing display,…for generating a project update request…including an issue tracking section displaying one or more issues of a project that meet a defined criteria and a first set of graphical icons;
receiving user input…that includes: a schedule defining when, the project update request will be initiated, and a time window defining when responses to the project update request need to be received by the issue tracking system
initiate, based on the schedule, the project update request for updates on issues managed…, each issue processed…
in accordance with a respective programmed workflow defining a series of issue states;
in response to receiving the project update request: generating and executing an application programming interface call…, wherein the application programming interface call includes a unique project identifier, which causes…to identify a first set of issues associated with the unique project identifier;
receiving respective issue data associated with each issue of the identified set of issues…in response to the application programming interface call;
identifying one or more respective user accounts associated with each issue by analyzing the respective issue data for each issue of the identified set of issues;
causing the generation of one or more update requests for each respective user account, each update request including an issue identifier and an update input field; and
causing the sending of each update request for each respective user account…associated with the respective user account;
causing the generation of one or more subsequent update requests to user accounts for which a response to the update request was not received upon expiration of the time window when fewer responses than user accounts are received within the time window;
following receipt of each respective response for each user account during the time window:
in response to determining that a particular response corresponds to a state change for a particular issue, causing…to update the respective programmed workflow for the particular issue from a first state to a second state of the series of issue states;
causing the generation for each issue of the identified set of issues, a set of update summaries including an update summary for each user account, each update summary including an issue identifier for a respective issue and a user input to the update request, the set of update summaries including an issue update summary for the particular issue;
causing…operating on the client device to display…including a second set of graphical icons corresponding to one or more update summaries of the set of update summaries for a first particular user; and
in response to a selection by a user of a particular graphical icon of the first set of graphical icons…causing…to display…including a third set of graphical icons corresponding to one or more update summaries of the set of update summaries for a second particular user associated with the particular graphical icon, wherein the set of update summaries includes the issue update summary for the particular issue, the issue update summary indicating the update to the respective programmed workflow 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, inputs and their input requests associated to project update “issues”, including updates from “application programming interface” or API requests as calls generated/sent, to determine and identify a set of issues and their respective user accounts along with the corresponding issue status based on time and date conditions/criteria by updating the “the respective programmed workflow for the particular issue” to further generate a “set of update summaries” for a particular user and issue, upon user selection of a graphical icon from different sets of graphical icons and send the API request and its subsequent updates to their respective 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) that are considered business relations between users that are receiving and responding to issues and their updates and update summaries. Further, 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 “…causes…to identify a first set of issues”, “identifying one or more respective user accounts associated with each issue by analyzing the respective issue data”, and “generating” a “set of update summaries” for each user account 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 and analyzing 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)).
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 an issue tracking system, a client application, a client or first/respective 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, and a processor allocation (from claim 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.
As for the steps directed in part to “receiving” user inputs, respective issue data and initiating requests related to updates, as well as “sending” update requests, “update” the “respective programmed workflows” to “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, the limitations directed in part to “generating and executing an application programming interface call…” 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 an 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: an issue tracking system, a client application, a client or first/respective 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, and a processor allocation (from claim 16). 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, 7 - 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 and mental processes at Step Prong 1. They describe additional limitations steps of:
Claims 2-3, 7 - 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. Similarly, for claims 2 and 18, associating respective user responses with issues and determining issues assigned to user accounts by sending API calls to a calendar application encompasses observation, evaluation and judgement as well.
Step 2A Prong 2 and Step 2B: For dependent claim 18, this claim recites the additional elements: a subsequent application programming interface call and a calendar application, which are also recited to be merely used as a tool to perform the abstract idea to determine the issues assigned to respective user accounts for a project. 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, 7 – 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 client device, of a first graphical interface for generating a project update request, the first graphical interface including an issue tracking section displaying one or more issues of a project managed by an issue tracking system that meet a defined criteria and a first set of graphical icons; (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 Fig. 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 user input via the first graphical interface (In ¶0178; Figs.13B – 13C, 23B – 23D, 26A, 33 – 34, 37A and 37D: teaches that “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)
that includes: a schedule defining when, the project update request will be initiated, and a time window defining when responses to the project update request need to be received by the issue tracking system (In ¶0143; Fig. 37A and 37D: teaches an example in Fig. 37A wherein “Upon the creation of the digital boards, a first user may edit the digital boards, as depicted in the FIG. 37A” to “add a date and time for tasks 3706, and to add an action task 3708”. Also, the “first user may further use a date/time button 3714 on the graphical user interface associated with the communication application, as shown in FIG. 37D, to add a date and time information for execution of the tasks in the digital boards”)
…wherein includes a unique project identifier associated with the project, and each issue is processed by the issue tracking system in accordance with a programmed workflow defining a series of issue states; (In ¶0180; Figs. 24C, 25A – 25B and 34: teaches the project update request including unique project identifier and related series of issue states, as 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.)
identifying one or more respective user accounts associated with each issue by analyzing the respective issue data for each issue of the identified set of issues; (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.)
causing the generation of an update request for each respective user account, each update request including an issue identifier and an update input field; (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”.)
causing the generation of one or more subsequent update requests to user accounts for which a response to the update request was not received upon expiration of the time window when fewer responses than user accounts are received within the time window; (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 received for an update request.)
following receipt of each respective response for each user account during the time window: generating, for each issue of the identified set of issues, 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 including an update to an issue, an issue identifier, and a user account identifier, each corresponding to a respective issue of the set of issues; (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, causing the issue tracking system to update the respective programmed workflow for the particular issue from a first state to a second state of the series of issue states; (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).)
Colafrancheschi teaches interfaces with updated summaries of tasks or issue update summary of all their corresponding users as shown in Figs. 38A – 38B, as well as interfaces for the user to review tasks progress/updates, as shown in Figs. 26A – 26C and 32 (see ¶0139 also; Colafrancheschi), wherein “user may interact with “to-do” button 2600 and “done” button 2602” (see Fig. 26A) in order to display the “all pending tasks” that are “assigned to one or more other users” on a “dashboard 2604” (see Fig. 26B) and display “all completed tasks” from “the one or more other users” in another “dashboard 2606” (see Fig. 26C and ¶0181; Colafrancheschi). However, Colafrancheschi does not explicitly teach the abilities of initiating project update requests, specifically based on a defined schedule, generate and execute an API call with a project identifier to identify the set of issues associated and receive issue data per issue from the system and specifically upon user selection of a certain graphical icon, display particular graphical interfaces with other graphical icons that correspond to update summaries of the set of update summaries for a first and a second particular user. However, Sundin teaches:
initiating the project update request based on the schedule,… (In ¶0152; Fig. 4A – 4B (420): teaches that “user contact event updates 420 can be generated by process 400 automatically or dynamically in response to one or more triggering events or conditions. For example, process 400 and/or user contact event updates 420 can be triggered by user events (e.g., user contact activity) detected by content management system 110”. Further in ¶0157, “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.”)
in response to receiving the project update request: generating and executing an application programming interface call to the issue tracking system, wherein the [[an]] application programming interface call comprises the unique project identifier which causes the issue tracking system to identify a 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 a “namespace can be analogous in some ways to a root level of a file system directory” which is uniquely identified with a link or “path” (see ¶0164). Thus, 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.)
receiving respective issue data for each respective issue of the first set of issues from the issue tracking system in response to the application programming interface call; (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.)
in response to a selection by a user of a particular graphical icon of the first set of graphical icons of the graphical interface, causing a client application operating on the first client device to display a second graphical interface including a second set of graphical icons corresponding to one or more update summaries of the set of update summaries for a first particular user associated with the particular graphical icon; and (In ¶0179 – 180; Figs. 5A – 5B (508A and 530): teaches “if the user wants to drill-down on user contact 508A (John) or limit or focus the contact activity information to user contact 508A, the user can click or select the name or profile image of user contact 508A (John) from contacts feed 506 in FIG. 5A to update GUI 502 according to expanded view 530 showing contact activity section 516 for user contact 508A (John).” Further, “Contact activity section 516 contains information, events, and/or updates pertaining to user contact 508A (John). For example, contact activity section 516 can include user contact event updates 420 generated via process 400, as shown in FIGS. 4A and 4B”.)
in response to a subsequent selection by the user of another particular graphical icon of the first set of graphical icons of the graphical interface, causing the client application to display a third graphical interface comprising a third set of graphical icons corresponding to one or more update summaries of the set of update summaries for a second particular user associated with the particular graphical icon wherein the set of update summaries includes the update summary for the particular issue, the issue update summary indicating the update to the respective programmed workflow for the particular issue. (In ¶0172; Figs. 5A – 5B (508B – 508E and 530): teaches that other graphical icons of the first set (i.e. clicking another “user contact 508”) can be clicked by the user in order to display another third graphical interface with graphical icons of a third set respective to update summaries for a second particular user and their update summary issues which is taught as “user contacts 508 can be selected by the user”. For example, “when the user selects a contact, graphical user interface 502 can present additional information about the selected contact (such as contact profile or activity information) or present an option to initiate a communication or collaboration with that contact (e.g., send a message, share a content item, start a collaborative project, etc. In some cases, a user can select a contact to update or modify contact activity and event information presented on graphical user interface 502 (e.g., Contacts feed 506, contact activity section 510). For example, the user can select contact 508A to limit contacts feed 506 to presenting information pertaining to contact 508A, as shown in FIG. 5B” which also applies to other user contacts.)
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 initiating project update requests, specifically based on a defined schedule, generate and execute an API call with a project identifier to identify the set of issues associated and receive issue data per issue from the system and specifically upon user selection of a certain graphical icon, display particular graphical interfaces with other graphical icons that correspond to update summaries of the set of update summaries for a first and a second particular user, 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 client device, a first graphical interface for generating a project update request, the first graphical interface including an issue tracking section displaying one or more issues of a project that meet a defined criteria and a first set of graphical icons; (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 Fig. 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 user input via the first graphical interface (In ¶0178; Figs.13B – 13C, 23B – 23D, 26A, 33 – 34, 37A and 37D: teaches that “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)
that includes: a schedule defining when, the project update request will be initiated, and a time window defining when responses to the project update request need to be received by the issue tracking system (In ¶0143; Fig. 37A and 37D: teaches an example in Fig. 37A wherein “Upon the creation of the digital boards, a first user may edit the digital boards, as depicted in the FIG. 37A” to “add a date and time for tasks 3706, and to add an action task 3708”. Also, the “first user may further use a date/time button 3714 on the graphical user interface associated with the communication application, as shown in FIG. 37D, to add a date and time information for execution of the tasks in the digital boards”)
identifying one or more respective user accounts associated with each issue by analyzing the respective issue data for each issue of the identified set of issues; (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.)
causing the generation of one or more update requests for each respective user account, each update request including an issue identifier and an update input field; and (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”.)
causing the sending of each update request for each respective user account to a respective client device associated with the respective user account; (In ¶0151; Fig. 28 (2814): teaches that “the second user may input a measurement number in the measurement ticket. The first user may receive a notification of the input, and may view the input in a home screen of the continuation application. Each of the first and the second users may view the historical data records a graph since the creation of the measurement ticket.” Also, refer to ¶0199 in which in “step 2814” a “final updated digital ticket” its generated from the second user computer and includes a “message that the farm task is completed by the second user” that is “associated with the completed farm task” and that is further notified to a first user that “the farm task is finished”.)
causing the generation of one or more subsequent update requests to user accounts for which a response to the update request was not received upon expiration of the time window when fewer responses than user accounts are received within the time window; (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 received for an update request.)
following receipt of each respective response for each user account during the time window: in response to determining that a particular response corresponds to a state change for a particular issue, causing the issue tracking system to update the respective programmed workflow for the particular issue from a first state to a second state of the series of issue states; (In ¶0123; Fig. 34 – 35: teaches that “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 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 generation for each issue of the identified set of issues, a set of update summaries including an update summary for each user account, (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 including an issue identifier for a respective issue and a user input to the update request, the set of update summaries including an issue update summary for the particular issue; (In ¶0143; Figs. 15C, 16A – 16B, 25B – 25C, 37A – 37B and 38A – 38B: teaches that “a summary of the digital board (associated with yield for field 17)” and “a history of operations associated with each digital board” can be viewed once selected by the user to display a “snapshot 3804 of history” on the “digital board presented on the communication application”. Refer to ¶0143, ¶0170 and ¶0180 wherein the “digital board” can include the name of the project as shown in Figs. 15C, 16A – 16B and 37A – 37B which is directed to the project identifier or project name, in accordance to ¶0020 from Applicant disclosure. But also, issues or “tickets” placed and “the name of the tasks that have been completed, etc.” are also included in each “digital board” as shown in Fig. 25B – 25C (see ¶0180).)
Colafrancheschi teaches interfaces with updated summaries of tasks or issue update summary of all their corresponding users as shown in Figs. 38A – 38B, as well as interfaces for the user to review tasks progress/updates, as shown in Figs. 26A – 26C and 32 (see ¶0139 also; Colafrancheschi), wherein “user may interact with “to-do” button 2600 and “done” button 2602” (see Fig. 26A) in order to display the “all pending tasks” that are “assigned to one or more other users” on a “dashboard 2604” (see Fig. 26B) and display “all completed tasks” from “the one or more other users” in another “dashboard 2606” (see Fig. 26C and ¶0181; Colafrancheschi). However, Colafrancheschi does not explicitly teach the abilities of initiating project update requests, specifically based on a defined schedule, generate and execute an API call with a project identifier to identify the set of issues associated and receive issue data per issue from the system and specifically upon a client application operating on the client device and/or upon user selection of a certain graphical icon, display particular graphical interfaces with other graphical icons that correspond to update summaries of the set of update summaries for a first and a second particular user. However, Sundin teaches:
initiate, based on the schedule, the project update request for updates 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 ¶0152; Fig. 4A – 4B (420): teaches that “user contact event updates 420 can be generated by process 400 automatically or dynamically in response to one or more triggering events or conditions. For example, process 400 and/or user contact event updates 420 can be triggered by user events (e.g., user contact activity) detected by content management system 110”. Further in ¶0157, “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.”)
in response to receiving the project update request: generating and executing an application programming interface call to the issue tracking system, wherein the application programming interface call includes a unique project identifier, which causes 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 a “namespace can be analogous in some ways to a root level of a file system directory” which is uniquely identified with a link or “path” (see ¶0164). Thus, 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.)
receiving respective issue data associated with each issue of the identified set of issues from the issue tracking system in response to the application programming interface call; (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.)
causing a client application operating on the client device to display a second graphical interface including a second set of graphical icons corresponding to one or more update summaries of the set of update summaries for a first particular user; and (In ¶0179 – 180; Figs. 5A – 5B (508A and 530): teaches “if the user wants to drill-down on user contact 508A (John) or limit or focus the contact activity information to user contact 508A, the user can click or select the name or profile image of user contact 508A (John) from contacts feed 506 in FIG. 5A to update GUI 502 according to expanded view 530 showing contact activity section 516 for user contact 508A (John).” Further, “Contact activity section 516 contains information, events, and/or updates pertaining to user contact 508A (John). For example, contact activity section 516 can include user contact event updates 420 generated via process 400, as shown in FIGS. 4A and 4B”.)
in response to a selection by a user of a particular graphical icon of the first set of graphical icons of the first graphical interface, causing the client application to display a third graphical interface including a third set of graphical icons corresponding to one or more update summaries of the set of update summaries for a second particular user associated with the particular graphical icon, wherein the set of update summaries includes the issue update summary for the particular issue, the issue update summary indicating the update to the respective programmed workflow for the particular issue. (In ¶0172; Figs. 5A – 5B (508B – 508E and 530): teaches that other graphical icons of the first set (i.e. clicking another “user contact 508”) can be clicked by the user in order to display another third graphical interface with graphical icons of a third set respective to update summaries for a second particular user and their update summary issues which is taught as “user contacts 508 can be selected by the user”. For example, “when the user selects a contact, graphical user interface 502 can present additional information about the selected contact (such as contact profile or activity information) or present an option to initiate a communication or collaboration with that contact (e.g., send a message, share a content item, start a collaborative project, etc. In some cases, a user can select a contact to update or modify contact activity and event information presented on graphical user interface 502 (e.g., Contacts feed 506, contact activity section 510). For example, the user can select contact 508A to limit contacts feed 506 to presenting information pertaining to contact 508A, as shown in FIG. 5B” which also applies to other user contacts.)
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 initiating project update requests, specifically based on a defined schedule, generate and execute an API call with a project identifier to identify the set of issues associated and receive issue data per issue from the system and specifically upon a client application operating on the client device and/or upon user selection of a certain graphical icon, display particular graphical interfaces with other graphical icons that correspond to update summaries of the set of update summaries for a first and a second particular user, 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 claim 2:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 1.
Colafrancheschi further teaches:
wherein the update input field includes at least one of: a first option to input a text update, a second option to input an audio update, and a third option to input a video update; (In ¶0141; Fig. 35: teaches that user input data can be measuring “yield data” as text input and the task messages can include items such as “an image, a video file, a file document, or any suitable information”. Also, in Fig. 38A a chat is shown in which the message bar includes a paper clip which generally means that multi-media attachments can be sent by each user.)
and following the receipt of each respective response for each user account, further causing the issue tracking system to associate the respective response with the issue. (In ¶0198: teaches that “application associated with the second computer may retrieve the updated digital ticket from the database”, “may parse data associated with the updated digital ticket” and “compare the parsed data with the information associated with the farm task” to “determine that the second user has completed the farm task based on the results of the comparison operation, in a next step 2814, the application associated with the second computer may generate a final updated digital ticket”.)
Regarding claim 3:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 1.
Colafrancheschi further teaches:
wherein the update input field includes one or more graphical icons having a predefined response that, when selected by the user, causes the issue to be updated at the issue tracking system in accordance with the selected predefined response. (In ¶0181; Figs. 26A and 27A: teaches that “when the user interacts with the “to-do” button 2600, all pending tasks are displayed on the dashboard 2604” in which the “user interacts with the “done” button 2602, all completed tasks are displayed on the dashboard 2606” which is directed to a predefined response that is sent and displayed to the other users as shown in Figs 27A – 27D.)
Regarding claim 7:
Colafrancheschi, as shown in the rejection above, discloses the limitations of claim 1.
Colafrancheschi does not explicitly teach the ability of the conditional limitation for either displaying graphical icons with a first scheme indicating that no update has been received or in response to receiving the update a second scheme indicates that the update is received. However, Sundin teaches:
wherein: in response to sending the one or more update requests, the client application displays the first set of graphical icons on the client device according to a first scheme indicating that no response has been received; and in response to receiving an response corresponding to the update request of the one or more update requests, the client application updates a respective graphical icon of the first set of graphical icons according to a second scheme indicating that the response corresponding to the update request has been received. (In Fig. 5B: teaches the contact activity for the condition when update requests are received with the activity of the user and their corresponding graphical icons or avatars (see John icon).)
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 ability of the conditional limitation for either displaying graphical icons with a first scheme indicating that no update has been received or in response to receiving the update a second scheme indicates that the update is received, 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).
Regarding claims 8:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 1.
Colafrancheschi further teaches:
wherein the first set of graphical icons each comprise an avatar corresponding to a user associated with a respective update summary. (In Figs. 32 – 34 and 37F: teaches interfaces in which the participants have an avatar or a picture icon in accordance to ¶0060 and Fig. 3A from applicant specifications.)
Regarding claim 9:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 1.
Colafrancheschi further teaches:
further comprising: subsequent to receiving the respective responses, causing the client device to output a notification indicating that the update summaries are complete. (In ¶0181; Figs. 26A and 27A: teaches that “when the user completes a task associated with a ticket, a status of the ticked is updated to mention complete.” See ¶0180 for more general details regarding information being notified via messages and displays on a board for tasks completed per user.)
Regarding claim 15:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 10.
Colafrancheschi teaches interfaces in which the participants have an avatar or a picture icon with expiration time window data as shown in Figs. 32 – 34 and 37F. However, Colafrancheschi does not explicitly teach the abilities of having graphical icons that corresponds to receive update summaries with an avatar and determine user accounts that have not responded to the update requests by displaying them in a second set of graphical icons. However, Sundin further teaches:
wherein the first set of graphical icons corresponds to received update summaries, each including an avatar corresponding to a user associated with a respective update summary and upon expiration of the time window (In Figs. 5A – 5B (508A – 508E): teaches an interface with graphical icons as “contact feeds” in which selecting one icon include a summary of the user activity as shown later in Fig. 5B.)
and causing the client application operating on the client device to display a fourth set of graphical icons corresponding to the user accounts that have not responded to the one of more of the update requests. (In ¶0181; Figs. 5A – 5B: teaches that upon the user “click or select the name or profile image of user contact 508A (John) from contacts feed 506 in FIG. 5A to update GUI 502 according to expanded view 530 showing contact activity section 516 for user contact 508A (John)” (see ¶0179) “the information presented in contact activity section 516 can include information about user contact 508A, such as user, session, and profile information. For example, the information about user contact 508 presented in contact activity section 516 can include, without limitation, a name, a profile picture or image, contact information (e.g., email, telephone, instant messaging address, etc.), a status” such as “inactive” which is interpreted as the user have not responded, which can be indicated to any other user from the “contacts feed”.)
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 having graphical icons that corresponds to receive update summaries with an avatar and determine user accounts that have not responded to the update requests by displaying them in a second set of graphical icons, 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), see also MPEP 2143.I.G.
Regarding claims 18:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 16.
Colafrancheschi teaches the configuration of programming a “staff meeting” at a date and time as an assigned task (see ¶0140; Colafrancheschi) to a second user. However, Colafrancheschi does not explicitly teach the abilities of receiving a meeting identifier with a scheduled meeting, determining user accounts assigned to the project by sending an API call to a specific calendar app and using the user accounts to retrieve issues assigned per user and associate them with the meeting identifier. However, Sundin further teaches:
wherein the processor allocation is further configured to: receive a meeting identifier associated with a scheduled meeting associated with the first mobile device; (In ¶0090: teaches that “collaboration content item editor 184 may configure the productivity management service 180 to provide access to the collaboration content item (e.g., using a link, including the collaboration content item, or any other mechanism to enable access to the collaboration content item) in a meeting request, a task entry, or the like. In some embodiments, collaboration content item editor 184 may instruct productivity management service 180 to place an icon corresponding to a link to the collaboration content item in the calendar entry, meeting request, task entry, or the like”.)
determine user accounts assigned to the project by sending an subsequent application programming interface call to a calendar application, the subsequent application programming interface call including the meeting identifier; and (In ¶0187: teaches that “application activity 520A can identify a calendar associated with user contact 508A (e.g., a calendar application at the client device of user contact 508A, a calendar of user contact 508A at content management system 110, etc.), and one or more entries in the calendar. For example, application activity 520A can display a calendar of user John (508A) and one or more entries in the calendar such as one or more tasks or meetings set in the calendar”.)
retrieve, using the user accounts, one or more issues assigned to the respective user accounts and associated with the meeting identifier. (In ¶0092: teaches “that users may be automatically guided to a collaboration content item related to a calendar entry, meeting request, a task entry, or the like without human intervention”.)
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 receiving a meeting identifier with a scheduled meeting, determining user accounts assigned to the project by sending an API call to a calendar app and using the user accounts to retrieve issues assigned per user and associate them with the meeting identifier, 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), see also MPEP 2143.I.G.
Regarding claim 19:
The combination of Colafrancheschi and Sundin, as shown in the rejection above, discloses the limitations of claim 16.
Colafrancheschi further teaches:
wherein the application programming interface call to the issue tracking system includes a set of user accounts selected at the client application on the client device. (In Figs. 8D, 16A, 18C, 19C – D, 22A, 24A – B and 31: teaches that the system allows the first user to “invite” (see Figs. 16A, 18C, 22A and 30) and add “members” to a “workspace” (see Fig. 8D) or “digital board” (see Figs. 24A - B). See ¶0163 and ¶0168 regarding the “list of users previously invited” that can be chosen to assign tickets and tasks that are automatically notified when completed (see ¶0199). API calls are satisfied by this prior art (see ¶0108 and ¶0135).)
Colafrancheschi does not explicitly teach the ability of sending an API call to the system. Thus, Sundin 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 provides authentication credentials” to “share, or otherwise manipulate content” (¶0075; Sundin).
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 ability of ability of sending an API call to the system, as taught by Sundin, in order to “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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gupta (U.S. Pub No. 20230421520 A1) is pertinent because it “generally relate to integration of online messaging services and document management services and, more specifically, related to a system for generating a tracking document in a document management system using data extracted from an online messaging session provided by online messaging services.” Specifically see ¶0073 wherein “issue tracking service may create and/or update an issue based on one or more data content items, or an API call, including information, such as a channel identifier, an identifier associated” with “a name and/or identification of a project”.
Savage (U.S. Pub No. 20130179799 A1) is pertinent because it is about a “system and method for actionable event generation for task delegation and management via a discussion forum in a web-based collaboration environment”
Nidecker (U.S. Patent No. 10984484 B1) is pertinent because it “relate to a method of accounting workflow integration”
Follis (U.S. Pub No. 20170220999 A1) is pertinent because it “relates generally to computer-implemented methods and systems for providing a number of workflows relating to document management project.”
Bar-On (U.S. Pub No. 20190294303 A1) is pertinent because it “relate to digital task management, and in particular to digital task management using an intermediary single-account issue inbox system.”
Chopra (U.S. Pub No. 20040015556 A1) is pertinent because it “relates generally to a software-based process/issue management system, and more particularly to a system that helps to better manage the business process, improve communication, increase efficiency and speed up the resolution of project issues.”
Wessel (U.S. Pub No. 20170323232 A1) is pertinent because it “relates to incident reporting systems and, more particularly, to reporting retail incidents using multiple electronic devices.”
Barnes (U.S. Pub No. 20170161657 A1) is pertinent because it is a “system includes a server that has access to a plurality of events associated with a construction project, including completion events and accounting events”
Homeyer (U.S. Pub No. 20190026663 A1) is pertinent because it “relates generally to project management software applications and, more specifically, to inferring time estimates in project management software applications.”
Hull (U.S. Pub No. 20150317073 A1) is pertinent because it “pertains generally to data processing systems, and more particularly, but not by way of limitation, to a platform for workplace collaboration.”
Dasdan (U.S. Patent No. 11606614 B1) is pertinent because it “generally directed to event feeds that may be displayed to a user, and, more specifically, to systems and methods for providing recommendations of new feed item sources to users.”
Jafari (U.S. Pub No. 20210319389 A1) is pertinent because it “relates generally to tools for automated management of a project. Specifically, the present disclosure relates to software tools for automated performance of a series of tasks during the undertaking and completion of a project.”
Pechachek (U.S. Pub No. 20200104125 A1) is pertinent because it is about “issue tracking systems (such as Atlassian's Jira for instance) allow users to perform various actions with respect to issues—for example, create issues, associate issues with projects and/or other issues, transition issues between workflow states, add/edit information associated with issues, assign issues to specific people/teams.”
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 Ivonnemary Rivera Gonzalez whose telephone number is (571)272-6158. The examiner can normally be reached Mon - Fri 9:00AM - 5:30PM.
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, Nathan Uber can be reached at (571) 270-3923. 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.
/IVONNEMARY RIVERA GONZALEZ/Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights