DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in response to Applicant's reply filed 09/04/2026 (effective filing date 04/28/2022). Claim 20 has been amended. Claims 1-20 are pending and have been examined. Claims 1 and 11 are independent.
This action is a second non-final action. The rejection under 35 U.S.C. 103 has been reformulated, and a nonstatutory double patenting rejection is newly entered. Because these new grounds of rejection were not necessitated by Applicant's amendment, this action is made non-final. See MPEP 706.07(a).
Information Disclosure Statement
The information disclosure statements submitted: 04/07/2026 and 09/04/2026, have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on 04/28/2025 as modified by the amendment filed on 09/04/2026.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more. The analysis below follows MPEP 2106 and replaces the analysis set forth in the prior Office action.
Step 1: Statutory Category
Claims 1-10 recite a system comprising one or more physical processors and are directed to a machine. Claims 11-20 recite a method and are directed to a process. Each claim falls within a statutory category. No signal per se or software per se issue is presented, because each claim requires one or more physical processors.
Step 2A, Prong One: The Claims Recite an Abstract Idea
Claim 11 is representative of the independent claims. The following limitations of claim 11 set forth the abstract idea:
“managing ... workflow information characterizing a workflow of a collaboration environment”;
“the collaboration environment managing a work unit record for a unit of work, the work unit record including a current stage value of a stage parameter characterizing stage of the work unit record within the workflow”;
“the workflow information describing: a set of stages; an order of progression through the set of stages; first rules that apply at a first stage in the set of stages; second rules that apply at a second stage in the set of stages; and a first set of automated actions to carry out in response to a first trigger event”; and
the information content of the presentation step, namely that the work page for the record displays “the current stage value,” and that the user, having viewed the record, is provided the “workflow” that governs it.
Taken together, these limitations describe the following concept, which is identified as the abstract idea: organizing and managing work that people perform by means of a staged workflow, that is, recording the stage that a unit of work currently occupies, defining the stages, the order in which work moves through them, the rules to be followed at each stage, and the actions to be taken when a specified event occurs, and making both the stage of the work and the workflow that governs it available to the person doing the work.
This concept falls within the "certain methods of organizing human activity" grouping, and specifically within the sub-grouping of managing personal behavior or relationships or interactions between people, including following rules or instructions. MPEP 2106.04(a)(2)(II)(C). A workflow of ordered stages with stage-specific rules is a set of instructions that tells people how work is to proceed and what must happen at each point. Applicant's own specification describes the claimed workflow as "a work process that is orchestrated, ongoing, and/or repeatable via an ordered series of stages" (Specification, Pub. No.: US 2025/0252402 A1 ¶ [0004]), explains that the stage-specific rules "may specify that certain form fields must be completed as part of entering the stage" (Id.), and identifies the problem addressed as a "disconnect between the reference material describing the workflow, and the work itself," where the reference material "may comprise, for example, a flow chart or other organizational information" (Specification, ¶ [0003]). A paper flow chart posted in an office, together with a job folder stamped with its current stage and a written procedure stating what is to be done when work enters each stage, performs the same organizing function. The rules that "apply" at each stage, and the automated actions to be carried out "in response to a first trigger event," are, in the claimed context, business rules for how work proceeds (for example, assigning the work to a user, setting a due date, or sending a communication, see claim 8). The identification of the abstract idea is made for claim 11 as a whole and applies equally to claim 1, which recites the same limitations in system form.
The Office relies on the "certain methods of organizing human activity" grouping only. The mental process grouping is not relied upon in this action.
Step 2A, Prong Two: The Abstract Idea Is Not Integrated into a Practical Application
The additional elements of claim 11 are: (a) “one or more physical processors configured by machine-readable instructions”; (b) “a server”; (c) “a remotely located client computing platform communicating with the server over a network connection”; (d) “establishing the network connection between the remotely located client computing platform and the server”; (e) “effectuating communication of user interface information from the server to the remotely located client computing platform over the network connection to cause the remotely located client computing platform to present a graphical user interface work page for the work unit record within a graphical user interface of the collaboration environment”; and (f) “responsive to obtaining user input information conveying user input of a selection of a user interface element in the graphical user interface work page, causing the graphical user interface to navigate from the graphical user interface work page to a graphical user interface workflow page for the workflow.” The fact that the stored stage, rules, and actions reside in a computer, and that the "automated actions" are carried out by the computer, is addressed together with elements (a) and (b).
Each additional element has been given weight, alone and in combination, without regard to whether it is well-understood, routine, or conventional. MPEP 2106.04(d).
Elements (a) and (b) are a generic processor and a generic server, recited at a high level of generality, that perform the abstract idea. Storing the workflow information, storing the stage value in a record, and carrying out the business rules by a processor rather than by a person amount to mere instructions to implement the abstract idea on a computer. MPEP 2106.05(f); Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 223-24 (2014). The specification confirms the generic nature of these elements: the client computing platform "may include one or more of a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a NetBook, a Smartphone, a gaming console, and/or other computing platforms" (Specification, ¶ [0109]), and the server "may be implemented by a cloud of computing platforms" (Specification, ¶ [0111]).
Elements (c) and (d) recite that the user reaches the server over a network. Connecting a client to a server over a network, and exchanging data over that connection, generally links the abstract idea to a networked computing environment and is insignificant extra-solution activity in the form of data transmission. MPEP 2106.05(g), 2106.05(h).
Element (e) recites transmitting user interface information so that the client displays a page for the record that shows the record's stage. This is presentation of the information that the abstract idea generates and manages. It does not specify any particular manner of generating or rendering the page, any particular page structure, or any change to how the client or server operates. Presenting information on a display is insignificant extra-solution activity. MPEP 2106.05(g); Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1353-54 (Fed. Cir. 2016).
Element (f) recites that when the user selects an element on the record's page, the interface navigates to a page for the workflow. The claim recites the result, a navigation from one page to another, without reciting how the navigation is accomplished. Selecting an element on one page to display a related page is the ordinary function of a graphical user interface. The Federal Circuit has held claims directed to navigating among pages or tabs of a web-based interface to be abstract where the claims describe the effect rather than a specific technical means of achieving it. Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348 (Fed. Cir. 2015). Element (f) therefore amounts to using a generic graphical user interface as a tool to provide the workflow to the user (MPEP 2106.05(f)) and to generally linking the abstract idea to a graphical user interface environment (MPEP 2106.05(h)).
Considered as a whole, the claim does not reflect an improvement to the functioning of a computer or to another technology or technical field. MPEP 2106.04(d)(1), 2106.05(a). The specification states that the problem addressed is that "adhering to the workflow requires substantial human intervention to keep tags up-to-date and accurate with respect to where work is within the progression through a workflow" (Specification, ¶ [0003]), and the asserted benefit is "increased efficiency and accuracy in the creation and management of records and/or the information making up the records of the collaboration environment" (Specification, ¶ [0007]). The problem is one of keeping people's work aligned with a business procedure, and the benefit is to the organization of that work. An improvement in the organization of human activity, even one delivered through a computer interface, is an improvement to the abstract idea and not to technology. Trading Technologies Int'l, Inc. v. IBG LLC, 921 F.3d 1084, 1093-95 (Fed. Cir. 2019); Customedia Technologies, LLC v. Dish Network Corp., 951 F.3d 1359, 1365-66 (Fed. Cir. 2020). The claims do not recite a particular machine, do not transform an article, and do not apply the exception in any other meaningful way beyond linking it to a networked computer environment. MPEP 2106.04(d), 2106.05(b), (c), (e).
Claim 1 recites the same additional elements in system form and is not integrated into a practical application for the same reasons. Claims 1 and 11 are directed to the abstract idea.
Step 2B: The Claims Do Not Recite Significantly More
As discussed under Prong Two, elements (a) and (b) are mere instructions to apply the abstract idea using a generic computer, and elements (c), (d), and (f) generally link the abstract idea to a networked graphical user interface. These conclusions carry over to Step 2B. MPEP 2106.05(I)(A).
Elements (c), (d), and (e), which were identified as insignificant extra-solution activity at Prong Two, are re-evaluated at Step 2B to determine whether they are more than well-understood, routine, conventional activity in the field. MPEP 2106.05(d). They are not. Receiving or transmitting data over a network is well-understood, routine, and conventional. MPEP 2106.05(d)(II)(i), citing Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), and OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015). Presenting data in a web page served to a remote client is likewise conventional; Applicant's specification describes the server, client computing platforms, and network only in generic terms (Specification, ¶¶ [0019], [0108], [0109], [0111]), which is itself evidence under Berkheimer v. HP Inc., 881 F.3d 1360, 1368 (Fed. Cir. 2018), that a person of ordinary skill needed no special description to implement them. See MPEP 2106.07(a)(III)(A).
Element (f), selection of a displayed element to navigate to an associated page, is also well-understood, routine, and conventional in web-based and mobile work-tracking systems. See Arora (US 2022/0335812 A1), ¶ [0040] (an event details display that includes "event timeline and current status information," where "[d]etailed timeline information can be viewed by clicking the view event timeline text at 338"); Powers (US 2016/0275453 A1), ¶ [0009] ("user interaction via the interactive electronic display with one of the plurality of displayable actionable elements in the referring guided page results in presenting a corresponding screen in the collaborative platform with which the displayable actionable element is associated"), and ¶ [0454] (a link that "may resolve to a specific location within a collaboration project, such as a particular step in a collaboration workflow or the like"); Viswanathan (US 2022/0261288 A1), ¶ [0079] (workflow user interfaces that "may comprise one or more webpages provided through a website that is in communication with the microservice"). These are citations to publications that describe the elements as known and in ordinary use. MPEP 2106.07(a)(III)(C).
Considered as an ordered combination, the additional elements add nothing that is not present when they are considered individually. The ordered combination is a server that stores the workflow and the record, serves a page showing the record's stage, and links that page to a page showing the workflow. That is the conventional client-server web arrangement applied to the abstract idea. It is not a non-conventional arrangement of known components of the kind found in BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1350 (Fed. Cir. 2016), where the claims recited a specific filtering architecture at a specific location in the network that improved the filtering technology itself. The claims do not recite significantly more than the abstract idea.
Dependent Claims
The dependent claims have been considered individually and do not add limitations that integrate the abstract idea into a practical application or amount to significantly more.
Claims 2 and 12 recite “criteria that must be met in order to progress from the first stage to the second stage.” Progress criteria are a further rule of the business procedure and are part of the abstract idea. No additional element is added.
Claims 3 and 13 recite that “the criteria includes one or more of work completion, uploading a digital content item, or communicating with one or more users.” These are examples of the kinds of human work that satisfy a procedural rule, and they further define the abstract idea. The mention of “uploading a digital content item” names ordinary data transfer without any technical detail and is at most insignificant extra-solution activity. MPEP 2106.05(g).
Claims 4 and 14 recite “responsive to the criteria being met for the work unit record, transition[ing] the work unit record from the first stage to the second stage by changing the current stage value from a first stage value to a second stage value.” Moving work to the next stage when a condition is met, and recording the new stage, is part of the abstract idea. Performing the update by a processor is mere instructions to apply it. MPEP 2106.05(f).
Claims 5-6 and 15-16 recite selecting and applying the first rules or the second rules “responsive to the current stage value being a first stage value because the work unit record is at the first stage” and at the second stage, respectively. Applying the rules that govern the stage the work is in is following rules or instructions and is part of the abstract idea.
Claims 7 and 17 recite “manag[ing], by the server, environment state information maintaining the collaboration environment.” Maintaining information about the work and the people doing it is part of the abstract idea; the server is the same generic server addressed above.
Claims 8 and 18 recite that the automated actions “include one or more of creating a new work unit record, specifying a user assignment, specifying a due date, work unit completion, causing progress to another workflow, or sending a communication to one or more users.” Assigning work, setting due dates, marking work complete, and sending communications are activities that organize human work and are part of the abstract idea.
Claims 9 and 19 recite that “the workflow is editable via the graphical user interface workflow page.” Editing the procedure is part of managing it. The use of a graphical user interface page for the edit is a generic computer function recited at a high level of generality. MPEP 2106.05(f).
Claims 10 and 20 recite “responsive to the work unit record being at a transition state between the first stage and the second stage, select[ing] transition rules that apply at the transition state.” Applying rules that govern the hand-off between stages is part of the abstract idea.
Claims 1-20 are therefore not patent eligible.
Suggested Amendment
The Examiner suggests that Applicant consider claim amendments that recite the specific technical mechanism by which the collaboration environment keeps the record and the workflow connected, rather than the organizational result. For example, a claim that recites how the server monitors the environment state information for fulfillment of the stored progress criteria and, without user input, changes the stored stage value and executes the stored automation records (see Specification, ¶¶ [0080]-[0081], [0086]-[0087]), together with a specific structure of the workflow page, such as stage elements that visually contain selectable elements representing the work unit records currently at each stage, where selection of such an element presents the corresponding work page (see Specification, ¶¶ [0096], [0107]; FIG. 4), would present a materially different question under Step 2A, Prong Two. Any amendment must be supported by the original disclosure.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046 (Fed. Cir. 1993); In re Longi, 759 F.2d 887 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937 (CCPA 1982); In re Vogel, 422 F.2d 438 (CCPA 1970); In re Thorington, 418 F.2d 528 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP 2159. See MPEP 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP 706.07(e) and 714.13.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-14 of U.S. Patent No. 12,346,881 B2 (Application No. 18/643,127). Although the claims at issue are not identical, they are not patentably distinct from each other because each instant claim is anticipated by the corresponding patented claim. Table 1 compares instant claim 1 with patented claim 1, limitation by limitation. Every limitation of instant claim 1 is recited in patented claim 1. Language of patented claim 1 that has no counterpart in instant claim 1 is shown in bold.
Table 1. Instant Claim 1 Compared with Claim 1 of U.S. Patent No. 12,346,881 B2
Instant Application 19/191,878, Claim 1
U.S. Patent No. 12,346,881 B2, Claim 1
A system configured to provide navigation to a user interface page of a workflow of a collaboration environment, the system comprising: one or more physical processors configured by machine-readable instructions to:
A system configured to characterize a work unit record of a collaboration environment based on stages within a workflow and provide navigation functionality between a graphical user interface page for the work unit record and a graphical user interface page for the workflow, the system comprising: one or more physical processors configured by machine-readable instructions to:
manage, by a server, workflow information characterizing a workflow of a collaboration environment, a user interacting with the collaboration environment via a remotely located client computing platform communicating with the server over a network connection, the collaboration environment managing a work unit record for a unit of work, the work unit record including a current stage value of a stage parameter characterizing stage of the work unit record within the workflow,
manage, by a server, environment state information maintaining a collaboration environment, the collaboration environment being configured to facilitate interaction by a user with the collaboration environment, the user interacting with the collaboration environment via a remotely located client computing platform communicating with the server over a network connection, the environment state information including a work unit record for a unit of work managed, created, and/or assigned within the collaboration environment, the work unit record including a current stage value of a stage parameter characterizing stage of the work unit record within a workflow; manage, by the server, workflow information characterizing the workflow, the workflow information comprising:
the workflow information describing: a set of stages;
a set of stages, the set of stages including a first stage associated with a first stage value of the stage parameter, and a second stage associated with a second stage value of the stage parameter;
an order of progression through the set of stages;
progression information specifying an order of progression through the set of stages, the order defining progress from the first stage to the second stage; and
first rules that apply at a first stage in the set of stages; second rules that apply at a second stage in the set of stages; and
rule information including first rules that apply at the first stage, and second rules that apply at the second stage,
a first set of automated actions to carry out in response to a first trigger event;
wherein the rule information includes automation information, the automation information including a first set of automated actions to carry out in response to a first trigger event, and a second set of automated actions to carry out in response to a second trigger event, and wherein the first trigger event includes specification of the first stage value of the stage parameter, and the second trigger event includes specification of the second stage value of the stage parameter;
establish the network connection between the remotely located client computing platform and the server;
establish the network connection between the remotely located client computing platform and the server;
effectuate communication of user interface information from the server to the remotely located client computing platform over the network connection to cause the remotely located client computing platform to present a graphical user interface work page for the work unit record within a graphical user interface of the collaboration environment, the graphical user interface work page displaying the current stage value; and
effectuate communication of user interface information from the server to the remotely located client computing platform over the network connection to cause the remotely located client computing platform to present a graphical user interface work page for the work unit record within a graphical user interface of the collaboration environment, the graphical user interface work page including a user interface element displaying the current stage value of the stage parameter included in the work unit record, wherein the user interface element is selectable to cause the graphical user interface to navigate from the graphical user interface work page to a graphical user interface workflow page for the workflow;
responsive to obtaining user input information conveying user input of a selection of a user interface element in the graphical user interface work page, cause the graphical user interface to navigate from the graphical user interface work page to a graphical user interface workflow page for the workflow.
responsive to obtaining user input information conveying user input into the graphical user interface including selection of the user interface element [displaying the current stage value], cause the graphical user interface to navigate from the graphical user interface work page to the graphical user interface workflow page;
(no corresponding limitation)
responsive to the current stage value being the first stage value because the work unit record is at the first stage, select and apply the first rules to the work unit record; and responsive to the current stage value being the second stage value because the work unit record is at the second stage, select and apply the second rules to the work unit record.
As Table 1 shows, patented claim 1 recites every limitation of instant claim 1 and adds further limitations: a second set of automated actions, trigger events defined by specification of the first and second stage values, a requirement that the selected user interface element be the element displaying the current stage value, and selection and application of the first and second rules according to the current stage value. Patented claim 1 is therefore a species of the genus recited in instant claim 1, and it anticipates instant claim 1. A later genus claim is not patentably distinct from an earlier species claim that falls within it. In re Goodman, 11 F.3d 1046, 1053 (Fed. Cir. 1993); Eli Lilly & Co. v. Barr Labs., Inc., 251 F.3d 955, 971 (Fed. Cir. 2001). Instant method claim 11 corresponds to patented method claim 8 in the same way: patented claim 8 recites, in method form, each limitation shown for patented claim 1 in Table 1, and it anticipates instant claim 11.
Table 2 identifies, for each instant claim, the patented claim that anticipates it.
Table 2. Correspondence of Instant Claims 1-20 to Claims of U.S. Patent No. 12,346,881 B2
Instant Claim
Anticipated by '881 Claim
Basis
1 (system)
1
See Table 1.
2
2
Both recite criteria that must be met to progress from the first stage to the second stage.
3
3
Identical criteria (work completion, uploading a digital content item, or communicating with one or more users).
4
4
Both recite transitioning the record from the first stage to the second stage by changing the current stage value when the criteria are met.
5
1
Patented claim 1 recites selecting and applying the first rules responsive to the current stage value being the first stage value.
6
1
Patented claim 1 recites selecting and applying the second rules responsive to the current stage value being the second stage value.
7
1
Patented claim 1 recites managing, by the server, environment state information maintaining the collaboration environment.
8
5
Identical list of automated actions.
9
6
Both recite that the workflow is editable via the graphical user interface workflow page.
10
7
Both recite selecting transition rules that apply at a transition state between the first and second stages.
11 (method)
8
Method counterpart of Table 1.
12
9
Method counterpart of instant claim 2 and patented claim 2.
13
10
Method counterpart of instant claim 3 and patented claim 3.
14
11
Method counterpart of instant claim 4 and patented claim 4.
15
8
Patented claim 8 recites selecting and applying the first rules responsive to the current stage value being the first stage value.
16
8
Patented claim 8 recites selecting and applying the second rules responsive to the current stage value being the second stage value.
17
8
Patented claim 8 recites managing, by the server, environment state information maintaining the collaboration environment.
18
12
Identical list of automated actions.
19
13
Both recite that the workflow is editable via the graphical user interface workflow page.
20
14
Both recite selecting transition rules that apply at a transition state between the first and second stages.
Claims 1-8, 10-18, and 20 are also rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 12,051,045 B1 (Application No. 17/731,923), and claims 9 and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 2 and 10 of U.S. Patent No. 12,051,045 B1 in view of Viswanathan (US 2022/0261288 A1). Patented claim 2, which incorporates claim 1, recites each limitation of instant claim 1 in the plural (work unit records, work pages, and workflow pages), including work pages with user interface elements "displaying individual stage values of the stage parameter" that are selectable to navigate to the workflow pages, and "a first set of automated actions to carry out in response to a first trigger event." Patented claim 10 recites the same limitations in method form for instant claim 11. The remaining claims correspond as follows: instant claims 2, 3, 4, 8, and 10 to patented claims 2, 6, 7, 5, and 8; instant claims 5-7 to patented claim 1; instant claims 12, 13, 14, 18, and 20 to patented claims 10, 14, 15, 13, and 16; and instant claims 15-17 to patented claim 9. The patented claims do not recite that the workflow is editable via the workflow page (instant claims 9 and 19). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to make the workflow page of patented claims 2 and 10 editable, as Viswanathan provides an interface "for creating and/or configuring a custom workflow" that "may also present workflow stages" (Viswanathan, ¶ [0154]), so that users can modify the workflow from the view through which they access it. MPEP 2143(I)(C); KSR, 550 U.S. at 416.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan (US 2022/0261288 A1) in view of Sabo (US 2021/0097466 A1) and further in view of Arora (US 2022/0335812 A1).
Claim 1
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 1 recites “A system configured to provide navigation to a user interface page of a workflow of a collaboration environment, the system comprising: one or more physical processors configured by machine-readable instructions to.” Viswanathan teaches a system comprising physical processors configured by machine-readable instructions: "The processor 1702 can execute processing logic 1726 for performing various operations and/or steps described herein" (Viswanathan, ¶ [0171]), and the data storage device stores "one or more modules 1722 (e.g., sets of software instructions)," including "a create workflow module 130, create stage module 140, create subtask module 150, create rule module 160, and/or publish workflow module 170 that are part of a workflow management engine 120" (Viswanathan, ¶ [0172]). The preamble's recitation of navigation to a page of a workflow of a collaboration environment is addressed with the final two limitations below.
Claim 1 recites “manage, by a server, workflow information characterizing a workflow.” Viswanathan teaches this feature. The workflow management engine stores each custom workflow and its components in a repository: "the repository architecture 300 includes a Workflows table 320 ... that can be used for storing values of attributes that can be defined for a specific custom workflow," together with "a Stages table 330," "a Subtasks table 340," and "a Rules table 350" (Viswanathan, ¶ [0092]). The engine runs on a server: "the server system 1610 can provide a cloud infrastructure to host one more microservice-based applications (e.g., microservices 115 provided as one or more computer-executable programs executed by one or more server devices 1615)" (Viswanathan, ¶ [0168]).
Claim 1 recites “a user interacting with the collaboration environment via a remotely located client computing platform communicating with the server over a network connection.” Viswanathan teaches a user interacting with the system via a remotely located client computing platform communicating with the server over a network: "team members 126 can use a team computing system 1620 to interact, via one or more user interfaces 125, with one or more microservices 115 used in implementing an enterprise software application that is hosted by the server system 1610," and "the team computing system 1620 can communicate with one or more of the server devices 1615 over the network(s) 1625" (Viswanathan, ¶ [0166]). Viswanathan does not describe its enterprise software application as a "collaboration environment." That term is addressed with the next limitation.
Claim 1 recites “the collaboration environment managing a work unit record for a unit of work, the work unit record including a current stage value of a stage parameter characterizing stage of the work unit record within the workflow.” Viswanathan teaches a record that progresses through the stages of a workflow. A published workflow is assigned to a domain object, and "the custom workflow becomes available for execution for each instance generated of the 'risk' domain object," such that the service "may generate an instance of the 'risk' domain object to represent the identified risk that is comprised of an instance of the custom workflow developed for performing the risk management process" (Viswanathan, ¶ [0114]). Viswanathan also tracks status at the stage level, for example a rule "triggered when the 'Recommended' stage is place in the status of 'ongoing'" (Viswanathan, ¶ [0112]). Primary prior-art reference Viswanathan does not explicitly teach “the collaboration environment managing a work unit record for a unit of work, the work unit record including a current stage value of a stage parameter characterizing stage of the work unit record within the workflow,” however, secondary prior-art reference Sabo teaches this feature as follows: "Environment state component 108 may be configured to manage environment state information maintaining a collaboration environment. The environment state information may include values of user parameters and values of work unit parameters. By way of non-limiting example, the values of the user parameters may be organized in user records corresponding to users interacting with and viewing the collaboration environment and the values of the work unit parameters are organized in work unit records corresponding to units of work managed, created, and/or assigned within the collaboration environment" (Sabo, ¶ [0022]); and the work unit parameters include "a status and/or progress (e.g., an update, a hardcoded status update, a measured status, quantity of work units remaining in a given project, completed work units in a given project, and/or other status parameter)" and "one or more custom fields (e.g., priority, cost, stage, and/or other custom fields)" (Sabo, ¶ [0024]). Sabo's work unit record is the claimed work unit record, and the value held in its "stage" work unit parameter is a current stage value of a stage parameter. Sabo's users access the collaboration environment through client computing platforms that communicate with the server over a network (Sabo, ¶¶ [0020], [0038]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to use Sabo's work unit records in a collaboration environment as the domain object whose instances execute Viswanathan's custom workflow, and to store the stage each instance occupies in Sabo's "stage" work unit parameter, because Viswanathan teaches assigning a workflow as the behavior of a domain object so that the service "can then execute the workflow to perform the risk management process for the instance of the domain object" (Viswanathan, ¶ [0045]), and because Sabo teaches that the records for units of work carry status, progress, and stage parameters (Sabo, ¶ [0024]), which is where the position of an instance in a staged workflow would be recorded. The rationale is MPEP 2143(I)(A): Viswanathan's workflow engine and Sabo's work unit records each perform their known functions in combination, and the predictable result is a collaboration environment in which each work unit record executes a staged workflow and stores its current stage. KSR, 550 U.S. at 416. Viswanathan and Sabo are analogous art. Both are in the field of software for defining, assigning, and tracking units of work performed by teams of users.
Claim 1 recites “the workflow information describing: a set of stages; an order of progression through the set of stages.” Viswanathan teaches this feature. "The stage component is used to represent a stage that can be defined within a workflow to organize a group of features for the custom workflow. For example, a stage can be used in organizing a group of related tasks to perform for the custom workflow. Often, the stages of a custom workflow are performed in a sequence" (Viswanathan, ¶ [0055]). In the example, "three records having 'WS1,' 'WS2,' 'WS3' identifiers 331, 332, 333 have been added to the Stages table 330 to persist the three stages 'Identified,' 'Recommended,' and 'Mitigated,'" and "the Stages table 330 includes a 'Sequence' field 334 that is used in identifying the position of a stage in the sequence of stages defined for the custom workflow" (Viswanathan, ¶ [0105]). The stored stages are the claimed set of stages, and the stored sequence is the claimed order of progression.
Claim 1 recites “first rules that apply at a first stage in the set of stages; second rules that apply at a second stage in the set of stages.” Viswanathan teaches this feature. "[A] hook point may be provided at the beginning of a stage that allows for a rule to be defined that is triggered when the stage begins for an instance of the custom workflow" (Viswanathan, ¶ [0109]). In the example, "the first rule associated with (e.g., is implemented responsive to encountering) a hook point with the identifier 'H1' 354. This particular identifier 354 may be for a hook point implemented for the beginning of the first stage of the custom workflow. Therefore, the rule is triggered at the beginning of the 'Identified' stage," and "the second rule is triggered at the beginning of the 'Recommended' stage" (Viswanathan, ¶ [0112]). The rule associated with the "Identified" stage is a first rule that applies at a first stage, and the rule associated with the "Recommended" stage is a second rule that applies at a second stage.
Claim 1 recites “and a first set of automated actions to carry out in response to a first trigger event.” Viswanathan teaches this feature. "The rule component is used to represent a rule that controls one or more actions that are performed within the custom workflow based on one or more conditions. The microservice, in executing an instance of the custom workflow, can carry out the one or more actions in an automated manner" (Viswanathan, ¶ [0057]). "Here, 'triggering' involves evaluating the condition(s) of the rule and if the condition(s) are met, or not met depending on the rule, then executing the action(s) defined by the rule" (Viswanathan, ¶ [0109]). The actions defined by a rule are the claimed set of automated actions, and encountering the rule's hook point with its condition satisfied is the claimed trigger event.
Claim 1 recites “establish the network connection between the remotely located client computing platform and the server.” Viswanathan teaches this feature. "[T]he server system 1610 accepts requests from team member devices (e.g., the team computing system 1620) with respect to implementing and/or managing functionality associated with application services (microservices 115 thereof) over the network(s) 1625" (Viswanathan, ¶ [0167]). Accepting requests from a remote device over a network requires establishing a network connection between that device and the server. Sabo likewise teaches that "server(s) 102, client computing platform(s) 104, and/or external resources 124 may be operatively linked via one or more electronic communication links," which "may be established, at least in part, via a network such as the Internet" (Sabo, ¶ [0038]).
Claim 1 recites “effectuate communication of user interface information from the server to the remotely located client computing platform over the network connection to cause the remotely located client computing platform to present a graphical user interface work page for the work unit record within a graphical user interface of the collaboration environment, the graphical user interface work page displaying the current stage value.” Viswanathan teaches communicating user interface information from the server to the remote client to present pages: the user interfaces 125 "may comprise one or more webpages provided through a website that is in communication with the microservice 115" (Viswanathan, ¶ [0079]), and the microservices communicate using "a REST API, which may be accessed using the hypertext transfer protocol (HTTP), in a manner similar to a standard web page" (Viswanathan, ¶ [0168]). The collaboration environment and the work unit record are supplied by Sabo, as addressed in paragraph 50 above. Primary prior-art reference Viswanathan does not explicitly teach “a graphical user interface work page for the work unit record ... the graphical user interface work page displaying the current stage value,” however, secondary prior-art reference Arora teaches a page for an individual item of work that displays the item's current stage, as follows: "The response personnel status system can also allow workflow to be defined for different types of alarms, and when progress of one stage is moved to another stage, the graphical user interface can show the current stage details in the user interface" (Arora, ¶ [0035]); and "FIG. 3 is an illustration of a display screen provided on a user interface showing a device status summary," in which "the display provides the category of event 334, event description 336 including type of event, location, device indicating an event is occurring, event date and time, other details, and event timeline and current status information" (Arora, ¶ [0040]). FIG. 3 of Arora is labeled "EVENT DETAILS WITH LIVE STATUS" and displays, for a single event, "CURRENT STATUS FIRE BRIGADE DISPATCHED AT 17:30:00" (Arora, FIG. 3, display 321). The event details display 321 is a graphical user interface page for an individual item of work, the event, and the displayed current status is the item's current stage within the workflow defined for that type of event. Arora's display is presented on a remote user's device from data supplied by the remote server (Arora, ¶¶ [0034], [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to present, in the combined Viswanathan-Sabo system, a page for each work unit record that displays the record's current stage value, as Arora presents an event details page displaying the event's current stage, because Arora teaches that showing "the current stage details in the user interface" lets users "quickly ascertain the status of the event without having to navigate through the mobile application" (Arora, ¶ [0035]), and because the stage value is one of the values Sabo stores for each record (Sabo, ¶ [0024]). The rationale is MPEP 2143(I)(C): Arora's known technique of presenting an item's current workflow stage on the item's own page improves the similar Viswanathan-Sabo system in the same way, and the predictable result is a work page for the work unit record that displays its current stage value. KSR, 550 U.S. at 416. Arora is analogous art. Although Arora's examples concern building alarm events, Arora is reasonably pertinent to the particular problem with which the inventors were involved, namely connecting an item of work with the staged workflow that governs it so that users can see where the item stands and move between the item and its workflow (Specification, ¶¶ [0003], [0006]). Arora addresses that same problem for items of work handled by multiple personnel through a defined, phase-wise workflow (Arora, ¶¶ [0033]-[0035]). In re Bigio, 381 F.3d 1320, 1325 (Fed. Cir. 2004); In re Clay, 966 F.2d 656, 659 (Fed. Cir. 1992); MPEP 2141.01(a).
Claim 1 recites “and responsive to obtaining user input information conveying user input of a selection of a user interface element in the graphical user interface work page, cause the graphical user interface to navigate from the graphical user interface work page to a graphical user interface workflow page for the workflow.” Under the broadest reasonable interpretation, the claim requires selection of a user interface element in the work page and does not require that the selected element be the element displaying the stage value. Viswanathan teaches a graphical user interface workflow page for the workflow: "FIG. 11 illustrates an example of an interface 1100 that a custom workflow can use for creating and/or configuring a custom workflow," which "may also present workflow stages such as 'OPEN' 1115 and various other details, such as the stage's details 1120" (Viswanathan, ¶ [0154]); and "FIG. 14 illustrates an example of an interface 1400 that can be used for publishing a custom workflow. The interface 1400 presents various attributes of the custom workflow and associated stages" (Viswanathan, ¶ [0157]). Primary prior-art reference Viswanathan does not explicitly teach “responsive to obtaining user input information conveying user input of a selection of a user interface element in the graphical user interface work page, cause the graphical user interface to navigate from the graphical user interface work page to a graphical user interface workflow page for the workflow,” however, secondary prior-art reference Arora teaches this feature as follows: "Detailed timeline information can be viewed by clicking the view event timeline text at 338" (Arora, ¶ [0040]; FIG. 3, element 338 "VIEW EVENT TIMELINE"); and, upon selection, "the display presents a timeline of the event phases 230 with some being finished and others yet to be undertaken," in which "[t]he event response phases can be represented by different identifiers (e.g., colors, symbols, text) to help the viewer understand whether the response phase has happened, is happening, or is yet to occur" (Arora, ¶ [0039]; FIG. 2, "EVENT TIMELINE"). Arora describes these phases as the stages of a defined workflow: "the process of handling an event can be viewed as a phase-wise process where on phase is completed and another phase begins until the event has been handled and all phases have been completed" (Arora, ¶ [0033]; see also ¶ [0035]). The "view event timeline" text 338 is a user interface element in the work page; clicking it is user input selecting that element; and the resulting timeline presenting the ordered phases of the event's workflow, with completed and pending phases, is a graphical user interface workflow page for the workflow. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to provide, on the work page of the combined Viswanathan-Sabo system, a selectable element that, when selected, navigates to Viswanathan's page presenting the workflow and its stages, as Arora provides on its event details page a selectable "view event timeline" element that navigates to the view of the event's workflow phases, because Arora teaches that giving users direct access from an item to the phase-wise progress of its workflow provides "significant benefits over present concepts" (Arora, ¶ [0034]) and lets users ascertain where the item stands "without having to navigate through the mobile application" (Arora, ¶ [0035]). The rationale is MPEP 2143(I)(C), with (G): Arora's known technique of linking an item's details page to the view of its workflow improves the similar Viswanathan-Sabo system in the same way, and the predictable result is that selecting the element on the work page navigates to the workflow page. KSR, 550 U.S. at 416-17.
Viswanathan in view of Sabo and further in view of Arora therefore teaches or suggests every limitation of claim 1.
Claim 2
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 2 recites “The system of claim 1, wherein the workflow information further describes criteria that must be met in order to progress from the first stage to the second stage.” Viswanathan teaches this feature. Each stage may include subtasks flagged as required: "the Subtasks table 340 includes a 'Required' field 344 that identifies whether the subtask is required to be performed for its corresponding stage. In this example, the 'Required' field 344 for each of the three subtasks has been set to 'TRUE,' indicating a required performance of each of the subtasks during their respective stages" (Viswanathan, ¶ [0106]); and "[i]f the indicator is set to 'TRUE,' then the subtask may automatically be added to the stage for an instance generated of the custom workflow" (Viswanathan, ¶ [0098]). Because the stages are "performed in a sequence" (Viswanathan, ¶ [0055]) and each required subtask must be performed during its stage, the stored "Required" designations are criteria that must be met before an instance progresses from one stage to the next. No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 3
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 3 recites “The system of claim 2, wherein the criteria includes one or more of work completion, uploading a digital content item, or communicating with one or more users.” The claim is met if the criteria include any one of the listed alternatives. Viswanathan teaches the alternative of work completion. The criteria discussed for claim 2 are the performance of required subtasks, that is, completion of work (Viswanathan, ¶ [0106]), and Viswanathan tracks subtask completion, including a rule that sends "a remainder email ... to the individual who has been assigned to complete a particular subtask if the subtask is not completed in a specified amount of time" (Viswanathan, ¶ [0108]). No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 4
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 4 recites “The system of claim 2, wherein the one or more physical processors are further configured by the machine-readable instructions to: responsive to the criteria being met for the work unit record, transition the work unit record from the first stage to the second stage.” Viswanathan teaches that an instance of the workflow proceeds through the stages in their stored sequence (Viswanathan, ¶¶ [0055], [0105]) and that the next stage "begins for an instance of the custom workflow" (Viswanathan, ¶ [0109]), such that the instance moves from the "Identified" stage to the "Recommended" stage (Viswanathan, ¶ [0112]) after the required work of the earlier stage is performed (Viswanathan, ¶ [0106]).
Claim 4 further recites “by changing the current stage value from a first stage value to a second stage value.” Primary prior-art reference Viswanathan does not explicitly teach “changing the current stage value from a first stage value to a second stage value,” however, secondary prior-art reference Sabo teaches storing the stage of a unit of work as the value of a work unit parameter, as follows: the work unit parameters include "a status and/or progress (e.g., an update, a hardcoded status update, a measured status, ... and/or other status parameter)" and "one or more custom fields (e.g., priority, cost, stage, and/or other custom fields)" (Sabo, ¶ [0024]); and "[a] work unit record may define values of the work unit parameters associated with a given work unit" (Sabo, ¶ [0023]). When the stage of the work unit changes, the value stored in the stage parameter is updated from the value for the prior stage to the value for the new stage. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to record the transition of an instance from the first stage to the second stage by changing the value of Sabo's stage parameter from the first stage value to the second stage value, for the reasons stated for claim 1, because the stage parameter is where Sabo records the stage of a unit of work and a recorded value that is not updated when the stage changes would no longer describe the unit of work. The rationale is MPEP 2143(I)(A), and the predictable result is a work unit record whose stored stage value tracks its progression through Viswanathan's stages. KSR, 550 U.S. at 416.
Claim 5
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 5 recites “The system of claim 1, wherein the one or more physical processors are further configured by the machine-readable instructions to: responsive to the current stage value being a first stage value because the work unit record is at the first stage, select and apply the first rules to the work unit record.” Viswanathan teaches selecting and applying the rules of the stage an instance is in: "if a rule is inserted into to a custom workflow at the beginning of a stage, then the condition(s) for the rule are evaluated when the stage begins during execution of an instance of the custom workflow" (Viswanathan, ¶ [0076]); and "the rule is triggered at the beginning of the 'Identified' stage" (Viswanathan, ¶ [0112]). In the combination addressed for claim 1, the stage the record is at is recorded by the value of Sabo's stage parameter (Sabo, ¶ [0024]), so that the first rules are selected and applied because the record's stage value is the first stage value. No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 6
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 6 recites “The system of claim 5, wherein the one or more physical processors are further configured by the machine-readable instructions to: responsive to the current stage value being a second stage value because the work unit record is at the second stage, select and apply the second rules to the work unit record.” Viswanathan teaches this feature for the second stage: "the second rule associated with (e.g., is implemented responsive to encountering) a hook point with the identifier 'H2' 355. This particular identifier 355 may be for a hook point implemented for the beginning of the second stage of the custom workflow. Therefore, the second rule is triggered at the beginning of the 'Recommended' stage" (Viswanathan, ¶ [0112]; see also ¶ [0076]). The combination with Sabo's stage parameter is as addressed for claim 5. No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 7
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 7 recites “The system of claim 1, wherein the one or more physical processors are further configured by the machine-readable instructions to: manage, by the server, environment state information maintaining the collaboration environment.” Primary prior-art reference Viswanathan does not explicitly teach “environment state information maintaining the collaboration environment,” however, secondary prior-art reference Sabo teaches this feature as follows: "Environment state component 108 may be configured to manage environment state information maintaining a collaboration environment" (Sabo, ¶ [0022]), where "[s]erver(s) 102 may be configured by machine-readable instructions 106" that include "an environment state component 108" (Sabo, ¶ [0021]). The motivation and rationale are those stated for the Viswanathan-Sabo combination in claim 1: Sabo's environment state information is the store in which Sabo maintains the collaboration environment and its work unit records, so it is carried into the combination with those records. MPEP 2143(I)(A). KSR, 550 U.S. at 416.
Claim 8
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 8 recites “The system of claim 1, wherein the first set of automated actions include one or more of creating a new work unit record, specifying a user assignment, specifying a due date, work unit completion, causing progress to another workflow, or sending a communication to one or more users.” The claim is met if the automated actions include any one of the listed alternatives. Viswanathan teaches the alternatives of specifying a user assignment and sending a communication to one or more users: "The second rule may involve assigning a subtask to have an individual review the assessment if the assessment were sent based on the first rule. The third rule may involve generating and sending an email remainder for a subtask if the completion date set for the subtask is less than two days" (Viswanathan, ¶ [0111]); and "the rule component can be used to represent a notification rule that involves automatically sending an electronic notification to risk management personnel if the risk score satisfies a threshold value" (Viswanathan, ¶ [0057]). No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 9
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 9 recites “The system of claim 1, wherein the workflow is editable via the graphical user interface workflow page.” Viswanathan teaches this feature. The workflow page of FIG. 11 is "an interface 1100 that a custom workflow can use for creating and/or configuring a custom workflow," which "allows a user (e.g., team member) to specify various attributes of the custom workflow, such as the workflow name ('Demo Workflow') 1110," and "may also present workflow stages such as 'OPEN' 1115" (Viswanathan, ¶ [0154]); and "FIG. 12 illustrates an example of an interface 1200 that can be used for creating and/or configuring a stage of a custom workflow," which "allows a user to specify various attributes of the workflow stage" (Viswanathan, ¶ [0155]). Configuring the workflow and its stages through the interface is editing the workflow via the workflow page. The navigation to that page is as addressed for claim 1. No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 10
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 10 recites “The system of claim 1, wherein the one or more physical processors are further configured by the machine-readable instructions to: responsive to the work unit record being at a transition state between the first stage and the second stage, select transition rules that apply at the transition state.” Consistent with the specification, a "transition state" is a state in which the record is treated as having left a prior stage but is not yet in the next stage (Specification, ¶¶ [0035], [0084]). Viswanathan teaches this feature. Viswanathan provides "multiple 'hook' points (e.g., the beginning or end of a custom workflow, a stage, a subtask, etc.)" at which rules are implemented (Viswanathan, ¶ [0076]). A hook point at the end of the first stage, or at the beginning of the second stage, is a point of transition between the two stages, and a rule associated with that hook point is a transition rule that is selected and evaluated when the instance reaches that point. Viswanathan further teaches a rule tied to a change of stage status: "the third rule is triggered when the 'Recommended' stage is place in the status of 'ongoing'" (Viswanathan, ¶ [0112]). No additional secondary reference is needed to meet this limitation beyond the combination applied to claim 1.
Claim 11
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 11 is the method counterpart of claim 1. Claim 11 recites “A method to provide navigation to a user interface page of a workflow of a collaboration environment, the method being implemented in a computer system comprising one or more physical processors configured by machine-readable instructions, such that execution of the machine-readable instructions by the one or more physical processors causes the one or more physical processors to perform the method comprising.” Viswanathan teaches a computer-implemented method performed by processors executing instructions (Viswanathan, ¶¶ [0171]-[0172], [0174]), as addressed for claim 1. Claim 11 further recites “managing, by a server, workflow information characterizing a workflow of a collaboration environment, a user interacting with the collaboration environment via a remotely located client computing platform communicating with the server over a network connection, the collaboration environment managing a work unit record for a unit of work, the work unit record including a current stage value of a stage parameter characterizing stage of the work unit record within the workflow, the workflow information describing: a set of stages; an order of progression through the set of stages; first rules that apply at a first stage in the set of stages; second rules that apply at a second stage in the set of stages; and a first set of automated actions to carry out in response to a first trigger event; establishing the network connection between the remotely located client computing platform and the server; effectuating communication of user interface information from the server to the remotely located client computing platform over the network connection to cause the remotely located client computing platform to present a graphical user interface work page for the work unit record within a graphical user interface of the collaboration environment, the graphical user interface work page displaying the current stage value; and responsive to obtaining user input information conveying user input of a selection of a user interface element in the graphical user interface work page, causing the graphical user interface to navigate from the graphical user interface work page to a graphical user interface workflow page for the workflow.” These steps correspond limitation for limitation to the functions of claim 1 and are taught or suggested by Viswanathan in view of Sabo and further in view of Arora for the reasons, with the citations, motivations, and rationales, set forth for claim 1 above.
Claims 12-20
Claims 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan in view of Sabo and further in view of Arora.
Claim 12 recites “The method of claim 11, wherein the workflow information further describes criteria that must be met in order to progress from the first stage to the second stage.” This is the method counterpart of claim 2 and is taught for the reasons given for claim 2 (Viswanathan, ¶¶ [0055], [0098], [0106]).
Claim 13 recites “The method of claim 12, wherein the criteria includes one or more of work completion, uploading a digital content item, or communicating with one or more users.” This is the method counterpart of claim 3 and is taught for the reasons given for claim 3 (Viswanathan, ¶¶ [0106], [0108]).
Claim 14 recites “The method of claim 12, further comprising: responsive to the criteria being met for the work unit record, transitioning the work unit record from the first stage to the second stage by changing the current stage value from a first stage value to a second stage value.” This is the method counterpart of claim 4 and is taught or suggested for the reasons, and with the Sabo combination, motivation, and rationale, given for claim 4 (Viswanathan, ¶¶ [0055], [0105], [0106], [0109], [0112]; Sabo, ¶¶ [0023]-[0024]).
Claim 15 recites “The method of claim 11, further comprising: responsive to the current stage value being a first stage value because the work unit record is at the first stage, selecting and applying the first rules to the work unit record.” This is the method counterpart of claim 5 and is taught for the reasons given for claim 5 (Viswanathan, ¶¶ [0076], [0112]; Sabo, ¶ [0024]).
Claim 16 recites “The method of claim 15, further comprising: responsive to the current stage value being a second stage value because the work unit record is at the second stage, selecting and applying the second rules to the work unit record.” This is the method counterpart of claim 6 and is taught for the reasons given for claim 6 (Viswanathan, ¶¶ [0076], [0112]).
Claim 17 recites “The method of claim 11, further comprising: managing, by the server, environment state information maintaining the collaboration environment.” This is the method counterpart of claim 7 and is taught or suggested for the reasons, and with the Sabo combination, motivation, and rationale, given for claim 7 (Sabo, ¶¶ [0021]-[0022]).
Claim 18 recites “The method of claim 11, wherein the first set of automated actions include one or more of creating a new work unit record, specifying a user assignment, specifying a due date, work unit completion, causing progress to another workflow, or sending a communication to one or more users.” This is the method counterpart of claim 8 and is taught for the reasons given for claim 8 (Viswanathan, ¶¶ [0057], [0111]).
Claim 19 recites “The method of claim 11, wherein the workflow is editable via the graphical user interface workflow page.” This is the method counterpart of claim 9 and is taught for the reasons given for claim 9 (Viswanathan, ¶¶ [0154]-[0155]).
Claim 20, as amended, recites “The method of claim 11, further comprising: responsive to the work unit record being at a transition state between the first stage and the second stage, selecting transition rules that apply at the transition state.” This is the method counterpart of claim 10 and is taught for the reasons given for claim 10 (Viswanathan, ¶¶ [0076], [0112]).
Response to Arguments
Arguments Regarding 35 U.S.C. 101
Applicant's arguments filed 09/04/2026 regarding the rejection under 35 U.S.C. 101 have been fully considered but they are not persuasive. The rejection has been restated above to address the points raised, and each argument is answered below.
Argument: the abstract idea was not identified as it is recited in the claim, because the stated idea ("a method and system to characterize work unit records of a collaboration environment based on stages within a workflow") does not encompass the network connection, communication of user interface information, receipt of user input, and navigation limitations (Remarks, § 101, Part A.2.a). Response: This argument has been considered and the Step 2A, Prong One analysis has been restated. The present action identifies the abstract idea with reference to the specific claim limitations that set it forth and does not treat the network connection, user interface communication, user input, and navigation limitations as part of the abstract idea. Those limitations are identified as additional elements and are evaluated at Step 2A, Prong Two and Step 2B above, as MPEP 2106.04(d) requires. The argument is therefore addressed by the restated rejection.
Argument: the Office did not determine which grouping of abstract ideas applies, because each limitation was characterized as a mental process "and/or" a certain method of organizing human activity, and the mental process grouping is inapplicable on its face (Remarks, § 101, Part A.2.b). Response: The present action identifies a single grouping, certain methods of organizing human activity, and a single sub-grouping, managing personal behavior or relationships or interactions between people, including following rules or instructions (MPEP 2106.04(a)(2)(II)(C)), and explains why the recited limitations fall within it. The mental process grouping is not relied upon. The argument is therefore addressed by the restated rejection.
Argument: under Step 2A, Prong Two, the specification identifies a problem in web-based collaboration environments, a "disconnect between the reference material describing the workflow, and the work itself," and the claims reflect the solution through three cooperating features: the stage carried on the record, the stage displayed on the work page, and navigation from the work page to the workflow page (Remarks, § 101, Part B.2). Response: The Examiner has evaluated the specification and the claims under the two-part inquiry of MPEP 2106.04(d)(1). The disconnect described in the specification is a disconnect between a business procedure and the work performed under it. The specification states that the "reference material may comprise, for example, a flow chart or other organizational information," and that, as a result, "adhering to the workflow requires substantial human intervention to keep tags up-to-date and accurate" (Specification, ¶ [0003]). That is a problem in the organization of human work, and it exists equally where the flow chart is on paper and the job is tracked in a folder. It is not a problem in the operation of a computer, a network, or a graphical user interface. Of the three features Applicant identifies, the first (the stage recorded on the record, with stages, order, rules, and actions stored as workflow information) is the abstract idea itself, and an improvement to the abstract idea is not an improvement to technology. MPEP 2106.05(a)(II); SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1170 (Fed. Cir. 2018). The second and third features are the display of information on a page and a link from that page to another page. The claims recite these features by their result and do not recite any particular way of generating the pages, storing or retrieving the link, or rendering the interface. This differs from Core Wireless Licensing S.A.R.L. v. LG Electronics, Inc., 880 F.3d 1356, 1362-63 (Fed. Cir. 2018), where the claims recited a specific manner of displaying a limited set of information in an application summary window reachable from a menu while the application was unlaunched, which improved the efficiency of using small-screen electronic devices. The present claims instead resemble those in Trading Technologies Int'l, Inc. v. IBG LLC, 921 F.3d 1084, 1093-95 (Fed. Cir. 2019), and Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348 (Fed. Cir. 2015), in which displaying information to assist a user, and navigating among pages of an interface, did not improve the functioning of the computer. Making it easier for a user to consult the procedure that governs a task is a benefit to the user's work, not to the computer. Customedia, 951 F.3d at 1365.
Argument: the prior action's Prong Two findings were conclusory, and the reasoning that the additional elements were "generic components performing generic computer functions" improperly considered well-understood, routine, conventional activity at Prong Two (Remarks, § 101, Part B.3). Response: The Prong Two analysis has been restated. It now identifies the specification's stated problem and benefit, identifies each additional element, and explains why each fails to integrate the abstract idea. The Examiner agrees that whether an additional element is well-understood, routine, or conventional is not a Prong Two consideration. MPEP 2106.04(d). The restated Prong Two analysis does not rely on that consideration. It relies on the considerations of MPEP 2106.05(a), (f), (g), and (h). Describing a component as generic, meaning recited at a high level of generality, bears on whether the claim merely uses a computer as a tool under MPEP 2106.05(f), which is a Prong Two consideration, and is distinct from a finding of well-understood, routine, conventional activity.
Argument: under Step 2B, the ordered combination supplies an inventive concept under BASCOM, because the claims arrange the record's stage, the workflow information, the stage display on the work page, and navigation to the workflow page in a non-generic way; and the claims are analogous to DDR Holdings because they solve a problem arising in Internet-based collaboration environments (Remarks, § 101, Part C.2). Response: In BASCOM, the inventive concept lay in the installation of a filtering tool at a specific location, remote from the end user, with customizable filtering features specific to each end user, which was a technical improvement to how the filtering itself was performed. BASCOM, 827 F.3d at 1350. The arrangement Applicant identifies is instead the abstract idea (the stage, stages, order, rules, and actions) combined with the display of that information and a link between two pages. Each part performs its ordinary function: the server stores and serves data, the client displays a page, and a selection on a page opens another page. As shown by the evidence cited in the rejection above, linking a displayed element of a collaboration-platform page to a related page, including a step of a collaboration workflow, was an ordinary practice (Arora, ¶ [0040]; Powers, ¶¶ [0009], [0453]-[0455]). The ordered combination does not change how any of the components operate. As to DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1257-58 (Fed. Cir. 2014), the claims there addressed a problem that did not exist outside computer networks, the loss of website visitors who click on a third-party advertisement and recited a specific way of generating a composite web page to retain them. The problem addressed here, keeping work aligned with the procedure that governs it, arises wherever work follows a written procedure, as the specification's reference to a flow chart confirms (Specification, ¶ [0003]). The claims apply that practice in a networked environment. The argument is not persuasive.
Arguments Regarding 35 U.S.C. 103
Applicant's arguments regarding the rejection of claims 1-20 under 35 U.S.C. 103 have been considered but are moot in view of the new ground of rejection set forth above, which is based on a different combination of references and a newly articulated rationale for each combination.
Applicant's arguments that Powers does not describe "a set of stages" or "a current stage value of a stage parameter" being part of a work unit record (Remarks, § 103, Part A.1), and that Powers does not describe navigating to "a graphical user interface workflow page for the workflow" (Remarks, § 103, Part A.2), are moot because the new ground of rejection does not rely on Powers for any teaching or matter specifically challenged in the argument. The rejection relies on Viswanathan for the set of stages, their order, and the stage-specific rules and automated actions; on Sabo for the collaboration environment, the work unit record, and its stage parameter; and on Arora for the work page displaying the current stage and the navigation to the workflow page.
Arguments that the prior action failed to articulate a sufficient reason to combine, used a generic and conclusory rationale, recited the claimed invention as the objective of the combination, and identified no rationale under MPEP 2143 (Remarks, § 103, Part B), are moot, because the rejection above sets out a separate motivation, drawn from the teachings of each reference, and a specific MPEP 2143(I) rationale for each combination.
Applicant's summary of the interview states that Sabo was cited in the prior action as disclosing the collaboration environment and work unit records more explicitly than Powers. The present rejection relies on Sabo alone for those features.
Applicant "expressly reserves the right to challenge the analogousness of any of the cited references" (Remarks, § 103, introduction). No argument has been presented. For the record, Viswanathan and Sabo are in the same field of endeavor as the claimed invention, software for defining, assigning, and tracking the work of users through staged workflows. Arora is reasonably pertinent to the problem the inventors faced, connecting an item of work with the staged workflow that governs it, for the reasons stated above. In re Bigio, 381 F.3d 1320, 1325 (Fed. Cir. 2004); In re Clay, 966 F.2d 656, 659 (Fed. Cir. 1992); MPEP 2141.01(a).
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
PERTINENT PRIOR ART – Patent and Non-Patent Literature (NPL)
The prior-art made of record and considered pertinent to applicant's disclosure.
Powers et al., US 2016/0275453 A1, published September 22, 2016, first-named inventor Frederick A. Powers (35 U.S.C. 102(a)(1)). Powers describes a business collaboration platform integrated with guided navigation pages, including a page for an individual collaboration activity whose displayed data elements are selectable to open related pages (¶ [0482]), and links that "may resolve to a specific location within a collaboration project, such as a particular step in a collaboration workflow" (¶ [0454]). Powers does not describe work unit records that store a current stage value, stage-specific rules, or triggered automated actions, and it does not describe a page for a unit of work that displays its current stage and links to a page presenting the workflow's stages. Powers was relied upon in the prior Office action and is not relied upon in the rejection above.
Subbiah et al., US 2022/0335346 A1, published October 20, 2022, first-named inventor Subash Subbiah, applicant Zoho Corporation Private Limited, Application No. 17/699,072, filed March 18, 2022, claiming the benefit of Provisional Application No. 63/163,041, filed March 18, 2021 (35 U.S.C. 102(a)(2)). Subbiah describes a kanban board in which information records are grouped into buckets by stage, with a stage overview through which the user selects a stage to display the corresponding bucket, and stages that may be configured by the user (Abstract). Subbiah does not describe stage-specific rules or triggered automated actions, or navigation from a page for an individual record to a page for its workflow.
Deshpande, US 2013/0054299 A1, published February 28, 2013, first-named inventor Deepak Arun Deshpande, assignee International Business Machines Corporation, filed August 22, 2011 (35 U.S.C. 102(a)(1)). Deshpande describes a user interface in which "[a] set of steps of a workflow is presented as a set of tabs in a graphical user interface (UI)," and "[e]ach tab includes a visual indicator indicating a status of a corresponding step associated with that tab" (Abstract), with status updates to one step propagated to related steps. Deshpande does not describe work unit records of a collaboration environment that carry a stage value, stage-specific rules, or navigation from a record's page to the workflow.
Sabourin, WO 2022/109153 A1, published May 27, 2022, inventor Christopher Sabourin, applicant Flowpatterns, Inc., International Application No. PCT/US2021/059917, filed November 18, 2021, designating the United States and published in English, claiming priority to U.S. Provisional Application No. 63/115,740, filed November 19, 2020 (35 U.S.C. 102(a)(2)). Sabourin describes a system for mapping and optimizing business workflows in which process instances are tracked as their tasks are completed. Sabourin describes a user interface "configured to display process details 1901 for a process instance that is currently running," providing "the task status (e.g., number of tasks completed and number of tasks remaining)" and, in some cases, "a chronological or reverse-chronological listing of tasks to be completed for the process" (¶ [0196]; FIG. 19). Sabourin thus presents, on a single page for an item of work, the item's progress together with the ordered tasks of its process. Sabourin does not describe a stage value stored in the record, rules that apply at individual stages, automated actions triggered at stages, or a selectable element on the item's page that navigates to a separate page presenting the workflow.
Kagawa et al. 2009/0235182 [0080 - assisting and managing a collaborative activity such as contents management, project management, workflow management]
V. Freedman et al., "A collaborative extensible user environment for simulation and knowledge management," 2015 International Conference on Collaboration Technologies and Systems (CTS), Atlanta, GA, USA, 2015, pp. 280-286, doi: 10.1109/CTS.2015.7210435.
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.
THIS ACTION IS MADE FINAL
Applicant’s amendment necessitated new grounds of rejection and FINAL Rejection.
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 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b
