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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/29/26 has been entered.
Notice to Applicant
The following is a Non-Final Office action. In response to Examiner’s Final Rejection of 10/29/25, Applicant, on 1/29/26, amended claims. Claims 1-20 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
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 (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
A method for workflow processing, comprising:
Generating… a template comprising code embodying a plurality of steps, each of the steps comprising at least one task;
Generating… a workflow based on the template;
initiating an execution of an instance of the workflow…; and
during the execution of the instance of the workflow… at which the instance of the workflow is currently executing at a current step, updating the workflow comprising:
presenting, … to a user, … displaying a view of the instance of the workflow including the steps and tasks of the instance of the workflow;
receiving, …, user input navigating the interface from the view of the instance of the workflow to an add-task…;
receiving, …, via the add-task… user input identifying an additional step and an additional task;
adding…responsive to the receiving, the additional step to the instance of the workflow and adding the additional task to the added step;
validating… the added step and the added task comprising:
determining… whether the instance of the workflow is capable of executing the added step and the added task based on the current step; and
when valid, updating… the view of the instance of the workflow in the interface to include the added step and the added task and executing… the added step and the added task.”
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity” – managing personal behavior or interactions between people (including following rules or instructions), as here we are having a template of a plan for steps comprising at least one task [that can be for a person], generating a workflow [series of tasks, that can be e.g. “approval” between people – see [0060] as published – peer review, 2nd step “manager review”; 3rd step “leadership approval”] based on the template, initiating an instance of a workflow, updating the workflow to add a step and a task to the added step, validating the added step and the added task by determining whether the workflow is capable of executing the added step and the added task based on the “current step” [can be “following rules or instructions” as above, as it is checking if previous step is complete before moving to next added task in sequence (see dependent claims 6-7); or can be a comparison, which can be the abstract idea grouping of “mental process” – evaluation of whether it fits or not with no criteria specified]. Accordingly, claim 1 is directed to an abstract idea because it is generating a series of rules or instructions people follow for tasks, and checking if a next task can be added or not based on the current/previous step an whether there is a capability to add another step.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. Claim 1 recites additional elements that are:
Generating, by a computer, a template comprising code embodying a plurality of steps, each of the steps comprising at least one task;
Generating, by a computer, a workflow based on the template ;
initiating an execution of an instance of the workflow on the computer;
during the execution of the instance of the workflow on the computer at which the instance of the workflow is currently executing at a current step, updating the workflow comprising;
presenting, by the computer, a runtime user interface to a user, the runtime user interface displaying a view of the instance of the workflow including the steps and tasks of the instance of the workflow;
receiving, by the computer, user input navigating the interface from the view of the instance of the workflow to an add-task window;
receiving, by the computer via the add-task window, user input identifying an additional step and an additional task;
adding, by the computer, responsive to the receiving, the additional step to the instance of the workflow and adding the additional task to the added step;
“by the computer” [for each remaining step];
when valid, updating, by the computer the view of the instance of the workflow in the interface to include the added step and the added task and executing, by the computer the added step and the added task
This is treated as - MPEP 2106.05f applies –the claim involves a computer, and is considered “apply it [the abstract idea] on a computer”; merely uses a computer as a tool to perform an abstract idea; “machine learning” is positively recited, still would be “apply it” [abstract idea of mathematical relationships, or analysis for recommendations] on a computer”. Runtime is once the abstract idea (workflow, series of tasks) is running “by the computer” and “code embodying steps” and “user interface” along with “navigating” to an add-task “window” along with user interaction with the display are considered part of “apply it [the abstract idea] on a computer”; Examiner further notes that the current interface (i.e. display) is a “view of the instance of the workflow, and add-task window”; Applicant’s specification discloses popup window in only FIG. 5, 18A ([0060, 0076 as filed]). The combination of additional elements is viewed as MPEP 2106.05f and “field of use” MPEP 2106.05h. Here, the navigating is akin to going to a second input screen or window. See also MPEP 2106.05h “Field of use” example - “recent example of a limitation that does no more than generally link a judicial exception to a particular technological environment is Affinity Labs of Texas v. DirecTV, LLC,.. (3) contains a display that allows the user to select particular content. 838 F.3d at 1255-56). This is not similar to examples of subject matter eligible GUI aspects (a) See MPEP 2106.04a1 “ a method of rearranging icons on a graphical user interface (GUI) comprising the steps of: receiving a user selection to organize each icon based on the amount of use of each icon, determining the amount of use of each icon by using a processor to track the amount of memory allocated to the application associated with the icon over a period of time, and automatically moving the most used icons to a position in the GUI closest to the start icon of the computer system based on the determined amount of use;”; (b) MPEP 2106.05a(I) – “Improvements to Computer Functionality”- An improved user interface for electronic devices that displays an application summary of unlaunched applications, where the particular data in the summary is selectable by a user to launch the respective application. Core Wireless Licensing S.A.R.L., v. LG Electronics, Inc., 880 F.3d 1356, 1362-63, 125 USPQ2d 1436, 1440-41 (Fed. Cir. 2018).
Accordingly, the additional elements, individually or in combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a computing system [if recited in future, or based on limitation of “execution”, is treated as MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. See also MPEP 2106.05h “field of use” discussion above in Step 2A, prong two, as the combination of users being able to input information into GUI in “view”, navigating, and “window” alone as claimed and disclosed at this time are not sufficient to result in an improved GUI for purposes of 35 USC 101.
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. The claim is not patent eligible. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent claim 8 is directed to a system at step 1, which is a statutory category. Claim 11 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one, 2a, prong 2, and step 2b. The additional limitations, of processor, computer-readable memories for storing program instructions executed by processors, are all part of “apply it on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2b. The claim is not patent eligible.
Independent claim 15 is directed to an article of manufacture at step 1, which is a statutory category. Claim 15 recites similar limitations as claim 1 and claim 8 and is rejected for the same reasons at step 2a, prong one, 2a, prong 2, and step 2b. The additional limitations, of “processor”, computer readable storage media, are part of “apply it on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2b. The claim is not patent eligible.
Claims 2-7, 9-14, and 16-20 narrow the abstract idea by having various further data determined, related to tasks, workflows, templates, and claims 6-7 give more details as to whether a task can be inserted in a certain sequence/order in the workflow.
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
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, 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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Beringer (US 2007/0276714), and Nayak (US 2022/0229636) and Crew (US 2006/000514).
Concerning claim 1, Beringer discloses:
A method for workflow processing (Beringer – see par 22 - Methods and apparatuses enable generating distributed workflows that couple activities with a business scenario, and relate action to each other with request-to-perform (RTP) relationships. The workflow management environment provides different management perspectives that can be used to develop or manage a workflow. Design-time tools enable generation of building block components and workflows. Runtime tools allow dynamic management and ad hoc collaboration within workflows. see par 48 - FIG. 1 is a block diagram of an embodiment of a system with a fixed workflow having a task representing a long-running activity that includes multiple actions), comprising:
generating, by a computer, a template comprising code embodying a plurality of steps, each of the steps comprising at least one task (Beringer – see par 27 - A workflow can be defined in part, or partially through a template, and additional details or complete resources/actions may be included after initial design-time.);
generating, by the computer a workflow based on the template (Beringer – see par 42 - Regarding design-time components, simplified design times enable business experts to model scenarios and activities. Scenarios that already exist within an enterprise can serve as templates for new processes; see par 59 - Runtime engine 264 represents one or more modules that enable runtime generation of a workflow. Note that certain templates or components as defined in design-time may be defined based on a business role, rather than based on a specific person);
initiating an execution of an instance of the workflow on the computer (Beringer – see par 57 - Workflows as described herein include various aspects--design-time components include templates and building blocks that represent the workflow and its constituent elements (e.g., actions, resources, etc.); runtime components include instantiated versions of the templates and building blocks in a workflow for execution; and, distributed workflows as described herein include context, which relates to a business scenario to which the workflow components are related. see par 59 - Runtime engine 264 represents one or more modules that enable runtime generation of a workflow. Note that certain templates or components as defined in design-time may be defined based on a business role, rather than based on a specific person. At runtime, the system resolves such dynamic variables and assigns actual values to the dynamic template or generic values of the templates. Runtime engine 264 enables the system to create a workflow specific to a given situation or function, referred to as a business context. Runtime engine 264 either includes context engine 266 or works in conjunction with context engine 266 to determine the context of a workflow to be generated); and
during the execution of the instance of the workflow on the computer at which the instance of the workflow is currently executing at a current step, updating the workflow comprising:
presenting, by the computer, a runtime user interface to a user, the runtime user interface displaying a view of the instance of the workflow including the steps and tasks of the instance of the workflow (Beringer – see par 53 - Client device 210 includes user interface 220, which represents one or more input and output components that enable a user to interact with an item represented in the UI. UI components may include touchscreens, displays, keypads, etc. See par 77, FIG. 5 - System 500 may have design-time components that define components and workflows. System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow. Additionally, the workflow management environment can enable viewing status and interactions that take place as part of a user performing work; the interactions can be incorporated into the workflow. See par 80, FIG. 5 - Selecting one of the tabs (e.g. ask 532, resource 534, conversation 536, list 542, and role 544) can cause a dynamic change in what information is presented and/or how the information is presented. The layout of system 500 can be for designing, as well as modifying a workflow, such as incorporating ad hoc parts into a process);
receiving, by the computer, user input navigating the interface from the view of the instance of the workflow to an add-task … (Beringer –see par 57 - runtime components include instantiated versions of the templates and building blocks in a workflow for execution; see FIG. 8, par 93 - “development layout 810; triggering an activity for one performer may trigger a long running activity that generates other requests from that performer to other performers. As illustrated, perform block 840 of purchasing 826 may generate request 842 that triggers perform block 844 of processor 828, and request 848 that triggers perform block 850 of processor 828. Request 846 of purchasing 826 is related to an activity that is "off screen" with respect to the view of development layout 810 of FIG. 8; see par 96 - In one embodiment, layout tools 860 also includes tools to create new performer 872, or create new block 874, which can enable a developer or user to define new components to include within the workflow);
PNG
media_image1.png
408
638
media_image1.png
Greyscale
Bering discloses in FIGS. 5A-5B having additions made to a workflow using tool panel 510. Nayak discloses in FIG. 4 having an actions design panel for adding actions/subtasks or additional instructions (See par 22).
Crew discloses having an add-task “window” (Crew discloses entire limitation - see FIG. 4C, par 65 - An `Add activity` button 315 as seen in the GUI 301 is used to add a new activity, which by default will be inserted immediately above the final activity 305. See FIG. 5, par 98 – browser window titled “Add /Edit Activity; see FIG. 8, par 93 - “development layout 810; triggering an activity for one performer may trigger a long running activity that generates other requests from that performer to other performers. As illustrated, perform block 840 of purchasing 826 may generate request 842 that triggers perform block 844 of processor 828, and request 848 that triggers perform block 850 of processor 828. Request 846 of purchasing 826 is related to an activity that is "off screen" with respect to the view of development layout 810 of FIG. 8; see par 96 - In one embodiment, layout tools 860 also includes tools to create new performer 872, or create new block 874, which can enable a developer or user to define new components to include within the workflow).
PNG
media_image2.png
392
488
media_image2.png
Greyscale
PNG
media_image3.png
676
492
media_image3.png
Greyscale
Beringer, Nayak, and Crew disclose:
receiving, by the computer, via the add-task window user input identifying an additional step and an additional task (Crew – see FIG. 4C, par 65 - An `Add activity` button 315 as seen in the GUI 301 is used to add a new activity, which by default will be inserted immediately above the final activity 305. See FIG. 5, par 98 – browser window titled “Add /Edit Activity”; see par 109-113 - ) The "Activity Category" 501 is set according to the value of the activity being edited. Also, the "Activity Name" 504 is populated according to the name of the activity being edited. [0112] (c) The "Description" 505 is populated according to the description of the activity being edited. [0113] (d) The activity selector 509 is populated. The selector 509 contains an entry for every activity descriptor available to be added to a workflow process, which is of the selected activity category 615. In this example, the activity selector 509 includes a "process/activity type" of "Formreader" with a "document name" of "Loan_application);
adding, by the computer responsive to the receiving, the additional step to the instance of the workflow and adding a task to the added step (Beringer – see par 77 - System 500 may have design-time components that define components and workflows. System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow.);
Beringer discloses “Preconditions 940 enable the user or the system to make sure all resources and conditions necessary for the performance of the task are complete. For example, if a task is to request a part from a certain vendor, a necessary precondition for requesting the part is to make sure the vendor exists within the system” (See par 101) and modifying a workflow ad hoc (See par 77, 80).
Nayak discloses:
validating the added step and the added task comprising:
determining whether the instance of the workflow is capable of executing the added step and the added task based on the current step (Applicant’s specification only supports the limitation in two places – [0012] as published “dynamically updating the workflow can comprise adding a step to the workflow, adding a task to the added step, and validating the added step and the added task. The validating can comprise determining whether the instance of the workflow is capable of executing the added step and the added task based on the current step and when valid, executing the added step and the added task. [0013] In some embodiments, initiating the execution of the instance of the workflow can comprise defining the instance of the workflow as a dynamic workflow and configuring the execution of the instance of the workflow to permit adding the step to the workflow and adding the task to the added step. [0014] In some embodiments, determining whether the instance of the workflow is capable of executing the added step and the added task based on the current step can comprise determining whether the added task is insertable between one or more completed steps of the workflow and one or more upcoming steps of the workflow. Nayak discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 20 - Custom attributes 224 that are not included in the template library 210 may also be constructed using a design portal 220. The custom attributes 224 may include any user defined workflow component (e.g., event, action, trigger, rule, condition, etc.) The custom attributes 224 created by users are auto-configured by the workflow construction system 204 so that they are compatible with the workflow templates 212 and pre-configured attributes 214. For example, the auto-configured custom attributes 224 may be inserted into a workflow template 212 and or interchanged with a pre-configured attribute 214 with no additional coding or manual configuration; see par 36 - For example, a confirmation that confirms an action 254 included in the workflow model file 250A is complete will be detected as a trigger 256 that identifies the workflow model file 250A as in the workflow state 252 that includes the particular action. Additionally, receiving confirmations for all actions 254 included in a workflow state 252 is another possible trigger 256 for transitioning the workflow model file 250A to a new workflow state 252; see par 37 - The conditions 259 may include one or more characteristics of an event or other trigger 256. For example, a condition 259 for the invoice approval workflow model file may require the invoice amount to be above a certain amount threshold to initiate the automation workflow included in the invoice approval workflow model file.)
Beringer and Nayak (disclosing “validate/valid”), in combination disclose:
when valid, executing the added step and the added task Beringer – see par 93 - In one embodiment, triggering an activity for one performer may trigger a long running activity that generates other requests from that performer to other performers; see par 101 - Preconditions 940 enable the user or the system to make sure all resources and conditions necessary for the performance of the task are complete. For example, if a task is to request a part from a certain vendor, a necessary precondition for requesting the part is to make sure the vendor exists within the system.
Nayak – see par 21 - FIG. 4 illustrates an example workflow design UI 400 used to design custom workflows 222. The illustrated workflow design UI 400 includes a conditions design panel 402 used to create one or more conditions. The conditions generated using the conditions design panel 402 may, for example, control the beginning of the automation workflow, transitions from one workflow state to another workflow state, the end of the automation workflow, and the like. Conditions parameters can also be manually entered by typing the particular parameters in the corresponding drop down boxes. In comparison to other automation tools, which require coding custom conditions and other custom attributes in a programming language, custom attributes for the automation workflows are auto-configured by the design portal 220; see par 22 - The actions design panel 404 may also allow conditional logic 412 to be added to the instructions 408. The conditional logic 412 defines when to perform the processing steps included in the instructions 408 (i.e., send the notification after detecting a specific trigger and or condition) and or additional instructions related to the action and or subtask included in the action. For example, the conditional logic 412 for the send notification action may include a condition to send a reminder notification to complete the subtask mentioned in the notification if the subtask is not completed within seven days of sending the notification.)..
Beringer, Nayak, and Crew are analogous art as they are directed to workflows with tasks for people (see Beringer Abstract, Nayak Abstract; Crew Abstract). 1) Beringer discloses “Preconditions 940 enable the user or the system to make sure all resources and conditions necessary for the performance of the task are complete. For example, if a task is to request a part from a certain vendor, a necessary precondition for requesting the part is to make sure the vendor exists within the system” (See par 101) and modifying a workflow ad hoc (See par 77, 80). Nayak improves upon Beringer by disclosing not only allowing additional tasks/subtasks, but also allowing entry with custom attributes; and transitions for workflow states and condition parameters. One of ordinary skill in the art would be motivated to further include checking rules, having customer attributes that are compatible, conditions, and confirmations for tasks to efficiently improve upon the “preconditions” for completion of a task and the ad hock modifications of workflows in Beringer. 2) Bering discloses in FIGS. 5A-5B having additions made to a workflow using tool panel 510. Nayak discloses in FIG. 4 having an actions design panel for adding actions/subtasks or additional instructions (See par 22). Crew improves upon Bering and Nayak by disclosing having a window or screen for entering information for adding a task to a workflow or process with a series of tasks/activities. One of ordinary skill in the art would be motivated to further include window or screen for entering information for adding a task to a workflow or process to efficiently improve upon the adding items to a workflow from a “pane” in a GUI in Beringer and the actions design panel for adding things in a graphical user interface in Nayak.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for having a template for a workflow at design-time, and allowing additional actions included after design-time in Beringer (See par 27, 77, 80), to further include entry with custom attributes; and transitions for workflow states and condition parameters in Nayak, to explicitly have a new window for adding tasks/activities in a process as disclosed in Crew, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 8, Beringer and Nayak and Crew disclose:
A system for workflow processing (Beringer – see par 22 - Methods and apparatuses enable generating distributed workflows that couple activities with a business scenario, and relate action to each other with request-to-perform (RTP) relationships. The workflow management environment provides different management perspectives that can be used to develop or manage a workflow. Design-time tools enable generation of building block components and workflows. Runtime tools allow dynamic management and ad hoc collaboration within workflows. see par 48 - FIG. 1 is a block diagram of an embodiment of a system with a fixed workflow having a task representing a long-running activity that includes multiple actions), comprising:
a processor (Beringer – see par 48 - System 100 represents an enterprise system that includes client device 120, and workflow 110. Workflow 110 is an application or an enterprise system control structure that is typically executed from a backend enterprise system. One or more components of workflow 110 could be executed locally on client device 120; however, workflow 110 will generally be considered to be executing on a system level via business logic and enterprise services available from the backend system; see par 53- FIG. 2 is a block diagram of an embodiment of a system for generating workflows from reusable components. System 200 includes client device 210 and backend system 240. Client device 210 represents any of a number of devices with which a user may interface with a workflow. See par 56- backend system 240 represents one or more enterprise servers, databases, etc.);
a non-transitory computer-readable medium (Beringer – see par 60 - Each component described herein includes software, hardware, or a combination of these; Software content (e.g., data, instructions, configuration) may be provided via an article of manufacture including a machine readable medium, which provides content that represents instructions that can be executed.); and
stored instructions translatable by the processor for executing:
(Beringer – see par 60 - A machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., computing device, electronic system, etc.), such as recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc)):
The remaining limitations are similar to claim 1 above. Claim 8 is rejected for the same reasons.
It would be obvious to combine Beringer and Nayak and Crew for the same reasons as claim 1.
Concerning independent claim 15, Beringer and Nayak and Crew disclose:
A computer program product for workflow processing (Beringer – see par 22 - Methods and apparatuses enable generating distributed workflows that couple activities with a business scenario, and relate action to each other with request-to-perform (RTP) relationships. The workflow management environment provides different management perspectives that can be used to develop or manage a workflow. Design-time tools enable generation of building block components and workflows. Runtime tools allow dynamic management and ad hoc collaboration within workflows. see par 48 - FIG. 1 is a block diagram of an embodiment of a system with a fixed workflow having a task representing a long-running activity that includes multiple actions; see par 53- FIG. 2 is a block diagram of an embodiment of a system for generating workflows from reusable components. System 200 includes client device 210 and backend system 240. Client device 210 represents any of a number of devices with which a user may interface with a workflow. See par 56- backend system 240 represents one or more enterprise servers, databases, etc) comprising a non-transitory computer-readable medium storing instructions translatable by a processor to execute: (Beringer – see par 60 - Each component described herein includes software, hardware, or a combination of these; Software content (e.g., data, instructions, configuration) may be provided via an article of manufacture including a machine readable medium, which provides content that represents instructions that can be executed; A machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., computing device, electronic system, etc.), such as recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc).
The remaining limitations are similar to claim 1 and 8 above. Claim 15 is rejected for the same reasons.
It would be obvious to combine Beringer and Nayak and Crew for the same reasons as claim 1.
Concerning claim 2, 9, and 16, Beringer and Nayak disclose:
The method of claim 1, wherein executing the added step and the added task comprises:
updating the template based on the added step and the added task (Beringer – see par 27 - Such an ad hoc definition can become a template, or simply part of the individual workflow instantiation;
see also Nayak – see par 20 - The custom attributes 224 may include any user defined workflow component (e.g., event, action, trigger, rule, condition, etc.) The custom attributes 224 created by users are auto-configured by the workflow construction system 204 so that they are compatible with the workflow templates 212 and pre-configured attributes 214. The auto-configured custom attributes 224 may also be added to the template library 210 for future use; see par 25 - For example, custom workflows 222 that automate processes that are not associated with any of the workflow templates 212 may be added to the template library 210. Additionally, custom workflows 222 that modify one or more of the workflow templates 212 to fit user specific processes and systems may also be added the template library 210. Custom attributes 224 including new states 252, actions 254, and triggers 256 may also be added to the template library 210. For example, new actions 254 including calculations, new conditional logic, and the like may be added to the template library 210).
It would be obvious to combine Beringer and Nayak for the same reasons as claim 1.
Concerning claims 3, 10, and 17, Bering discloses “a workflow may be designed in part in design-time, and completed in a more ad hoc manner with the workflow management environment described herein. Additionally, the workflow management environment can enable viewing status and interactions that take place as part of a user performing work; the interactions can be incorporated into the workflow” (See par 77). Beringer discloses “As for design-time, the conversation components can make up a flow that is saved in whole or in part as a template or as part of the workflow model for the current business process” (see par 81). Beringer discloses “define perform blocks of a workflow (See par 97). Beringer also discloses having a “performance” tab (804, 904 in FIG. 8-9) where “Measure performance 926 allows performance parameters become part of the model to know what performance is expected, and have a measure of how performance actually matched with expectations” (See par 98). Beringer “A workflow can be defined in part, or partially through a template, and additional details or complete resources/actions may be included after initial design-time” (see par 27). Nayak discloses creating a user defined action, such as when a notification is sent to a person for approval (See par 22).
While Beringer discloses measuring performance (926) and defining workflow (984 ; FIG. 9, par 97-98), it does not explicitly discuss how the progress is monitored as best understood.
Crew discloses:
The method of claim 1, wherein generating a template is performed during a design time of the workflow processing (Crew – see par 46 - To facilitate the configuration of a workflow process, the workflow process is displayed within a user interface which enables a user to manipulate the workflow process. FIG. 6 shows a class diagram describing the high level design of a workflow process, as well as the components required to load, store, and manipulate the process. see par 47 - A workflow process 601 comprises a set of activities, of which one activity 603 is seen in FIG. 6. Each activity 603 represents a unit of work to be done within the workflow process 601. The activity 603 that is executed when a new instance of the workflow process 601 is commenced is marked as an initial activity 602 of the workflow process 601. An activity 603 typically has a set of transitions 607--one transition 607 for each of the possible outcomes of the activity 603. A terminal activity of a workflow process 601 will not have an outcome as such an activity concludes the process 601.), the design time further comprising:
Bering in combination with Crew and Nayak discloses:
configuring a workflow layout for the plurality of steps and tasks of the steps (Beringer - see par 106 - FIG. 10 is a block diagram of an embodiment of project status monitoring. Project monitoring status may be selected for the workflow management environment via tab activity plan 1002 for business scenario purchase external services 1000. In one embodiment, selecting tab 1002 brings up status layout 1010, which is a status window 1012;
See also Crew – see par 47 - Each transition 607 stores a unique identifier of a next activity 603 in the process 603 that should be executed, to give a particular outcome. This is seen in FIG. 6 as the "destination" or "target" 609 of the transition 607. Each transition 607 is also given a name 608, which is unique within set of transitions 607 for the activity 603. See par 53 - In a preferred implementation, a set of transitions 607 for an activity 603 is determined by its corresponding activity descriptor 613. That is, all instances of a given activity 603 will have the same set of transitions 607. Also preferably, the set of outcomes for a given activity 603 are stored as a set of required transitions 616, belonging to the activity descriptor 613. ); and
configuring a workflow progress for the plurality of steps and tasks of the steps (Beringer – see par 106 - FIG. 10 is a block diagram of an embodiment of project status monitoring. see par 107 - The specific status of each relationship can be shown in specify 1050. For example, the marketing manager request as initiator to the business manager as approver to approve the statement of work (SOW), is specified as incomplete. Furthermore, as illustrated, a connection to a resource is either missing or does not exist. Playback of the activity might be attempted and failed due to the missing resource. Other layouts are possible that can show the same and/or different information. Importantly, the status layout allows a view of various parts of a workflow, and their relationships;
see also Nayak – see par 38 - change the current workflow state of the workflow model files 250A, . . . , 250N, track the workflow state of the workflow model files 250A;
see also Crew par 3 - In general, workflow applications for automating business processes automate the flow of documents and other information between persons in order to fulfil the requirements of a particular process and to track the progress of the process. see par 57 - In an alternate implementation, provision may be made to initiate another process upon completion of the current process, using the destination selector of the final activity as a means of selecting the next process. See par 82 - When step 907 is concluded, step 908 checks to determine if any more activities remain to be processed.).
It would be obvious to combine Bering, Nayak, and Crew for the same reasons as claim 1. In addition, Bering discloses “a workflow may be designed in part in design-time, and completed in a more ad hoc manner with the workflow management environment described herein” (See par 77); “define perform blocks of a workflow (See par 97); and having a “performance” tab (804, 904 in FIG. 8-9) where “Measure performance 926 allows performance parameters become part of the model to know what performance is expected, and have a measure of how performance actually matched with expectations” (See par 98). Nayak discloses creating a user defined action, such as when a notification is sent to a person for approval (See par 22). Crew improves upon Bering and Nayak by disclosing tracking progress; selecting next process upon completion; determining which activities remain to be processed (see Crew par 3, 57, 82).
Concerning claim 4, 11, and 18, Beringer and Nayak disclose:
The method of claim 1, wherein initiating the execution of the instance of the workflow comprises:
defining the instance of the workflow as a dynamic workflow (Beringer – see par 27 - The resulting design-time provides a flexible approach with multiple perspectives for different roles (e.g., individual performers, process orchestrator, action (service) enabler, etc.). Additionally, the flexibility can extend to dynamic definition of a workflow.); and
configuring the execution of the instance of the workflow to permit adding the step to the workflow and adding the task to the added step (Beringer – See par 27 - . A workflow can be defined in part, or partially through a template, and additional details or complete resources/actions may be included after initial design-time. Workflow can be incrementally defined starting with a partially defined distributed workflow (e.g., missing one or more performers, missing one or more activities, missing a resource). see par 77 - System 500 may have design-time components that define components and workflows. System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow;
See also Nayak – see par 22 - For example, the action parameters may include action identification information 406 for the user(s) or computer system(s) assigned to receive the actions 254 and instructions 408 to perform the processing steps required by the action 254 (e.g., instructions to send a notification that distributes the a subtask to the user(s) and or computer system(s) according to the contact information 410). The actions design panel 404 may also allow conditional logic 412 to be added to the instructions 408. The conditional logic 412 defines when to perform the processing steps included in the instructions 408 (i.e., send the notification after detecting a specific trigger and or condition).
It would be obvious to combine Beringer and Nayak for the same reasons as claim 1.
Concerning claim 5, 12, and 19, Beringer and Nayak disclose:
The method of claim 1, wherein the at least one task comprises a task type (Beringer – see par 57 - Templates 248 represent other building blocks, and may include associations or relationships that relate one or more actions or activities to a context. In one embodiment, templates 248 cannot exist without context; thus, templates 248 can be considered to include context that defines relationships between components 246.), a user assigned to the task (Beringer – see par 91 - development layout 810 includes multiple potential views, for example, assign performers 812, and define roles 814. Assign performer 812 allows the business scenario modeler to define who will participate in the workflow, and can be defined by role (shown), skill, or by name).
Bering discloses having different aspects of the task (See par 91 – assign role or name for parts of workflow; see FIG. 8). Beringer also discloses having a “performance” tab (804, 904 in FIG. 8-9) where “Measure performance 926 allows performance parameters become part of the model to know what performance is expected, and have a measure of how performance actually matched with expectations” (See par 98).
Nayak discloses:
and a task due date (Nayak – see par 18 - reminders and notifications (e.g., sending reminders for overdue tasks; see par 22 - conditional logic 412 for the send notification action may include a condition to send a reminder notification to complete the subtask mentioned in the notification if the subtask is not completed within seven days of sending the notification.).
It would be obvious to combine Beringer and Nayak for the same reasons as claim 1. One of ordinary skill in the art would be motivated to further include having tasks that can become overdue or a day of completion to efficiently improve upon the descriptions of tasks having expected performance in Beringer.
Concerning claim 6, 13, Beringer discloses “Selecting one of the tabs can cause a dynamic change in what information is presented and/or how the information is presented. The layout of system 500 can be for designing, as well as modifying a workflow, such as incorporating ad hoc parts into a process” (see par 80).
Nayak discloses:
The method of claim 1, wherein determining whether the instance of the workflow is capable of executing the added step and the added task based on the current step comprises:
determining whether the added task is insertable between one or more completed steps of the workflow and one or more upcoming steps of the workflow (Nayak – see par 30 - The suggested workflow templates 244 may include automation workflows for new processes that have not been automated and modified versions of workflow templates 212 that are adapted to user specific processes. For example, the machine learning models 246 may generate a suggested workflow template 244 for an invoice approval workflow that modifies the invoice approval workflow template 212 to fit a user specific approval hierarchy; See par 39 - The roles and permissions can also include a particular approval hierarchy of an automation workflow included in a workflow model file. The approval hierarchy describes a particular sequence of approvals that must be completed in a particular order to complete the process of the workflow model file).
It would be obvious to combine Beringer and Nayak for the same reasons as claim 1.
Concerning claim 7, 14, and 20, Beringer and Nayak disclose:
The method of claim 6, wherein the at least one task is a plurality of tasks, each task comprising a task type, the task type from a predefined set of task types, the added task comprising a task type from the predefined set of type tasks, wherein adding a task to the added step comprises setting the task type of the added task to one of the task types in the predefined set of task types (Beringer – see par 57 - templates 248 represent other building blocks, and may include associations or relationships that relate one or more actions or activities to a context. templates 248 can be considered to include context that defines relationships between components 246; see par 58 - In one embodiment, design-time engine 262 includes modules necessary to provide a development environment in which a developer can generate actions, activities, context (business process or scenario) descriptions, templates, relationships (which may include RTP relationships), resource associations, etc., which are considered the constituent elements of a workflow; See par 103, FIG. 9 – Work pane 970; Different classes of tools may be available, such as shown by specify 972; Examples of various tools may include description 982, define 984, assign 986, trigger 988, connect 990, monitoring 992, and flow control 994. see par 104 - Description 982 may provide a system-level description of a block or a part of a block, or provide explanation as to what parameters or input is needed to model something. Define 984 can provide input boxes, selection lists, check boxes, parameter lists, etc., to define a request, an action, or some resource, or any of the blocks shown to the left of work pane 970. Assign 986 provides tools to assign relationships between actions and performers, resources and scenarios, etc. Such assignments can be made via …selection lists, side-by-side pull-down lists, etc), and determining whether the added task is insertable comprises:
Beringer discloses having a “flow control 994” when defining the workflow and activities where “Flow control 994 enables defining the state changes from one block to another. That is, system action after a particular block has been performed can be prescribed, and ownership (and/or responsibility) can be defined for activities” (See par 105; see also par 101 above – checking preconditions 940).
Nayak discloses:
based on a comparison of the task types of one or more of the plurality of tasks and the added task, determining whether the added task is executable after the current step and at least one task that will be completed before and up to the current step and whether added task is executable before at least one task to be executed after the added task (Nayak – see par 22 - the conditional logic 412 defines when to perform the processing steps included in the instructions 408 (i.e., send the notification after detecting a specific trigger and or condition) and or additional instructions related to the action and or subtask included in the action. For example, the conditional logic 412 for the send notification action may include a condition to send a reminder notification to complete the subtask mentioned in the notification if the subtask is not completed within seven days of sending the notification. See par 23 - The attributes 214 can also be pre-configured by automatically setting one or more conditions for executing automation workflows and or transitioning between states 252. For example, a condition for executing an invoice approval workflow may be pre-set to receive an invoice of a particular dollar amount (e.g., an invoice for more than $1,000). A condition for triggering completion of the invoice review state of the approval workflow may be pre-set to completing an invoice review action. See par 33 - The workflow properties 232 may include user specific rules and conditional logic such as threshold values, department and location matching attributes, and the like. The workflow properties 232 enable the custom workflows 222 to be compatible with one or more in-product applications or external applications).
Examiner notes claim 20 recites both limitations from claims 6-7 above. Claim 20 is rejected for the same reasons as claims 6-7 above.
It would be obvious to combine Beringer and Nayak for the same reasons as claim 1.
Response to Arguments
Applicant's arguments filed 1/29/26 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With respect to 101, Applicant argues that the claim is not directed to an abstract idea since “only three snippets of the claim” are considered. Remarks, pages 9-10. In response, Examiner respectfully disagrees. The 101 rejection considers eleven of the limitations to be part of the abstract idea, as shown in the 2a, prong one section of the rejection. The claim is considered individually and in combination in the section, and the argument is not persuasive. Applicant then argues 1) that tasks being “for a person” is not directed to an abstract idea because there is a “template comprising code.” Remarks, page 10. Examiner respectfully disagrees. The “template comprising code” is considered as an additional element in the step 2a, prong two and step 2B analysis, where it is “apply it [abstract idea] on a computer” (MPEP 2106.05f). The tasks here are still part of the consideration of it being “directed to an abstract idea,” as they are tasks for people governing organization/business aspects. Applicant then argues 2) that “generating… a workflow” also is related to a “computer based on a template comprising code. Remarks, page 10. Examiner respectfully disagrees. The “template comprising code” is considered as an additional element in the step 2a, prong two and step 2B analysis, where it is “apply it [abstract idea] on a computer” (MPEP 2106.05f). The workflow here are still part of the consideration of it being “directed to an abstract idea,” as they are workflow is for people governing organization/business aspects. Applicant notes that the tasks, approvals, peer reviews, manager reviews “cannot be performed by a person.” Examiner disagrees – the computer displays the information on the tasks, that the user performs or is assigned. See Applicant then argues 3) that initiating the workflow instance, updating, it and validating it are “performed by a computer” and therefore is not directed to an abstract idea. Remarks, page 10. Examiner respectfully disagrees. The pre-Alice test (pre-2014) only required a computer to pass 101. Alice requires more than just a computer to reach eligibility. Hence the computer is analyzed as an additional element at step 2a, prong two and step 2B. See MPEP 2106.05(f) “"apply it" (or an equivalent) or are more than mere instructions to implement an abstract idea or other exception on a computer.” The arguments are not persuasive here.
Applicant then argues with regards to Step 2a, prong two (practical application) that though “instance” is well known in the art for executing a process on a computer, therefore, a computer is required, and MPEP 2106.05f does not apply. Remarks, pages 11-12. In response, Examiner respectfully disagrees. Just requiring a computer alone, even with “well known” instance and code, does not mean we have a practical application. We would need an improvement in computing technology, or some other technology, under MPEP 2106.05(a), or “meaningful limitations” under MPEP 2106.05e.
Applicant then argues the interface with an “add-task window” is similar to Core Wireless because there is a UI that “presents and receives information” used to modify ongoing workflow. Remarks, pages 10-13. In response, Examiner respectfully disagrees. MPEP 2106(a)(I) summarizes Core Wireless decision as “An improved user interface for electronic devices that displays an application summary of unlaunched applications, where the particular data in the summary is selectable by a user to launch the respective application. Core Wireless Licensing S.A.R.L., v. LG Electronics, Inc., 880 F.3d 1356 (Fed. Cir. 2018). The claims here, as explained in the revised rejection addressing limitations (e.g. window), the presence of a computer here with a GUI (e.g. user interface, view, navigating to a window) are additional elements. However, the window is just for entering data by a user. In contrast to Core Wireless, the claims here have a second screen or a pop-up window, with little explanation in the specification, is not sufficient at this time to make the claim eligible and is not similar to Core Wireless.
Applicant then argues with that Examiner’s “broadest reasonable interpretation in light of the specification” is “divorced from the specification.” Remarks, pages 14-16. In response, Examiner respectfully disagrees. The 101 rejection is grounded on viewing Applicant’s specification which throughout is representing business processes and tasks (See e.g. FIG. 2, 5 – “permit approval” workflow; task ; user ; FIG. 3-4 – peer review; manager review; leadership approval; FIG. 19 “purchase requisition” – task name; assigned to a user, with a due date; for a “purchase flow”; see [0060] as published – peer review, 2nd step “manager review”; 3rd step “leadership approval; [0061] as published - In this example, the user specifies a new task, “Legal Review” 522 and enters/selects values for parameters such as “Task Name,” “Task Type,” “Assigned to,” “User,” “Due in days,” “Sequence to,” “Task actions behavior,” and “Priority” (entered via task input data fields 524).
With regards to 103, Applicant argues that Nayak is for “workflow designs”, and does not disclose “validating the added and the added task comprising: determining whether the instance of the workflow is capable of executing the added step and the added task based on the current step” because Nayak does not determine whether a n added step is “capable” of being executed by the computer to ensure it is compatible. Remarks, page 15-16. In response, Examiner respectfully discloses. The claim only states it needs to validate whether the workflow is “capable of” executing an added step. Bering discloses having “preconditions” for tasks (See par 77, 80). Nayak discloses looking at attributes including “trigger, rule, condition, so the custom attributes are “compatible” with the workflow templates. Applicant’s only support is [0012-0014] as published. where [0012] as published states “dynamically updating the workflow can comprise adding a step to the workflow, adding a task to the added step, and validating the added step and the added task. The validating can comprise determining whether the instance of the workflow is capable of executing the added step and the added task based on the current step and when valid, executing the added step and the added task.” Beringer and Nayak disclosure render the limitation obvious.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
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, Anita Coupe can be reached at 571-270-3614. 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.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619
Prosecution Insights