DETAILED ACTION
This action is responsive to Applicant’s reply filed 5 January 2026 (hereinafter “Reply”). This action is made Final.
Status of the Claims
Claims 1 and 14 are currently amended.
Claims 2, 4, 8-9, 11, and 20-22 have been canceled.
Claims 23-28 are newly added.
Claims 1, 3, 5-7, 10, 12-19, and 23-28 are pending.
Notice of AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Claim Interpretation - 35 USC § 112(f)
The following is a quotation of 35 U.S.C. § 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claims 1, 3, 5-7, 10, 12-13, 23, and 25-26 have been interpreted to invoke 35 U.S.C. § 112(f).
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. § 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. § 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. § 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. § 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. § 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. § 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. § 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. § 112(f) except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. § 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim(s) and corresponding limitation(s) is/are:
In claim 1, the limitations: “a user interface module …,” “a document module …,” “a project management module …,” “an email integration module …,” “a communication module …,” “a redline module …,” and “a form generation module ….”
In claim 7, the limitation: “a term definition module ….”
In claim 23, the limitation: “a form generation module ….”
Claims 3, 5-7, 10, 12-13, 23, and 25-26 are also being treated as invoking § 112(f) for substantially the same reasons as indicated above for claim 1, at least due to their dependence on the claim.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. § 112(f) it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. § 112(f) applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. § 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. § 112(f).
Claim Rejections - 35 USC § 112(a)
The following is a quotation of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1, 3, 5-7, 10, 12-19, and 23-28 are rejected under 35 U.S.C. § 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Regarding claim 1, there does not appear to be adequate support for the following newly added limitation: “wherein the user interface comprises a workstream interface configured do display a workstream, and wherein the workstream interface is configured for viewing, editing and transmitting the workstream to other users.”
Applicant has indicated that support for the amendments can be found in figure 6 and paragraphs 34, 35, 40, and 77-83 of the “published application.” Reply 10. However, the referenced portion of the specification does not disclose the above limitation. Rather, the specification discloses that a “user may then interact with the workstream by viewing, editing, or transmitting the workstream to other users.” Specification ¶ 41. The specification provides no description of configuring a graphical user interface for viewing, editing and transmitting the workstream to other users.
Additionally, the claim defines the invention in functional language specifying a desired result. A claim may lack written description support when the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved. MPEP § 2163.03(V). Specifically, a software-related claim must adequately describe, in sufficient detail, a computer and algorithm that achieves the claimed functionality. Id. § 2161.01(I). With regards to the claim at issue, the written description fails to provide an algorithm for configuring a graphical user interface for viewing, editing and transmitting a workstream to other users.
Claims 3, 5-7,10, 12-13, 23, and 25-26 are rejected for substantially the same reason indicated above for claim 1, at least due to their dependence on the claim.
Regarding claim 14, there does not appear to be adequate support for the following newly added limitation: “displaying a workstream on a workstream interface of the user interface, wherein the workstream interface is configured for viewing, editing and transmitting the workstream to other users.”
Applicant has indicated that support for the amendments can be found in figure 6 and paragraphs 34, 35, 40, and 77-83 of the “published application.” Reply 10. However, the referenced portion of the specification does not disclose the above limitation. Rather, the specification discloses that a “user may then interact with the workstream by viewing, editing, or transmitting the workstream to other users.” Specification ¶ 41. The specification provides no description of configuring a graphical user interface for viewing, editing and transmitting the workstream to other users.
Additionally, the claim defines the invention in functional language specifying a desired result. A claim may lack written description support when the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved. MPEP § 2163.03(V). Specifically, a software-related claim must adequately describe, in sufficient detail, a computer and algorithm that achieves the claimed functionality. Id. § 2161.01(I). With regards to the claim at issue, the written description fails to provide an algorithm for configuring a graphical user interface for viewing, editing and transmitting a workstream to other users.
Claims 15-19, 24, and 27-28 are rejected for substantially the same reason indicated above for claim 14, at least due to their dependence on the claim.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 3, 5-7, 10, 12-19, and 23-28 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 1 recites the limitation “wherein the user interface comprises a workstream interface configured to display a workstream, and wherein the workstream interface is configured for viewing, editing and transmitting the workstream to other users.” There is insufficient antecedent basis for the phrase “the user interface.” See MPEP § 2173.05(e).
Claims 3, 5-7,10, 12-13, 23, and 25-26 are rejected for substantially the same reason indicated above for claim 1, at least due to their dependence on the claim.
Claim 14 recites the limitation “displaying a workstream on a workstream interface of the user interface, wherein the workstream interface is configured for viewing, editing and transmitting the workstream to other users.” There is insufficient antecedent basis for the phrase “the user interface.” See MPEP § 2173.05(e).
Claims 15-19, 24, and 27-28 are rejected for substantially the same reason indicated above for claim 14, at least due to their dependence on the claim.
Claim Rejections - 35 USC § 103
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.
Claims 1, 3, 5-6, 10, and 12-13 are rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Baek et al., US 2018/0189369 A1.
Regarding claim 1, Schultz discloses a project management system, comprising:
At least one user computing device in operable connection with a user network. Schultz fig. 1 (client 102).
An application server in operable communication with the user network, the application server configured to host an application system for providing a platform managing information related to a project. In Schultz, a server may communicate with a client device via a network. Schultz fig. 1. The server may host a project management system. Id. fig. 2 (project management system 202).
The application system having a user interface module for providing access to the application system through the user computing device. In Schultz, the project management system may comprise a user interface. Schultz ¶ 44.
[The application system having] a document module to receive at least one document from a document management API to permit the creation, editing, and transmittal of a document associated with a project. In Schultz, the project management system may comprise a collaborative authoring application for editing documents. Schultz ¶¶ 19-20. Applicant has defined the term “API” to mean “a set of commands, functions and/or protocols that computer programmers can use when building software for a specific operating system.” Specification ¶ 98. Schultz teaches two or more computer applications communicating with each other. Schultz ¶ 20. Additionally, Schultz teaches retrieving data from a data store or database server. Id. ¶ 40. The mere communication between two applications or two computing devices implies the use of an API. Therefore, Schultz inherently teaches the use of an API to receive documents.
A project management module to receive a plurality of information and to correlate the information to at least one project. Schultz teaches the project management system may associate items of information with a project workspace. Schultz ¶¶ 50-51.
An email integration module in operable communication with the project management module, the email integration module configured to display outputs of an email API onto a user dashboard. In Schultz, the user interface may display emails. Schultz figs. 3-4, ¶¶ 23-26. As explained above, communication with a correspondence application (whether local or remote) implies the use of an API. Therefore, Schultz inherently teaches the use of an email API in receiving email communication for display.
Wherein the user dashboard is permitted to display emails as aggregated emails for a plurality of projects each associated with at least one client. By use of the phrase “permitted to,” this clause has been interpreted to recite an intended use or result. Therefore, the clause is afforded no limiting effect. Nevertheless, Schultz teaches a user interface displaying multiple projects and related items (e.g., emails) associated with each project. Schultz ¶ 37. Each project may be associated with one or more clients (i.e., “participants”). Id. ¶¶ 33, 37.
A communication module to permit collaborative engagement with the document. By use of the phrase “to permit,” this clause has been interpreted to recite an intended use or result. Therefore, the clause is afforded no limiting effect. Nevertheless, in Schultz, the project management system allows for collaborative work with a document. Schultz ¶ 19, fig. 1.
Wherein the email integration module permits the integration of the emails between the first user computing device and a second user computing device to be shared and interacted with each other. By use of the phrase “permits,” this clause has been interpreted to recite an intended use or result. Therefore, the clause is afforded no limiting effect. Nevertheless, Schultz teaches the sharing of work-product items, such as emails, between computing devices. Schultz ¶¶ 19, 22, figs. 1-2.
Wherein the document management API is in operable communication with the user dashboard to display one or more documents associated with each client. In Schultz, the user interface may display documents associated with a project. Schultz fig. 4, ¶¶ 31, 35, 37. As explained above, communication with a user interface implies the use of an API. Therefore, Schultz inherently teaches the use of document management API for displaying documents.
Wherein the user interface comprises a workstream interface configured to display a workstream, and wherein the workstream interface is configured for viewing, editing and transmitting the workstream to other users. Applicant has described a workstream as comprising “relevant documents, deadlines, contact information, discussions and other communications, transactions, and other information.” Specification ¶ 80. Schultz describes a user interface comprising a workspace configured to display work product items associated with a project. Schultz ¶ 26. Schultz also describes an interface that allows for viewing, editing, and transmitting work product items to others. Id. ¶ 19.
Schultz does not explicitly disclose, but Baek discloses:
A redline module configured to receive edits from both a first user device and a second user device to one or more documents associated with a project. Baek teaches a content management system that may receive multiple versions of a document from different users. Baek ¶ 92.
Wherein the first user device is alerted of edits of the second user device, wherein the alert is displayed on the user dashboard. Baek teaches displaying a notification of changes to a document by another user. Baek fig. 4, ¶¶ 93-94. The notification may appear on a dashboard (“client desktop interface”). Id. fig. 4, ¶ 89.
Wherein the redline module is configured to accept or deny, via the first user device, each edit of the second user device. Baek teaches displaying respective user interface elements that allow a user to accept or reject an edit. Baek fig. 6B, ¶ 106.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Baek’s process for managing the version history for a shared document. Such a modification would increase utility of the project management system by facilitating collaboration through synchronization of content among multiple users.
Regarding claim 3, which depends on claim 1, Schultz discloses wherein the user dashboard displays a plurality of project information stored in a project database. In Schultz, project information may be stored in a database. Schultz ¶ 40. The user interface may display project information. Id. fig. 4.
Regarding claim 5, which depends on claim 1, Schultz discloses wherein the application system is in operable communication with an email server API to permit the integration of the emails with the user dashboard. Schultz ¶ 22, fig. 4. The phrase “to permit the integration of emails with the user dashboard” has been interpreted to recite an intended use or result. Therefore, the phrase is afforded no limiting effect.
Regarding claim 6, which depends on claim 5, Schultz discloses wherein the application system is in operable communication with a case management API to permit the integration of case management information. Schultz ¶ 22. The phrase “to permit the integration of case management information” has been interpreted to recite an intended use or result. Therefore, the phrase is afforded no limiting effect.
Regarding claim 10, which depends on claim 7, Schultz discloses a user dashboard to display a plurality of project information stored in a project database. In Schultz, project information may be stored in a database. Schultz ¶ 40. The user interface may display project information. Id. fig. 4.
Regarding claim 12, which depends on claim 10, Schultz discloses wherein the application system is in operable communication with an email server API to permit the integration of the emails with the user dashboard. Schultz ¶ 22, fig. 4. The phrase “to permit the integration of emails with the user dashboard” has been interpreted to recite an intended use or result. Therefore, the phrase is afforded no limiting effect.
Regarding claim 13, which depends on claim 12, Schultz discloses wherein the application system is in operable communication with a case management API to permit the integration of case management information. Schultz ¶ 22. The phrase “to permit the integration of case management information” has been interpreted to recite an intended use or result. Therefore, the phrase is afforded no limiting effect.
Claim 7 is rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Baek et al., US 2018/0189369 A1, further in view of Bhogal et al., US 20060230346 A1.
Regarding claim 7, which depends on claim 1, Schultz does not explicitly disclose, but Bhogal discloses a term definition module configured to:
Associate a term defined via the first user device with one or more terms in the document. Bhogal fig. 6A, ¶ 45.
Generate a hyperlink selectable via the first user device. Bhogal fig. 6B, ¶ 53.
Display the definition following a selection of the hyperlink. Bhogal fig. 6B, ¶ 53.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz and Baek’s system for editing a document with Bhogal’s process for creating a hyperlink within a document. Such a modification would increase utility by allowing a reader to quickly be presented with additional, desired information (e.g., a definition of an unfamiliar term). See Bhogal ¶ 9.
Claims 14-17 are rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Chuang et al., US 2006/0178921 A1, further in view of Baek et al., US 2018/0189369 A1.
Regarding claim 14, Schultz discloses a computer program product comprising a non-transitory computer-usable medium having computer-readable project code embodied therein, wherein the computer readable program code, when executed by a first computing system, causes the computing system to implement a method comprising the steps of:
Receiving, via a first user device, a plurality of client information associated with a client. In Schultz, information relating to a client (i.e., “participant”) may be received from a user. Schultz ¶ 33.
Storing, via a client database, the plurality of client information. Schultz fig. 5 (data store(s) 519 and database server 518), ¶ 40.
Creating, via a first user device, at least one project associated with the client. Schultz ¶ 33, fig. 4.
Storing, via a project database, a plurality of project information and permitting access to the plurality of project information via a user dashboard. In Schultz, project information may be stored in a database. Schultz fig. 5 (data store(s) 519 and database server 518), ¶ 40. Project information may be accessed via a user interface. Id. fig. 4, ¶¶ 31-32, 34-37.
Managing, via a document management API, at least one document associated with the project. In Schultz, the project management system allows for the functionality of managing a document. Schultz ¶ 19.
Integrating, via an email integration module, emails between the first computing system and a second computing system such that the emails may be shared and interacted with each other. The phrase “such that the emails may be shared and interacted with each other” has been interpreted to recite an intended use or result. Therefore, the phrase is afforded no limiting effect. Nevertheless, Schultz teaches the sharing of work-product items, such as emails, between computing devices. Schultz ¶¶ 19, 22, figs. 1-2.
Displaying a workstream on a workstream interface of the user interface, wherein the workstream interface is configured for viewing, editing and transmitting the workstream to other users. Applicant has described a workstream as comprising “relevant documents, deadlines, contact information, discussions and other communications, transactions, and other information.” Specification ¶ 80. Schultz describes a user interface comprising a workspace configured to display work product items associated with a project. Schultz ¶ 26. Schultz also describes an interface that allows for viewing, editing, and transmitting work product items to others. Id. ¶ 19.
Schultz does not explicitly disclose, but Chuang discloses:
Scheduling, via a case management API, one or more deadlines associated with the project. Applicant has defined the term “API” to mean “a set of commands, functions and/or protocols that computer programmers can use when building software for a specific operating system.” Specification ¶ 98. Schultz does not explicitly disclose functionality for scheduling a project deadline. However, Chuang teaches a task deadline controller that allows for scheduling a project deadline. Chuang ¶ 33.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Chuang’s process for scheduling a project deadline. Such a modification would increase utility of the project management system by facilitating the notification of users of important project deadlines.
Schultz does not explicitly disclose, but Baek discloses:
Editing by both the first user device and a second user device, via a redline module, one or more documents associated with a project. Baek teaches a content management system that may receive multiple versions of a document from different users. Baek ¶ 92.
Wherein the first user device is alerted of edits of the second user device, wherein the alert is displayed on the user dashboard. Baek teaches displaying a notification of changes to a document by another user. Baek fig. 4, ¶¶ 93-94. The notification may appear on a dashboard (“client desktop interface”). Id. fig. 4, ¶ 89.
Accepting or denying, via the first user device, each edit of the second user device. Baek teaches displaying respective user interface elements that allow a user to accept or reject an edit. Baek fig. 6B, ¶ 106.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Baek’s process for managing the version history for a shared document. Such a modification would increase utility of the project management system by facilitating collaboration through synchronization of content among multiple users.
Regarding claim 15, which depends on claim 14, Schultz discloses transmitting, via a communication module, edits to the one or more documents to a third-party computing device. Schultz ¶¶ 19-20, 27.
Regarding claim 16, which depends on claim 15, Schultz discloses wherein the communication module is in operable communication with an email server API to integrate one or more emails and display the one or more emails via the user dashboard. Schultz ¶ 22, fig. 4.
Regarding claim 17, which depends on claim 16, Schultz discloses wherein the document management API is in operable communication with the user dashboard to display one or more documents associated with each client. In Schultz, the user interface may display documents associated with a project. Schultz fig. 4, ¶¶ 31, 35, 37. As explained above, communication with a user interface implies the use of an API. Therefore, Schultz inherently teaches the use of document management API for displaying documents.
Claims 18-19 are rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Chuang et al., US 2006/0178921 A1, further in view of Baek et al., US 2018/0189369 A1, further in view of Bhogal et al., US 20060230346 A1.
Regarding claim 18, which depends on claim 17, Schultz does not explicitly disclose, but Bhogal discloses a term definition module to perform the following steps:
Associating a term defined via the first user device with one or more terms in the document. Bhogal fig. 6A, ¶ 45.
Generating a hyperlink selectable via the first user device. Bhogal fig. 6B, ¶ 53.
Displaying the definition following a selection of the hyperlink. Bhogal fig. 6B, ¶ 53.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz and Chuang’s system for editing a document with Bhogal’s process for creating a hyperlink within a document. Such a modification would increase utility by allowing a reader to quickly be presented with additional, desired information (e.g., a definition of an unfamiliar term). See Bhogal ¶ 9.
Regarding claim 19, which depends on claim 18, Chuang discloses a calendar module to permit input of one or more scheduled events and one or more deadlines associated with the client. By use of the phrase “to permit,” this clause has been interpreted to recite an intended use or result. Therefore, the clause is afforded no limiting effect. Nevertheless, in Chuang, a task deadline controller allows for scheduling a deadline for an event (i.e., task) associated with a project. Chuang ¶ 33, fig. 4.
Claim 23 is rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Baek et al., US 2018/0189369 A1, further in view of Heston, US 2002/0019741 A1.
Regarding claim 23, which depends on claim 1, Schultz does not explicitly disclose, but Heston discloses a form generation module configured to generate forms associated with a task of the project. Heston teaches software that allows a user to generate forms. For example, the forms may be associated with a task (e.g., drafting a will). Heston ¶ 124.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Heston’s process for generating forms associated with a task. Such a modification would increase utility of the project management system by facilitating the drafting and completion of legal forms. See Heston ¶ 15.
Claim 24 is rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Chuang et al., US 2006/0178921 A1, further in view of Baek et al., US 2018/0189369 A1, further in view of Heston, US 2002/0019741 A1.
Regarding claim 24, which depends on claim 14, Schultz does not explicitly disclose, but Heston discloses generating, via a form generation module, forms associated with a task of the project. Heston teaches software that allows a user to generate forms. For example, the forms may be associated with a task (e.g., drafting a will). Heston ¶ 124.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Heston’s process for generating forms associated with a task. Such a modification would increase utility of the project management system by facilitating the drafting and completion of legal forms. See Heston ¶ 15.
Claims 25-26 are rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Baek et al., US 2018/0189369 A1, further in view of Lau et al., US 2006/0047811 A1.
Regarding claim 25, which depends on claim 1, Schultz does not explicitly disclose, but Lau discloses wherein the workstream interface comprises a chat interface that is configured to allow a user to input communications which are transmitted to other users. Lau describes an interface that allows a user to initiate chat communication with another user. Lau ¶ 51, fig. 5.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Lau’s interface for communicating with other users. Such a modification would increase the usability and convenience of the project management system by allowing a user to contact other users without having to switch to a different user interface or application. See Lau ¶ 51.
Regarding claim 26, which depends on claim 1, Schultz does not explicitly disclose, but Lau discloses wherein the project management system is configured to contextualize workstreams, wherein contextualizing the workstreams comprises: aggregating information into client, matter, and workstream subcategories. Lau teaches aggregating information into a workstream subcategory (i.e., “new and recent files”). Lau ¶ 52, fig. 5. Lau teaches aggregating information into a client subcategory (i.e., “contacts”). Id. ¶ 51, fig. 5. Lau teaches aggregating information into a matter subcategory (i.e., “projects”). Id. ¶ 47, fig. 5.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Lau’s interface for aggregating information. Such a modification would increase the usability and convenience of the project management system by allowing a user to centrally access client, matter, and workstream information. See Lau ¶ 5.
Claims 27-28 are rejected under 35 U.S.C. § 103 as being unpatentable over Schultz et al., US 2012/0151377 A1, in view of Chuang et al., US 2006/0178921 A1, further in view of Baek et al., US 2018/0189369 A1, further in view of Lau et al., US 2006/0047811 A1.
Regarding claim 27, which depends on claim 14, Schultz does not explicitly disclose, but Lau discloses allowing a user to input communications through a chat interface that are transmitted to other users. Lau describes an interface that allows a user to initiate chat communication with another user. Lau ¶ 51, fig. 5.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Lau’s interface for communicating with other users. Such a modification would increase the usability and convenience of the project management system by allowing a user to contact other users without having to switch to a different user interface or application. See Lau ¶ 51.
Regarding claim 28, which depends on claim 14, Schultz does not explicitly disclose, but Lau discloses contextualizing workstreams, wherein contextualizing workstreams comprises: aggregating information into client, matter, and workstream subcategories. Lau teaches aggregating information into a workstream subcategory (i.e., “new and recent files”). Lau ¶ 52, fig. 5. Lau teaches aggregating information into a client subcategory (i.e., “contacts”). Id. ¶ 51, fig. 5. Lau teaches aggregating information into a matter subcategory (i.e., “projects”). Id. ¶ 47, fig. 5.
It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify Schultz’s project management system with Lau’s interface for aggregating information. Such a modification would increase the usability and convenience of the project management system by allowing a user to centrally access client, matter, and workstream information. See Lau ¶ 5.
Response to Arguments
I. Written Description/Indefiniteness
The prior rejections of claims 21-22 under § 112(a)/(b) have been withdrawn based on the cancelation of the corresponding claims
II. Nonobviousness
Regarding claims 1 and 14, Applicant alleges that Schultz does not disclose the newly added limitation directed to a user interface comprising a workstream. Reply 9. The specification describes a workstream as comprising “relevant documents, deadlines, contact information, discussions and other communications, transactions, and other information.” Specification ¶ 80. In turn, Schultz describes a user interface comprising a workspace configured to display work product items associated with a project. Schultz ¶ 26. Schultz also describes an interface that allows for viewing, editing, and transmitting work product items to others. Id. ¶ 19. Accordingly, Applicant’s allegation is unpersuasive.
Conclusion
Although particular portions of the prior art may have been cited in support of the rejections, the specified citations are merely representative of the teachings. Other passages and figures in the cited prior art may apply. Accordingly, Applicant should consider the entirety of the cited prior art for potentially teaching all or part of the claims.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Asher D Kells whose telephone number is (571)270-7729. The examiner can normally be reached Mon. - Fri., 8 a.m. - 4 p.m..
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, Kieu Vu can be reached at 571-272-4057. 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.
Asher D. Kells
Primary Examiner
Art Unit 2171
/Asher D Kells/ Primary Examiner, Art Unit 2171