DETAILED ACTION
Notice to Applicant
The following is a FINAL Office action upon examination of application number 18/951,440 filed on 11/18/2024. Claims 1-20 are pending in this application, and have been examined on the merits discussed below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
3. In the response filed April 30, 2026, Applicant amended claims 1-8 and 10-20, and did not cancel any claims. No new claims were presented for examination.
4. Applicant's amendments to claims 8 and 15 are hereby acknowledged. The amendments are sufficient to overcome the previously issued rejection of claims 8-14 and 15-20 under 35 U.S.C. 112(b); accordingly, this rejection has been withdrawn.
5. Applicant's amendments to claims 1, 8, and 15 are hereby acknowledged. The amendments are not sufficient to overcome the previously issued claim rejection under 35 U.S.C. 101; accordingly, this rejection has been maintained.
Response to Arguments
6. Applicant's arguments filed April 30, 2026, have been fully considered.
7. Applicant submits “Without acquiescing to the propriety of the rejections and reserving the right to argue additional or different distinguishing features in the future, independent claims 1, 8, and 15 have been amended to include distinguishing features such as, for example, "generating, by a messaging server, a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams," "each stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream," "receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams," and "the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task," (emphasis added)...Matsuoka does not disclose or suggest at least these distinguishing features.” [Applicant’s Remarks, 04/30/2026, page 10]
In response to the Applicant’s argument that “Matsuoka does not disclose or suggest” “generating, by a messaging server, a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams,” “each stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream,” “receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams,” and “the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task,” it is noted that this argument is a mere allegation of patentability by the Applicant with no supporting rationale or explanation. Merely stating that the claims do not teach a feature does not offer any insight as to why the specific sections of the prior art relied upon by the Examiner fail to disclose the claimed features. Applicant's arguments amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Moreover, the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 04/30/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the updated ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim and supports a conclusion of obviousness of the amended claims.
8. Applicant submits “As shown in FIG. 13, Matsuoka's user interface 1300 does not include the claimed feature of "a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams" and Matsuoka's task list 1304 does not appear to be associated with a particular "stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream," as claimed (emphasis added). Furthermore, Matsuoka's user interface 1300 does not include a "workspace GUI [that] comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task," as claimed (emphasis added).” [Applicant’s Remarks, 04/30/2026, pages 11-12]
In response to the Applicant’s argument that Matsuoka does not disclose or suggest “a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams,” “stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream," and "workspace GUI [that] comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task,” the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 04/30/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the updated ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim and supports a conclusion of obviousness of the amended claims.
9. Applicant submits “Figlin does not disclose or suggest a "workspace GUI [that] comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task," as claimed (emphasis added).” [Applicant’s Remarks, 04/30/2026, pages 12-13]
In response to the Applicant’s argument that “Figlin does not disclose or suggest a "workspace GUI [that] comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task,” the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 04/30/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the updated ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim and supports a conclusion of obviousness of the amended claims.
10. Applicant submits “Figlin does not disclose or suggest the claimed feature of "at least one calendar panel configured to display at least one of meetings, appointments, or reminders based on the at least one calendar," (emphasis added).” [Applicant’s Remarks, 04/30/2026, page 13]
In response to the Applicant’s argument that “Figlin does not disclose or suggest the claimed feature of "at least one calendar panel configured to display at least one of meetings, appointments, or reminders based on the at least one calendar,” the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 04/30/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to dependent claim 4 that are believed to be addressed via the updated ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim and supports a conclusion of obviousness of the amended claims.
11. Applicant submits “The Office Action lists the following elements and states that none of them provide a practical application: "generating, by a messaging server, a task graphical user interface (GUI), a database, a client device, and a workspace GUI that includes at least one chat panel, at least one file panel, and at least one task panel (claim 1), a database, a messaging server, generate a task graphical user interface (GUI), a database, a client device, and a workspace GUI that includes at least one chat panel, at least one file panel, and at least one task panel (claim 8), a non-transitory computer-readable device having instructions stored thereon, at least one computing device, generating, by a messaging server, a task graphical user interface (GUI), a database, a client device, a workspace GUI that includes at least one chat panel, at least one file panel, and at least one task panel (claim 15)." OA, 5-6. The Office Action then alleges that "the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception." OA, 6. Applicant respectfully disagrees.” [Applicant’s Remarks, 04/30/2026, page 14]
The Examiner respectfully disagrees. The additional elements in exemplary claim 1 are: a messaging server, a first dashboard graphical user interface (GUI), a task GUI, a database, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, and wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task, which merely serve to tie the abstract idea to a particular technological environment (computer-based operating environment) via generic computing hardware, software/instructions, which is not sufficient to amount to a practical application, as noted in MPEP 2106.05. Applicant has provided no facts/evidence, cited any portion of the Specification, nor provided a persuasive line of reasoning showing how the additional elements are integrated with the abstract idea to integrate the abstract idea into a practical application.
Furthermore, it is noted that the claims are devoid of any discernible change, transformation, or improvement to a computer (software or hardware) or any existing technology. Applicant has not shown that any specific technological improvement is achieved within the scope of the claims. It bears emphasis that no server, graphical user interface, database, client device, or technological elements are modified or improved upon in any discernible manner. Instead, the result produced by the claims is simply information relating to a second task, which is not a technical result or improvement thereof.
Lastly, the additional elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Accordingly, this argument is found unpersuasive.
Applicant alludes to Step 2B of the eligibility inquiry by suggesting that amended claim 1 recites significantly more than any alleged abstract idea. The Examiner respectfully disagrees and notes that the claims merely product a result in the form of a “second task,” which is not an improvement to the server, graphical user interface, database, or client device. These elements have been considered individually and in combination, or any other system or technology. The claims have not been shown to modify, reconfigure, manipulate, or transform the server, graphical user interface, database, client device, or any technology in any discernible manner, much less yield an improvement thereto. There is no indication that any of the additional elements or the combination of elements amount to an improvement to the computer or to any technology. Their individual and collective functions merely provide generic computer implementation. Therefore, these additional claim elements do not amount to significantly more than the abstract idea itself.
12. Applicant submits “Similar to DDR Holdings, the instant claims (as amended) also amount to significantly more because they recite a solution that is rooted in computer technology and overcomes a problem specifically arising in the realm of computer networks.” Applicant further submits “Thus, like the claims in DDR Holdings, the instant claims improve upon computer functionality by generating a graphical user interface that presents information from various sources, thereby providing a similar multi-source hybrid interface.” [Applicant’s Remarks, 04/30/2026, pages 15, 17]
With respect to Applicant’s argument reading “the claims in DDR Holdings, the instant claims improve upon computer functionality by generating a graphical user interface that presents information from various sources, thereby providing a similar multi-source hybrid interface,” the Examiner emphasizes that, while the claims in DDR were directed toward addressing problems related to retaining Web site visitors from being diverted from a host's Web site to an advertiser's Web site such that the claimed solution is necessarily rooted in computer technology, DDR’s claims are distinguishable from Applicant’s claims because the steps leading to displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams; wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task, as recited in Applicant’s claim 1, are not reasonably understood as providing a solution narrowly rooted in computing technology as in DDR. Furthermore, it bears emphasis that Applicant’s claims are not confined to, nor do the claims purport to, provide an improvement to the generation of a web page or to an Internet-centric problem. Instead, the claims merely employ a general purpose computer to perform the abstract idea. Therefore, in contrast to the claims in DDR, there is simply no discernible improvement to any existing technological process, webpage or network, or to a computer itself. Accordingly, Applicant’s suggestion that the claims are eligible for the same reason as set forth in the DDR decision is not persuasive.
13. Applicant submits “Similar to Core Wireless, the instant claims also amount to significantly more because they recite an improved user interface for computing devices.” [Applicant’s Remarks, 04/30/2026, page 17]
In response to the Applicant’s arguments that the claims provide improvements similar to the improvement in Core Wireless Core Wireless Licensing S.A.R.L. v. LG Electronics, Inc., the Examiner respectfully disagrees. With respect to Applicant's comparison to Core Wireless, Examiner points out that the claims in Core Wireless involved to an improved user interface for computing devices, which was not an abstract idea. While the generic idea of summarizing information was known, the claims were directed to a “particular manner of summarizing and presenting information in electronic devices” that improved the efficiency of the electronic device over the prior art. As stated in Core Wireless, the claim recites a computing device comprising a display screen, the computing device being configured to display on the screen a menu listing one or more applications, and additionally being configured to display on the screen an application summary that can be reached directly from the menu, wherein the application summary displays a limited list of data offered within the one or more applications, each of the data in the list being selectable to launch the respective application and enable the selected data to be seen within the respective application, and wherein the application summary is displayed while the one or more applications are in an un-launched state. The claims at issue are far different from the claims in Core Wireless. The claims of the present case involve displaying a second task according to metadata on a workspace GUI of a first dashboard GUI that corresponds to a corresponding one of streams. Displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task does not improve the efficiency of the computer. The claims of the instant application are not directed to an improved user interface for computing devices, as the claims in Core Wireless recite. Here, the claim merely displays a second task and a plurality of panels. In the claims/specification here for example, there is no improved interface, improved navigation between menus, or ability to see statuses in un-launched states, as in Core Wireless. Accordingly, this argument is found unpersuasive.
Lastly, Applicant’s arguments with respect to the §101 rejection of claims 1-20 has been considered, but are primarily raised in support of the new limitations and therefore are believed to be fully addressed in the updated §101 rejection below.
14. Applicant’s remaining arguments either logically depend from the above-rejected arguments, in which case they too are unpersuasive for the reasons set forth above, or they are directed to features which have been newly added via amendment. Therefore, this is now the Examiner's first opportunity to consider these limitations and as such any arguments regarding these limitations would be inappropriate since they have not yet been examined. A full rejection of these limitations will be presented later in this Office Action.
Claim Rejections - 35 USC § 101
15. 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.
16. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the method (claims 1-7), system (claims 8-14), and non-transitory computer-readable device (claims 15-20), are directed to at least one potentially eligible category of subject matter (i.e., process, machine, and article of manufacture, respectively). Thus, Step 1 of the Subject Matter Eligibility test for claims 1-20 is satisfied.
With respect to Step 2A Prong One, it is next noted that the claims recite an abstract idea that falls into the “Certain Methods of Organizing Human Activity” abstract idea grouping set forth in MPEP 2106 because the claims recite steps for managing tasks, which encompasses activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions). With respect to independent claim 1, the limitations reciting the abstract idea are indicated in bold below: generating, by a messaging server, a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams, each stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream; receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams; generating, by a messaging server, a task GUI comprising one or more parameters for the second task in the corresponding one of the streams; receiving, by the messaging server and via the task GUI, a second command specifying the one or more parameters; generating, by the messaging server, metadata reflecting the one or more parameters as specified by the second command; storing, by the messaging server, the metadata in a database; displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams; wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task. These steps are organizing human activity by managing interactions between people by following rules, or instructions. The claim recites limitations that fall under the “Certain Methods of Organizing Human Activity” abstract idea grouping because the limitations relate to managing tasks within a work stream based on user roles and permission, which constitutes organizing human activity, including workplace collaboration and task coordination.
Therefore, because the limitations above set forth activities falling within the “Certain methods of organizing human activity” abstract idea grouping described in MPEP 2106, the additional elements recited in the claims are further evaluated, individually and in combination, under Step 2A Prong Two and Step 2B below. Independent claims 8 and 15 recite similar limitations as those discussed above and are therefore found to recite the same or substantially the same abstract idea as claim 1.
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. With respect to the independent claims, the additional elements are: a messaging server, a first dashboard graphical user interface (GUI), a task GUI, a database, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, and wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (claim 1), a database, a messaging server configured to, a first dashboard graphical user interface (GUI), a task GUI, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (claim 8), a non-transitory computer-readable device having instructions stored thereon that, at least one computing device, a first dashboard graphical user interface (GUI), a task GUI, a database, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (claim 15). These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h). Even if the “receiving” and “displaying” steps are evaluated as additional elements, these steps amount at most to insignificant extra-solution data gathering or output activity, which is not indicative of a practical application, as noted in MPEP 2106.05(g). See MPEP 2106.05(g). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. With respect to the independent claims, the additional elements are: a messaging server, a first dashboard graphical user interface (GUI), a task GUI, a database, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, and wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (claim 1), a database, a messaging server configured to, a first dashboard graphical user interface (GUI), a task GUI, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (claim 8), a non-transitory computer-readable device having instructions stored thereon that, at least one computing device, a first dashboard graphical user interface (GUI), a task GUI, a database, a client device, a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams, wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (claim 15).These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment and does not amount to significantly more than the abstract idea itself. Notably, Applicant’s Specification suggests that virtually any type of computing device under the sun can be used to implement the claimed invention (Specification at paragraphs [0037, 0098]). Accordingly, the generic computer involvement in performing the claim steps merely serves to generally link the use of the judicial exception to a particular technological environment, which does not add significantly more to the claim. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976.).
With respect to the “receiving” and “displaying” steps, these steps amount to insignificant extra-solution activity, which does not amount to a practical application (MPEP 2106.05(g)), nor add significantly more because such activity has been recognized as well-understood, routine, and conventional and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d) - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent claims 2-7, 9-14, and 16-20 recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One are found to merely recite details that serve to narrow the same abstract idea recited in the independent claims accompanied by the same generic computing elements or software as those addressed above in the discussion of the independent claims, which is not sufficient to amount to a practical application or add significantly more, or other additional elements that fail to amount to a practical application or add significantly more, as noted above. In particular, dependent claims 2-7 recite “wherein the receiving the second command specifying the one or more parameters comprises receiving a command specifying at least one of a name, a type, a tag, a status, a tracked time, a priority level, a deadline, a description, or one or more assigned users,” “wherein the storing the metadata comprises storing the metadata as a task template reflecting the one or more parameters as specified by the second command,” “wherein each stream further comprises at least one calendar; and display at least one of meetings, appointments, or reminders based on the at least one calendar,” “wherein the displaying the second task comprises displaying the second task as specified in the permissions such that the user is able to view or modify contents of the corresponding one of the streams only if the user has a role allowed within the permissions,” “further comprising receiving a third command to edit the one or more parameters for the second task,” “further comprising displaying the second task according to the metadata,” however these limitations cover activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), which is part of the same abstract idea as addressed in the independent claims that falls within the “Certain Methods of Organizing Human Activity” abstract idea grouping. The dependent claims recite additional elements of: wherein the workspace GUI further comprises at least one calendar panel (claims 4, 11), a second dashboard GUI that comprises at least one task panel, at least one status panel, and at least one data reporting panel (claims 7, 14, 20). However, when evaluated under Step 2A Prong Two and Step 2B, these additional elements do not amount to a practical application or significantly more since they merely require generic computing devices (or computer-implemented instructions/code) which as noted in the discussion of the independent claims above is not enough to render the claims as eligible.
The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself.
For more information, see MPEP 2106.
Claim Rejections - 35 USC § 103
17. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
18. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
19. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
20. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
21. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Matsuoka et al., Pub. No.: US 2023/0074736 A1, [hereinafter Matsuoka], in view of Figlin, Pub. No.: US 2016/0140501 A1, [hereinafter Figlin], in further view of Chen et al., Pub. No.: US 2016/0224939 A1, [hereinafter Chen].
As per claim 1, Matsuoka teaches a computer-implemented method (paragraph 0004: “a computer-implemented method is provided”), comprising:
generating, by a messaging server, a first dashboard graphical user interface (GUI) comprising a stream (paragraph 0068, discussing that an interface provided by the task facilitation service, may be presented with the submitted message. Accordingly, the representative may evaluate the message and generate a corresponding task that is to be performed to assist the member. For instance, the representative, via the interface provided by the task facilitation service, may access a task generation form, through which the representative may provide information related to the task; paragraph 0076, discussing that the task facilitation service automatically generates a specific chat corresponding to the task…; paragraph 0110, discussing that if the member selects an option for manual entry of a task, the task facilitation service may provide, via an interface of the application or web portal, a task template through which the member may enter various details related to the task. The task template may include various fields through which the member may provide a name for the task, a description of the task, a timeframe for performance of the task (e.g., a specific deadline date, a date range, a level of urgency, etc.), a budget for performance of the task, and the like),
generating, by a messaging server, a task GUI comprising graphical user interface (GUI) that includes one or more parameters (paragraph 0068, discussing that an interface provided by the task facilitation service, may be presented with the submitted message. Accordingly, the representative may evaluate the message and generate a corresponding task that is to be performed to assist the member. For instance, the representative, via the interface provided by the task facilitation service, may access a task generation form, through which the representative may provide information related to the task. The information may include various parameters of the task itself (e.g., allocated budget, timeframe for completion of the task, and the like); paragraph 0069, discussing that the representative can provide the information obtained from the member for the task specified in the one or more messages to a task recommendation system of the task facilitation service to dynamically, and in real-time, identify any additional task parameters that may be required for generating one or more proposals for completion of the task…In an embodiment, the task recommendation system provides the representative with an interface through which the representative may generate a task that may be presented to the member over the chat session…For instance, the representative may provide a name for the task, any known parameters of the task as provided by the member (e.g., budgets, timeframes, task operations to be performed, etc.), and the like; paragraph 0076, discussing that the task facilitation service automatically generates a specific chat corresponding to the task…; paragraph 0110, discussing that if the member selects an option for manual entry of a task, the task facilitation service may provide, via an interface of the application or web portal, a task template through which the member may enter various details related to the task. The task template may include various fields through which the member may provide a name for the task, a description of the task, a timeframe for performance of the task (e.g., a specific deadline date, a date range, a level of urgency, etc.), a budget for performance of the task, and the like; paragraph 0117);
receiving, by the messaging server and via the task GUI, a second command specifying the one or more parameters (paragraph 0074, discussing determining whether additional member input is needed for creation of a proposal that may be presented to the member for completion of the task. The task recommendation system, for instance, may process the generated task and information corresponding to the member from the user datastore using a machine learning algorithm or artificial intelligence to automatically identify additional parameters for the task, as well as any additional information that may be required from the member for the generation of proposals; paragraph 0075, discussing that if the task recommendation system determines that additional member input is required for the task, the task recommendation system may provide the representative with recommendations for questions that may be presented to the member regarding the task…the task recommendation system may provide a recommendation to the representative to prompt the member to provide these one or more parameters. The representative may review the recommendations provided by the task recommendation system and, via the chat session, prompt the member to provide the additional task parameters; paragraph 0077, discussing that once the representative has obtained the necessary task-related information from the member and/or through the task recommendation system (e.g., task parameters garnered via evaluation of tasks performed for similarly situated members, etc.), the representative can utilize a task coordination system of the task facilitation service to generate one or more proposals for resolution of the task. The task coordination system may be implemented using a computer system or as an application or other executable code implemented on a computer system of the task facilitation service; paragraphs 0079, 0110);
generating, by the messaging server, metadata reflecting the one or more parameters as specified by the command (paragraph 0132, discussing that using the user recording, the task recommendation system may further utilize computer vision or other artificial intelligence to evaluate the identified room to identify one or more parameters associated with the painting task (e.g., a possible budget for completion of the painting task, etc.). Thus, the task recommendation system may utilize computer vision, NLP, and/or other machine-learning algorithms or artificial intelligence to process user recordings to identify possible tasks and parameters associated with these identified possible tasks; paragraph 0306, discussing that the task facilitation service receives task-related data from an application executed on computing device through a corresponding API. The task-related data may be task data (e.g., data corresponding to a parameter of a task or potential task) or user data);
storing, by the messaging server, the metadata in a database (paragraph 0045, discussing that the process of generating or recommending a task includes obtaining data associated with the member...The obtained data may correspond to information provided by the member and stored in association with the user model; paragraph 0062, discussing that data associated with the member collected during the onboarding process, as well as any data corresponding to the selected representative, may be stored in a user datastore…messages exchanged over the chat session or stream may be recorded in the user datastore; paragraph 00080, discussing that the recommendation provided by the task recommendation system may be stored in the task datastore; paragraph 0091, discussing that the information collected by the task facilitation service may be stored in a resource library or other repository accessible to the task recommendation system; paragraph 0117, discussing that messages exchanged between the member and the representative may be processed by the task recommendation system to identify potential projects and/or tasks that may be recommended to the representative for presentation to the member. As noted above, the task recommendation system may utilize NLP (Natural Language Processing) or other artificial intelligence to evaluate exchanged messages or other communications from the member to identify possible tasks that may be recommended to the member. For instance, the task recommendation system may process any incoming messages from the member using NLP to detect a new project, new task, or other issue that the member would like to have resolved. In some instances, the task recommendation system may utilize historical task data and corresponding messages from a task datastore to train the NLP to identify possible tasks. If the task recommendation system identifies one or more possible projects and/or tasks that may be recommended to the member, the task recommendation system may present these possible tasks to the representative, which may select projects and/or tasks that can be shared with the member over the chat session; paragraph 0138, discussing that the task-facilitation service, via the data model, can dictate that all published data is to include metadata that specifies the time of data generation; paragraph 0188, discussing that once a potential task is defined by the member,…, or the like, a task specification may be generated that encapsulates the data associated with the task. The data may be structured (e.g., according to type, source, time, and/or the like) or unstructured (e.g., stored in a same or similar format as it is received from a respective information source); paragraphs 0074, 0130, 0134);
displaying, by the messaging server and at a client device, the task according to the metadata on a workspace GUI that includes at least one chat panel (paragraph 0076, discussing that through this task-specific chat, the member and the representative may exchange messages related to the particular task. For example, through this task-specific chat, the representative may prompt the member for information that may be required to determine one or more parameters of the task. Similarly, if the member has questions related to the particular task, the member may provide these questions through the task-specific chat…; paragraph 0082, discussing that the data collected from a member over a chat session with the representative may be evaluated by the task recommendation system to identify one or more tasks that may be presented to the member for completion; paragraph 0087, discussing that the data collected from a member over a chat session with the representative may be evaluated by the task recommendation system to identify one or more tasks that may be presented to the member for completion; paragraph 0086, discussing a final determination as to which tasks may be presented to the member through task-specific interfaces (e.g., a communications session specific to these tasks, etc.; paragraph 0115, discussing identifying one or more tasks that may be involved with this project and generate these one or more tasks for presentation to the member…These tasks may be presented to the member via an interface specific to the project to allow the member to evaluate each of these tasks associated with the project; paragraphs 0079, 0307).
Matsuoka does not explicitly teach a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams, each stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream; receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams; generating, by a messaging server, a task GUI comprising one or more parameters for the second task in the corresponding one of the streams; generating, by the messaging server, metadata reflecting the one or more parameters as specified by the second command; displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams; wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task. Figlin in the analogous art of task management systems teaches:
each stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream (paragraph 0015, discussing an execution environment for assignment, management, and completion of tasks; paragraph 0030, discussing that the deployment cockpit can make visible to other team members responsibilities of other team members and the status of a task, providing a clear understanding of responsibilities and statuses of each team member. The visibility can be adjustable based on the permissions associated with each user; paragraph 0037, discussing that sections of the workspace can facilitate and encourage teamwork. The method can design, collect, and invite team members. For example, invited team members can be listed in a team section of the workspace and be granted permission to access the workspace. The method can display team members, respective tasks, and/or access permissions to a GUI; paragraph 0048, discussing that access to the project workspace provided through a link, can include security features to limit access to particular user(s). A new member can be automatically granted permission to access the project space via the link or from a GUI of a deployment cockpit. Team members can be added to a project workspace through a team members section of the GUI. The team members section can be a sidebar of the GUI that can be displayed or hidden via button. To add or remove team members to a project, the team members bar can be loaded with input areas. Selection of add button 704 can trigger display of a GUI, e.g., as a pop-up window, which can receive input for storage and association with a team member. Information related to a team member can be collected, including a user identification number. In an embodiment, the identification number can provide information regarding the type of user. Different categories of users can have different prefixes. For example, an employee can have an identification number prefix “D, C, or I,” while partners and customers can have a prefix, “S.” A flag can indicate editing permissions granted to a user. For example, partners and customers can post or upload internal information not viewable by other users. This can prevent internal or confidential information from being exposed to outsiders…; paragraph 0052, discussing that the GUI can include a selectable link to load a default view of a task management interface. A task area of the GUI can display tasks….Selection of a task, e.g., “Task 11” as shown can cause another section of the GUI to load details of the task, including staffing requirements, status, documents, templates, and a message board… The documents section can receive input of at least one format, e.g., uploads of documents. The documents section can also display documents that have been uploaded and/or are available for team members to read and/or download. The message board can be an area integrated with the GUI, a pop-up window, or a re-direction to another GUI. The message board can be an area in which information or questions can be posted to the team. Messages can be displayed to a subset of team members. For example, internal information can be displayed to partners…; paragraphs 0038, 0050); and
wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (paragraph 0045, discussing that the GUI 600 can include a selectable button 602 to trigger loading of a default view of the GUI, buttons 604, 608, 618 to trigger display details of the GUI, button 614 to trigger storing of any changes made to the GUI, and button 616 to display details regarding phases of tasks. Phases 616 and deliverables displayed in the GUI can be selectable to display or hide details of the phase and/or deliverable…Details of a task can also be displayed, e.g., in area 606; paragraph 0046, discussing that details can be retrieved and displayed responsive to selection of a task name. The details can be displayed in a side panel of the GUI. The GUI can receive queries, e.g., phrases, deliverables or tasks. The queries can be entered, e.g., as a search string, in a search box of the GUI. In an embodiment, results based on the query can be automatically loaded…; paragraph 0049, discussing that the GUI can include a link for loading a default view of an assignment workspace. The GUI can also include a button for triggering editing of assignments, e.g., alerting the system to poll for inputs defining task assignments…; paragraph 0052, discussing that the GUI can include a selectable link to load a default view of a task management interface. A task area [i.e., task panel] of the GUI can display tasks….Selection of a task, e.g., “Task 11” as shown can cause another section of the GUI to load details of the task, including staffing requirements, status, documents, templates, and a message board… The documents section [i.e., file panel] can receive input of at least one format, e.g., uploads of documents. The documents section can also display documents that have been uploaded and/or are available for team members to read and/or download. The message board [i.e., chat panel] can be an area integrated with the GUI, a pop-up window, or a re-direction to another GUI. The message board can be an area in which information or questions can be posted to the team. Messages can be displayed to a subset of team members. For example, internal information can be displayed to partners…; paragraph 0056).
Matsuoka is directed towards a system and method for task facilitation. Figlin is directed towards a system and method for task assignment. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Matsuoka with Figlin because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying Matsuoka to include Figlin’s features for including each stream comprising at least one chat channel, at least one file, at least one task, and permissions specifying which role a user must have to access the stream and wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task, in the manner claimed, would serve the motivation of better supporting project collaboration and facilitating management and identification of new tasks (Figlin, paragraphs 0022, 0057); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The Matsuoka-Figlin combination does not explicitly teach a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams; receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams; generating, by a messaging server, a task GUI comprising one or more parameters for the second task in the corresponding one of the streams; generating, by the messaging server, metadata reflecting the one or more parameters as specified by the second command; and displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams. However, Chen in the analogous art of task management systems teaches these concepts. Chen teaches:
generating, by a messaging server, a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams (paragraph 0023, discussing a computer-implemented method for managing tasks; paragraph 0133, discussing an example user interface for task management…The user interface can include multiple windows configured to display information and to receive inputs from the user(s) by way of various input devices. For example, the user interface can include a user profile or summary box. The user profile box can display identifying information about the user…; paragraph 0134, discussing that the user interface can also include a list of user communities and/or contacts...Further, a list of active tasks may also be displayed on the user interface. The user may select a particular task to manipulate task content data and/or to interface with participants in the particular task. For example, the list of active tasks may be used to select a particular task that a user would like work on at that moment; paragraph 0135, discussing that the user interface can include a real-time messaging window that can provide for real-time communications among task participants. For example, the messaging window can include a real-time messaging window for the exchange of electronic text messages…The user interface may also include a document sharing window that displays a list of documents that are relevant to a particular task);
receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams (paragraph 0015, discussing that the system can further include a task creation module programmed to process the message to identify task information and one or more task recipients. The task creation module can also be programmed to create a task based on the identified task information. The system can include a task notification module programmed to notify the one or more task recipients about the created task; paragraph 0052, discussing that the tasks can be created and assigned over the one or more communications networks, and task content data can be shared among the employees across the network(s); paragraph 0147, discussing that users create tasks; paragraph 0181, discussing that when a task has been accepted, completed, begun, etc., as explained above, the status field for Tasks 1, 2, or 5 may be appropriately update; paragraph 0102);
generating, by a messaging server, a task GUI comprising one or more parameters for the second task in the corresponding one of the streams (paragraph 0052, discussing that a company or organization may set up one or more communications networks to connect its employees to one another. The employees of the company or organization may participate in various projects, and each project can include one or more tasks…These tasks can be assigned to multiple employees to complete over a predetermined timeline or schedule…The tasks can be created and assigned over the one or more communications networks, and task content data can be shared among the employees across the network(s)…Any type of scheduled event managed by one or more parties can be used within embodiments of the system to track and manage their progress towards task completion. In addition to managing tasks to be performed by task participants, the system can also manage and organize documents associated with the tasks and task participants. The system can employ a user interface to share documents among task participants and can ensure that task participants are accountable for tasks that they are assigned to complete; paragraph 0054, discussing that a record is created in the task management system corresponding to the new task. This record would include information regarding the task, its timeline for completion, and the parties that are involved in working on the task; paragraph 0055, discussing that the webpage may also display a calendar of due dates or milestones for the project, and also allow authorized individuals associated with the task to modify task parameters or add/remove individuals from the task; paragraph 0092);
generating, by the messaging server, metadata reflecting the one or more parameters as specified by the second command (paragraph 0102, discussing that the task management system can include multiple modules that can be implemented and/or stored on a server. The task management system can include a task management module, which can include a task creation module, an object management module, and a user interface module. The task creation module can include a task creation database that processes and stores the task creation packets received from the task creators. The task creation database can therefore include data structures that store data received for a plurality of tasks. For example, the task creation database can store an array of the task identifiers, task creator entries, task recipients entries, task content data, server addresses that identify the addresses of the servers hosting the tasks, and network IDs that identify to which network a user logs in. For example, a user can create a task within a particular network, e.g., Network 1, and the task may thereby be associated with Network 1 by way of the network ID 324. Thus, for each task creation packet that is received by the server, the task management system can process and store the information contained in the packet in the task creation database. In order to process the information received in the packets, the task creation module can further include instructions for identifying and sorting the information in the packets); and
displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the streams (paragraph 0104, discussing that the user interface module can include various modules for processing, sorting, and displaying task information. In some implementations, for example, the task information, e.g., information about the task and task assignments, can be shared among the task participants using the user interface module. The user interface module can include a task assignment module. The task assignment module can be configured to assign portions or divisions of the task to one or more task participants associated with the task. For example, referring back to the examples of FIG. 2A, User 1 may be the task creator, and may assign various tasks to Users 2 and 3, such as, e.g., assigning responsibility for completing various portions of the widget in the final product design. The task creator, or User 1, may also be assigned with a portion of the task; paragraph 0123, discussing that an active tasks field can include a list of all the tasks in which the user is currently participating. Further, an associated documents field can list documents that are associated with the user and/or the tasks associated with the user).
Examiner notes that Chen, in addition to Figlin as cited above, also teaches: receiving, by the messaging server and via the task GUI, a second command specifying the one or more parameters (paragraph 0055, discussing that after the record has been created, the task management system, in one embodiment, may send out a link to a webpage that manages that task and any communication between the parties regarding the task. For example, the task management system may create an electronic chat room specific to the task so that the parties can review and post messages regarding the task that do not need to circulate through email. The webpage may also display a calendar of due dates or milestones for the project, and also allow authorized individuals associated with the task to modify task parameters; paragraph 0092, discussing that the task creation packet can include a task identifier that uniquely identifies the task. Because the server may process multiple tasks from multiple users, it can be important to ensure that the tasks are accurately sorted such that each task received by the server is accurately assigned to the correct users and that each task includes the correct information for the task. The task creation packet can also include a task creator entry that identifies the task creator. For example, the task creator entry can include the name and/or the username of the task creator; paragraph 0094, discussing that the task creation packet can also include task content data. The task content data can include details of the task, such as the overall goals and objectives of the task. The task content data can also include a listing of the task assignments that are assigned to each user associated with the task. Further, the task content data can include a task schedule that manages the progression of the task. The task content data can also include various accountability measures, such as a schedule of reminder notification that can be sent to the task participants to remind them of their assignments; paragraph 0191, discussing that a user can create a computer object (such as a task); paragraph 0192); and
wherein the workspace GUI comprises a plurality of panels arranged according to a user-specified layout, the plurality of panels comprising at least one chat panel corresponding to the at least one chat channel, at least one file panel corresponding to the at least one file, and at least one task panel corresponding to the at least one task (paragraph 0133, discussing an example user interface for task management…The user interface can include multiple windows configured to display information and to receive inputs from the user(s) by way of various input devices; paragraph 0134, discussing that the user interface can also include a list of user communities and/or contacts...Further, a list of active tasks may also be displayed on the user interface. The user may select a particular task to manipulate task content data and/or to interface with participants in the particular task. For example, the list of active tasks may be used to select a particular task that a user would like work on at that moment; paragraph 0135, discussing that the user interface can include a real-time messaging window that can provide for real-time communications among task participants. For example, the messaging window can include a real-time messaging window for the exchange of electronic text messages…The user interface may also include a document sharing window that displays a list of documents that are relevant to a particular task).
The Matsuoka-Figlin combination describes features related to task management. Chen is directed towards a system and method for managing tasks. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Matsuoka-Figlin combination with Chen because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying the Matsuoka-Figlin combination to include Chen’s features for including a first dashboard graphical user interface (GUI) comprising an index listing a plurality of streams, receiving, by the messaging server and via the first dashboard GUI, a first command to create a second task for a corresponding one of the streams, generating, by a messaging server, a task GUI comprising one or more parameters for the second task in the corresponding one of the streams, generating, by the messaging server, metadata reflecting the one or more parameters as specified by the second command, and displaying, by the messaging server and at a client device, the second task according to the metadata on a workspace GUI of the first dashboard GUI that corresponds to the corresponding one of the stream, in the manner claimed, would serve the motivation of enabling users to efficiently manage the various tasks that are required for a project (Chen, paragraph 0005); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 2, the Matsuoka-Figlin-Chen combination teaches the computer-implemented method of claim 1. Matsuoka further teaches wherein the receiving the second command specifying the one or more parameters comprises receiving a command specifying at least one of a name, a type, a tag, a status, a tracked time, a priority level, a deadline, a description, or one or more assigned users (paragraph 0068, discussing that the information may include various parameters of the task itself (e.g., allocated budget, timeframe for completion of the task, and the like); paragraph 0110, discussing that if the member selects an option for manual entry of a task, the task facilitation service may provide, via an interface of the application or web portal, a task template through which the member may enter various details related to the task. The task template may include various fields through which the member may provide a name for the task, a description of the task, a timeframe for performance of the task (e.g., a specific deadline date, a date range, a level of urgency, etc.), a budget for performance of the task, and the like; paragraph 0128).
As per claim 3, the Matsuoka-Figlin-Chen combination teaches the computer-implemented method of claim 1. Matsuoka further teaches wherein the storing the metadata in the database comprises storing the metadata as a task template reflecting the one or more parameters as specified by the second command (paragraph 0071, discussing that the resource library may serve as a repository for different task templates corresponding to different task categories. A task template may include a plurality of task definition fields that may be used to define a task…Thus, each task template maintained in the resource library may include fields that are specific to the task category associated with the task template; paragraph 0110, discussing that if the member selects an option for manual entry of a task, the task facilitation service may provide, via an interface of the application or web portal, a task template through which the member may enter various details related to the task. The task template may include various fields through which the member may provide a name for the task, a description of the task, a timeframe for performance of the task (e.g., a specific deadline date, a date range, a level of urgency, etc.), a budget for performance of the task, and the like); paragraph 0162, discussing that a task template corresponding to the task type or category for the task being defined. The representative, via the task template, may define various parameters associated with new task or project, including assignment of the task; paragraph 0163).
As per claim 4, the Matsuoka-Figlin-Chen combination teaches the computer-implemented method of claim 1. While Matsuoka teaches a calendar (paragraph 0252, discussing that a member may maintain information regarding a given task within each of an application associated with the task facilitation service and a third-party application, such as a calendar or task management application; paragraph 0258, discussing that the computing device may execute a third-party calendar application for member that provides various time management and calendaring features), Matsuoka does not explicitly teach wherein each stream further comprises at least one calendar; and wherein the workspace GUI further comprises at least one calendar panel configured to display at least one of meetings, appointments, or reminders based on the at least one calendar. Figlin in the analogous art of task management systems teaches:
wherein each stream further comprises at least one calendar (paragraph 0043, discussing that the GUI can display data grouped in several areas. The GUI can display information retrieved from a bid project, including customer data, services, scope items, recent messages, and project attributes. Project attributes can include a project timescale, timeline, timeframe, and/or status. A user, e.g., a project leader, can verify project scope received from a bid project and specify a project time frame, e.g., a start date and a go-live date. Selection of overview can display a summary of project information. Verification area can display attributes such as services, scope items, and project scope items. A link such as bid project link can display or be selected to open a bid cockpit or solution configurator, enabling a user to view bid project details upon which the deployment project is based. Area 506 can receive input and/or display various milestone dates for the project. The input can include a calendar function [i.e., calendar panel] to visually display a date option. Status can display a status of a project, e.g., that a project has been created. The status can also define which certain users can access the project workspace. For example, the system may specify that the project status be “created” to allow for editing of the WBS (work breakdown structure of the project; FIG. 5, element 506).
Matsuoka is directed towards a system and method for task facilitation. Figlin is directed towards a system and method for task assignment. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Matsuoka with Figlin because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying Matsuoka to include Figlin’s feature for including wherein each stream further comprises at least one calendar, in the manner claimed, would serve the motivation of better supporting project collaboration and facilitating management and identification of new tasks (Figlin, paragraphs 0022, 0057); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The Matsuoka-Figlin combination does not explicitly teach wherein the workspace GUI further comprises at least one calendar panel configured to display at least one of meetings, appointments, or reminders based on the at least one calendar. However, Chen in the analogous art of task management systems teaches this concept. Chen teaches:
wherein the workspace GUI further comprises at least one calendar panel configured to display at least one of meetings, appointments, or reminders based on the at least one calendar (paragraph 0055, discussing that the webpage may also display a calendar of due dates or milestones for the project, and also allow authorized individuals associated with the task to modify task parameters or add/remove individuals from the task; paragraph 0137, discussing that a calendar and/or a schedule of tasks can be presented in the user interface. The calendar can list the portions of a task that are assigned to the user and can enforce accountability for timely performance of the task. In some embodiments, the user can check off assignments that have been completed and may prioritize the remaining assignments. In some arrangements, other users can view the user's calendar, and/or notifications may be sent to all task participants when the user completes an assignment…Skilled artisans will appreciate that other windows may be presented on the user interface; paragraph 0176, discussing that In the user inbox-outbox interface, all the objects associated with User 1 are displayed, as the “show-all” option is selected. In some arrangements, the inbox-outbox interface can include an object field, an object type field, an object content field, a status field, and a due date field. For example, in the first line illustrated in the interface, “Task 1” is the name of the object listed in the object field. The object type field indicates that Task 1 is a task, and the object content field describes the task content, e.g., the task information, which for Task 1 includes meeting with Vendor to discuss their sales strategy for a particular product…; paragraph 0178).
The Matsuoka-Figlin combination describes features related to task management. Chen is directed towards a system and method for managing tasks. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Matsuoka-Figlin combination with Chen because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying the Matsuoka-Figlin combination to include Chen’s feature for including wherein the workspace GUI further comprises at least one calendar panel configured to display at least one of meetings, appointments, or reminders based on the at least one calendar, in the manner claimed, would serve the motivation of enabling users to efficiently manage the various tasks that are required for a project (Chen, paragraph 0005); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 5, the Matsuoka-Figlin-Chen combination teaches the computer-implemented method of claim 1. Although not explicitly taught by Matsuoka, Figlin in the analogous art of task management systems teaches wherein the displaying the task comprises displaying the task on the workspace GUI as specified in the permissions such that the user is able to view or modify contents of the corresponding one of the streams only if the user has a role allowed within the permissions (paragraph 0030, discussing that the deployment cockpit can have increased transparency compared with typical implementations for project execution, e.g., a project team, including customers and partners, can monitor progress of a project. For example, the deployment cockpit can make visible to other team members responsibilities of other team members and the status of a task (e.g., level of completion), providing a clear understanding of responsibilities and statuses of each team member. The visibility can be adjustable based on the permissions associated with each user; paragraph 0034, discussing that the user can be informed of access permissions to a corresponding deployment project space; paragraph 0037, discussing that sections of the workspace can facilitate and encourage teamwork. The method can design, collect, and invite team members. For example, invited team members can be listed in a team section of the workspace and be granted permission to access the workspace. The method can display team members, respective tasks, and/or access permissions to a GUI; paragraph 0041, discussing /security features to limit access to particular user(s); paragraph 0050, discussing that team members can be categorized and granted different editing capabilities…).
Matsuoka is directed towards a system and method for task facilitation. Figlin is directed towards a system and method for task assignment. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Matsuoka with Figlin because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying Matsuoka to include Figlin’s feature for including wherein the displaying the task comprises displaying the task on the workspace GUI as specified in the permissions such that the user is able to view or modify contents of the stream only if the user has a role allowed within the permissions, in the manner claimed, would serve the motivation of better supporting project collaboration and facilitating management and identification of new tasks (Figlin, paragraphs 0022, 0057); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The Matsuoka-Figlin combination does not explicitly teach wherein the displaying the second task comprises displaying the second task on the workspace GUI as specified in the permissions such that the user is able to view or modify contents of the corresponding one of the streams stream only if the user has a role allowed within the permissions. However, Chen in the analogous art of task management systems teaches this concept. Chen teaches:
wherein the displaying the second task comprises displaying the second task on the workspace GUI as specified in the permissions such that the user is able to view or modify contents of the corresponding one of the streams stream only if the user has a role allowed within the permission (paragraph 0022, discussing that the integrated interface module can be programmed to indicate the assigned status on the graphical user interface to each of the authorized users associated with the computer object; paragraph 0054, discussing that a record is created in the task management system corresponding to the new task. This record would include information regarding the task, its timeline for completion, and the parties that are involved in working on the task; paragraph 0055, discussing that the webpage may also display a calendar of due dates or milestones for the project, and also allow authorized individuals associated with the task to modify task parameters or add/remove individuals from the task; paragraph 0104, discussing that the user interface module can include various modules for processing, sorting, and displaying task information. In some implementations, for example, the task information, e.g., information about the task and task assignments, can be shared among the task participants using the user interface module. The user interface module can include a task assignment module. The task assignment module can be configured to assign portions or divisions of the task to one or more task participants associated with the task. For example, referring back to the examples of FIG. 2A, User 1 may be the task creator, and may assign various tasks to Users 2 and 3, such as, e.g., assigning responsibility for completing various portions of the widget in the final product design. The task creator, or User 1, may also be assigned with a portion of the task; paragraph 0103, discussing that the object management module can provide a platform for sharing persistent objects with authorized users. For example, when one user modifies a document or replies to a message, the updated object (e.g., the modified document or replied-to message) may automatically present itself to authorized users so that the users have a persistent object with which to work; paragraph 0181, discussing that the status of the object (e.g., task) can accordingly be updated and presented to authorized users; paragraph 0217).
The Matsuoka-Figlin combination describes features related to task management. Chen is directed towards a system and method for managing tasks. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Matsuoka-Figlin combination with Chen because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying the Matsuoka-Figlin combination to include Chen’s feature for including wherein the displaying the second task comprises displaying the second task on the workspace GUI as specified in the permissions such that the user is able to view or modify contents of the corresponding one of the streams stream only if the user has a role allowed within the permissions, in the manner claimed, would serve the motivation of enabling users to efficiently manage the various tasks that are required for a project (Chen, paragraph 0005); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 6, the Matsuoka-Figlin-Chen combination teaches the computer-implemented method of claim 1. Matsuoka further teaches further comprising receiving, by the messaging server and via the first dashboard GUI, a third command to edit the one or more parameters for the task (paragraph 0069, discussing that the representative can provide the information obtained from the member for the task specified in the one or more messages to a task recommendation system of the task facilitation service to dynamically, and in real-time, identify any additional task parameters that may be required for generating one or more proposals for completion of the task…In an embodiment, the task recommendation system provides the representative with an interface through which the representative may generate a task that may be presented to the member over the chat session…For instance, the representative may provide a name for the task, any known parameters of the task as provided by the member (e.g., budgets, timeframes, task operations to be performed, etc.), and the like; paragraph 0074, discussing determining whether additional member input is needed for creation of a proposal that may be presented to the member for completion of the task. The task recommendation system, for instance, may process the generated task and information corresponding to the member from the user datastore using any additional information that may be required from the member for the generation of proposals; paragraph 0075, discussing that if the task recommendation system determines that additional member input is required for the task, the task recommendation system may provide the representative with recommendations for questions that may be presented to the member regarding the task…the task recommendation system may provide a recommendation to the representative to prompt the member to provide these one or more parameters. The representative may review the recommendations provided by the task recommendation system and, via the chat session, prompt the member to provide the additional task parameters; paragraph 0077, discussing that once the representative has obtained the necessary task-related information from the member and/or through the task recommendation system (e.g., task parameters garnered via evaluation of tasks performed for similarly situated members, etc.), the representative can utilize a task coordination system of the task facilitation service to generate one or more proposals for resolution of the task. The task coordination system may be implemented using a computer system or as an application or other executable code implemented on a computer system of the task facilitation service; paragraph 0110, discussing that if the member selects an option for manual entry of a task, the task facilitation service may provide, via an interface of the application or web portal, a task template through which the member may enter various details related to the task. The task template may include various fields through which the member may provide a name for the task, a description of the task, a timeframe for performance of the task (e.g., a specific deadline date, a date range, a level of urgency, etc.), a budget for performance of the task, and the like; paragraph 0156, discussing that a member interacts with a task creation sub-system of the task recommendation system to generate a new task or project; paragraph 0157, discussing that the member can access the task creation sub-system to request creation of one or more tasks; paragraph 0158, discussing that the task facilitation service may provide, via an application or web portal of the task facilitation service, a widget or other user interface element through which a member may generate a new task or project manually. In some examples, the task creation sub-system provides various task templates that may be used by the member to generate a new task or project…; paragraph 0070).
The Matsuoka-Figlin combination does not explicitly teach receiving, by the messaging server and via the first dashboard GUI, a third command to edit the one or more parameters for the second task. However, Chen in the analogous art of task management systems teaches this concept (paragraph 0055, discussing that after the record has been created, the task management system, in one embodiment, may send out a link to a webpage that manages that task and any communication between the parties regarding the task. For example, the task management system may create an electronic chat room specific to the task so that the parties can review and post messages regarding the task that do not need to circulate through email. The webpage may also display a calendar of due dates or milestones for the project, and also allow authorized individuals associated with the task to modify task parameters; paragraph 0092, discussing that the task creation packet can include a task identifier that uniquely identifies the task. Because the server may process multiple tasks from multiple users, it can be important to ensure that the tasks are accurately sorted such that each task received by the server is accurately assigned to the correct users and that each task includes the correct information for the task. The task creation packet can also include a task creator entry that identifies the task creator. For example, the task creator entry can include the name and/or the username of the task creator; paragraph 0094, discussing that the task creation packet can also include task content data. The task content data can include details of the task, such as the overall goals and objectives of the task. The task content data can also include a listing of the task assignments that are assigned to each user associated with the task. Further, the task content data can include a task schedule that manages the progression of the task. The task content data can also include various accountability measures, such as a schedule of reminder notification that can be sent to the task participants to remind them of their assignments; paragraph 0191, discussing that a user can create a computer object (such as a task); paragraph 0192).
The Matsuoka-Figlin combination describes features related to task management. Chen is directed towards a system and method for managing tasks. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Matsuoka-Figlin combination with Chen because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying the Matsuoka-Figlin combination to include Chen’s feature for including receiving, by the messaging server and via the first dashboard GUI, a third command to edit the one or more parameters for the second task, in the manner claimed, would serve the motivation of enabling users to efficiently manage the various tasks that are required for a project (Chen, paragraph 0005); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 7, the Matsuoka-Figlin-Chen combination teaches the computer-implemented method of claim 1. Although not explicitly taught by Matsuoka, Figlin in the analogous art of task management systems teaches further comprising displaying the second task according to the metadata on a second dashboard GUI that includes comprises at least one task panel, at least one status panel, and at least one data reporting panel (paragraph 0025, discussing that the deployment cockpit can be configured...In an embodiment, a deployment cockpit includes an environment in which one or more users can organize, execute, and track implementation steps, e.g., by following instructions and activity guidelines. The deployment cockpit can be a web-based consumption layer where users can have an overview of projects and/or tasks; paragraph 0030, discussing that deployment cockpit can make visible to other team members responsibilities of other team members and the status of a task (e.g., level of completion); paragraph 0043, discussing that the GUI can display data grouped in several areas. The GUI can display information retrieved from a bid project, including customer data, services, scope items, recent messages, and project attributes. Project attributes can include a project timescale, timeline, timeframe, and/or status; paragraph 0045, discussing that the GUI 600 can include a selectable button 602 to trigger loading of a default view of the GUI, buttons 604, 608, 618 to trigger display details of the GUI, button 614 to trigger storing of any changes made to the GUI, and button 616 to display details regarding phases of tasks. Phases 616 and deliverables displayed in the GUI can be selectable to display or hide details of the phase and/or deliverable…Details of a task can also be displayed, e.g., in area 606; paragraph 0046, discussing that details can be retrieved and displayed responsive to selection of a task name. The details can be displayed in a side panel of the GUI. The GUI can receive queries, e.g., phrases, deliverables or tasks. The queries can be entered, e.g., as a search string, in a search box of the GUI. In an embodiment, results based on the query can be automatically loaded…; paragraph 0049, discussing that the GUI can include a link for loading a default view of an assignment workspace. The GUI can also include a button for triggering editing of assignments, e.g., alerting the system to poll for inputs defining task assignments…; paragraph 0052, discussing that the GUI can include a selectable link to load a default view of a task management interface. A task area of the GUI can display tasks….Selection of a task, e.g., “Task 11” as shown can cause another section of the GUI to load details of the task, including staffing requirements, status, documents, templates, and a message board… ; paragraph 0047).
Matsuoka is directed towards a system and method for task facilitation. Figlin is directed towards a system and method for task assignment. Therefore they are deemed to be analogous as they both are directed towards task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Matsuoka with Figlin because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (system and method for task management), and because modifying Matsuoka to include Figlin’s feature for including further comprising displaying the second task according to the metadata on a second dashboard GUI that includes comprises at least one task panel, at least one status panel, and at least one data reporting panel, and at least one data reporting panel., in the manner claimed, would serve the motivation of better supporting project collaboration and facilitating management and identification of new tasks (Figlin, paragraphs 0022, 0057); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Examiner notes that Chen, in addition to Figlin as cited above, also teaches displaying the second task according to the metadata on a second dashboard GUI that includes comprises at least one task panel, at least one status panel, and at least one data reporting panel (paragraph 0133, discussing an example user interface for task management…The user interface can include multiple windows configured to display information and to receive inputs from the user(s) by way of various input devices; paragraph 0134, discussing that the user interface can also include a list of user communities and/or contacts...Further, a list of active tasks may also be displayed on the user interface. The user may select a particular task to manipulate task content data and/or to interface with participants in the particular task. For example, the list of active tasks may be used to select a particular task that a user would like work on at that moment; paragraph 0069, discussing that as with documents and messages, the tasks stored on the server(s) and presented in the inbox-outbox interface may be updated by the authorized users (e.g., task participants). Authorized users may be notified when the objects are updated. For example, when one user has begun a task, the user may update the task status to “pending.” Similarly, when a user completes a task, the user can update the task status to “completed.” These updated task statuses may be presented to other authorized users on their respective inbox-outbox interfaces; paragraph 0158, discussing that the task analytics module can present a task analytics dashboard (e.g., a user interface) to a system user, such as a company manager or executive. The dashboard can organize, analyze, and clearly present the information that the task analytics module and/or the user management module aggregate regarding the tasks performed by employees or users associated with the particular company or organization).
Claim 8 recites substantially similar limitations that stand rejected via the art citations and
rationale applied to claim 1, as discussed above. Further, as per claim 8 the Matsuoka-Figlin-Chen combination teaches a system (Matsuoka, paragraph 0012: “a system includes one or more processors and memory including instructions that, as a result of being executed by the one or more processors, cause the system to perform the processes described herein. In another aspect, a non-transitory computer-readable storage medium stores thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to perform the processes described…”; paragraph 0383), comprising: a database (paragraph 0025, discussing computing devices such as personal computers, servers, database; paragraph 0062, discussing that as a member interacts with a representative over a chat session or stream, messages exchanged over the chat session or stream may be recorded in the user datastore; paragraph 0078, discussing that the task recommendation system may utilize the information provided by the representative, as well as data for similarly situated members from the user datastore and task data corresponding to similar tasks from a task datastore; paragraphs 0071, 0080); and a messaging server (paragraph 0025, discussing computing devices such as personal computers, servers, database; paragraph 0052, discussing that the task facilitation service may maintain a web server that hosts one or more websites configured to present or otherwise make available an interface through which the member may access the task facilitation service; paragraph 0304, discussing that data is generally referred to as being transmitted or shared by an external application with task facilitation service. This disclosure acknowledges that such data exchange may occur between an instance of the application and task facilitation service, between an application server supporting the application and task facilitation service, or a combination thereof; paragraphs 0352, 0383).
Claims 9 and 16 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 2, as discussed above.
Claims 10 and 17 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 3, as discussed above.
Claim 11 recites substantially similar limitations that stand rejected via the art citations and
rationale applied to claim 4, as discussed above.
Claims 12 and 18 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 5, as discussed above.
Claims 13 and 19 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 6, as discussed above.
Claims 14 and 20 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 7, as discussed above.
Claim 15 recites substantially similar limitations that stand rejected via the art citations and
rationale applied to claim 1, as discussed above. Further, as per claim 15 the Matsuoka-Figlin-Chen combination teaches a non-transitory computer-readable device having instructions stored thereon that, when executed by at least one computing device, causes the at least one computing device to perform operations (Matsuoka, paragraph 0012: “a system includes one or more processors and memory including instructions that, as a result of being executed by the one or more processors, cause the system to perform the processes described herein. In another aspect, a non-transitory computer-readable storage medium stores thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to perform the processes described…”; paragraph 0373: “the term “machine-readable medium” and “machine-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” and “machine-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the system and that cause the system to perform any one or more of the methodologies or modules of disclosed herein.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kim et al., Pub. No.: US 2021/0241600 A1 – describes a screen for enabling a user to create a task on a display.
Hecker et al., Patent No.: US 11,907,187 B1 – describes methods, systems, and devices that enable data stewardship tasks for linking and unlinking internal records associated with subjects, across disparate enterprises, on an enduring basis when the subjects are identified by attributes.
Beringer et al., Pub. No.: US 2013/0014026 A1 – describes techniques for provisioning and performing action items and related graphical user interfaces.
O'hara, Kenton, Jesper Kjeldskov, and Jeni Paay. "Blended interaction spaces for distributed team collaboration." ACM Transactions on Computer-Human Interaction (TOCHI) 18.1 (2011): 1-28 – describes blended spaces in which interactive groupware is incorporated in ways spatially consistent with the physical geometries of the video-mediated set-up.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 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 extension fee 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 DARLENE GARCIA-GUERRA whose telephone number is (571) 270-3339. The examiner can normally be reached M-F 7:30a.m.-5:00p.m. EST.
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, Brian M. Epstein can be reached on (571) 270-5389. 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.
/Darlene Garcia-Guerra/
Primary Examiner, Art Unit 3625
Prosecution Insights