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-6, 8-13, and 15-19 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The 112b rejections are withdrawn in light of the amendments and remarks (pages 10-11).
The 101 rejections are withdrawn, as when the claim is viewed in combination, it is viewed as not directed to an abstract idea, or meaningful limitations (MPEP 2106.05e) based on the specific flow in the claim of design time and run time, building blocks comprising code instantiated from a corresponding class, an application executing on a computer, defining at design time a dynamic workflow progress panel, an instantiating instance of workflow panel based on interaction in a first layout panel, then displaying view of steps and tasks in a second layout panel and including a UI element linked to an add-task window of the UI (user interface), receiving navigation to add-task window, adding additional step and task received via add-task window, where add-task window enables user input to configure a task type using a task type building block and task configuration using a task configuration building block, and responsive to user interaction with task configuration building block, creating or specifying a layout for the task type.
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-6, 8-13, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Beringer (US 2007/0276714), and Herter (US 2013/0159034) and Crew (US 2006/000514).
Concerning claim 1, Beringer discloses:
A method (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:
at design time, enabling a dynamic workflow feature (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), the enabling comprising adding a dynamic workflow building block to an entity in a modeling project (Beringer – see par 22 - Design-time tools enable generation of building block components and workflows. See par 24 - The actions are modeled components, where the model defines the actions in a way the system can manage. The modeled actions define resources related to a business activity. The individual activities can be instantiated and related with RTP relationships to result in a workflow that can be generated and managed by the enterprise system. See par 29 - The back and forth between runtime and design time, and a simplified visualization of distributed activities with different modeling levels provides a level of workflow design/creation and management not previously available. Different modeling levels may include, for example, scenarios, activities of individual contributors, actions as reusable building blocks, and completion status of building blocks. See par 42 - The design-time components are embodied in a design-time engine, which may include separate components (e.g., separate modules), or may include the functionality of each of the below; 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; see par 65 - Context determiner 336 can determine the context by accessing metadata about a business process or business scenario, or metadata about a system or application from which a business process is requested) defined in an entity-based application executing on a computer (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 60-61, FIG. 3 - various components described herein may be a means for performing the functions described. 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. Client 310 represents an application or a program that provides workflow access to a user (e.g., a user, a manager). see par 66, FIG. 3 - Backend 340 may include non-volatile storage that stores code for executing client 310 and process map designer 312.), the dynamic workflow building block comprising a task type building block (Beringer – see par 33 - he Activity Model allows actions to be generated as components or building blocks that can define individual actions or operations that will be performed by a user in context of one activity; see par 38 - According to the teachings herein, an enterprise system can model a business process on multiple layers. In one embodiment, a business process is modeled on three layers: Scenario, Activity (task), and Action. A scenario layer exists on a first level, where a developer lays out the activities of users, and connects activities of one or several users through an event-driven control flow, such as RTP relationships. Rather than inputting a particular person into the business process, the business process can be defined in terms of a role, or a "type" of person that can/should perform a particular action; see par 40 - An activity block is a collection of actions, information, and related resources that one user needs to accomplish the requested task. Each activity block may provide guidance for individual performers in terms of what actions to perform, and the checking of preconditions, required resources, and business rules. Each activity can be enriched to offer related information and actions. ) and a task configuration building block (Applicant’s specification [0068] as published “As illustrated in FIG. 10, with the task configuration building block, task actions can be defined and each task type can be mapped to a task action. In some embodiments, the task configuration building block supports a set of task actions: “complete,” “approve,” and “acknowledge.” FIG. 10 states “Summary: “Task configuration holds the relations that are used for capturing task configurations”; Actions shown include Approve, inquire, reject; “Configuration” also includes “Map a task type task to a custom enumerated text of a property such that the property value will be updated based on the mapping” – includes “task type” (for information, processing, or review) “action” (acknowledge, approve, complete), and selecting layouts
Beringer discloses the limitations based on broadest reasonable interpretation in light of the specification – See par 42 - Reusable actions enable business experts to configure an activity without implementing any service or UI. The design-time components are embodied in a design-time engine, which may include separate components (e.g., separate modules), or may include the functionality of each of the below. In one embodiment, a Process Map diagram tool or function is used to lay out processes. see par 62 - Resource 320 represents any of a number of workflow building block components that can be accessed and provided to a layout in process map designer 312. Resource 320 can be loaded into memory 302 where it is accessible to client 310. Resource 320 may be an action, which includes any of a number of atomic business acts, such as those provided above. Resource 320 may also be any type of workflow resource, such as a document, a file, an enterprise service, a business object, etc. Resource 320 may also be a conversation component, or an input or contribution to a human-to-human interaction that occurs within the context of fulfilling an activity of a workflow.), each of the building blocks comprising code instantiated from a corresponding class (Applicant’s [0054] as filed states “ Each building block comprises code instantiated from a class to implement certain settings that can be added to an entity. Such settings may be structural, decorative, and/or functional. In some embodiments, decorative and functional building blocks are treated the same way—as structural building blocks. In some embodiments, these building blocks can be used by entity model builders to assemble or compose entities in a particular project via an entity model designer tool of the entity modeling system.”
Beringer – see par 58 - Design-time engine 262 represents one or more modules that enable generation of a workflow and/or its constituent elements. Once developed or generated, these elements can be stored in one or more databases, represented as components 246 and templates 248, which are available to instantiate a workflow; see par 103 - Work pane 970 can provide various tools or functions that can be useful or necessary to define or model one or more aspects of the activity. Different classes of tools may be available, such as shown by specify 972 (tools to define or specify aspects of a block), compose 974 (tools to generate the modeled/defined activity), and connect 976 (tools to define relationships or requests). Examples of various tools may include description 982, define 984, assign 986, trigger 988, connect 990, monitoring 992, and flow control 994.);
at design time, defining by the entity-based application a task type using the task type building block (Applicant’s example FIG. 9C has “task type” for “information” or “for review” where “this building block holds different task types and allows the addition of task types of your choice.”
Beringer – see par 38 – Activity (task); See par 39 - Scenarios are composed by defining activity blocks, assigning them to process roles, and linking them through requests; See par 40 - A request event triggers an activity that models personal contributions in the form of a context description that defines potential actions, resources, rules, and related information associated with the activity. The activity may also include requests to other contributors to perform certain activities. An activity can further be split into separate actions that accomplish a task. As used herein, a task refers to a phase of a workflow. A task is some work or action (which could be an Action as described below), or something to do or accomplish. Tasks may be the subject of requests. An activity block is a collection of actions, information, and related resources that one user needs to accomplish the requested task. see par 77 - Tool panel 510 illustrates a toolbar or panel from which various functions can be available. Functions may be available, for example, for accessing workflow building block components, drilling down into particular components, saving a template, loading a template, etc.);
at design time, mapping by the entity-based application the task type to a task action using the task configuration building block (Beringer – see par 40 - A task is some work or action (which could be an Action as described below), or something to do or accomplish. Tasks may be the subject of requests. An activity block is a collection of actions, information, and related resources that one user needs to accomplish the requested task; Each activity block may provide guidance for individual performers in terms of what actions to perform, and the checking of preconditions, required resources, and business rules. Each activity can be enriched to offer related information and actions… a request within one activity can trigger sub-activities or entire new work situations (scenarios); see par 41 - An Action is a reusable atomic building block for meaningful business acts. An action provides a high-level enterprise service that encapsulates services and a user interface (UI). In one embodiment, actions provide a plug-and-execute interface to the activity context. Actions as reusable building blocks can be used to construct complex activities of a distributed workflow. Actions are connected to the enterprise backend (ESA), and may contain embedded navigation (e.g., object links, multiple screens such as guided activities). Examples of actions might be: Post Message, Create PO, Approve Vendor, View Supplier Details… Create invoice; Submit Application, etc; see par 44 - In one embodiment, the design-time engine includes or embodies an Activity Composer, which can be used to compose all actions required to accomplish an activity. Activities and actions can be enriched with contextual information; see par 45 - In one embodiment, the design-time engine includes or embodies an Activity Broker that determine whether a particular action can be displayed/accessed via a particular device, and if so, in what mode. The Activity Broker can enable support for multi-channel and OCA runtimes. The information about modes and channels can be provided directly in the activity through metadata or activity parameters.);
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.
Herter discloses:
at design time, defining by the entity-based application a dynamic workflow progress panel (Examiner further notes that dependent claim 4 states that the “second layout panel comprises the dynamic workflow progress panel”, thus details in FIG. 3 of Herter also are applicable here
Herter - See par 11 - Process guidance can be provided in an integrated manner while a current (e.g. in-progress or otherwise not yet completed) live instance of the business process is being executed. An overview of the business process can be provided that informs a user what the next process steps or other business process features (e.g. tasks, activities, etc.) are from the current process step. see par 24 – implementations… provide a process-centric view that gives an overview of a business process, which can include a sequential view of the process steps or sub-processes involved in completion of the business process as well as progress in completing those process steps and/or sub-processes for a specific instance of the business process. par 34, FIG. 3 - While an instance of the business process is in progress, or alternatively after the instance is completed, each first user interface element 306 can provide information that can include one or more of status information to show which process steps have already been already performed).
Beringer and Herter disclose:
at design time, defining by the entity-based application layout panels including a first layout panel for starting a workflow (Applicant’s [0033], [0036] give FIGS. 16, 19 as examples of “Start Workflow” where information can be entered
Beringer discloses the limitations based on broadest reasonable interpretation in light of the specification – See par 22 - 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. See FIG. 3, par 61 - As discussed above, process map designer 312 provides views of the component parts of a workflow from any of a variety of management perspectives, as described in more detail below. Process map designer 312 will generally exist within a memory in which client 310 is being executed. UI 314 represents any type of graphical user interface that can present the workflow layout and development environment. see par 62 - Resource 320 represents any of a number of workflow building block components that can be accessed and provided to a layout in process map designer 312. Resource 320 can be loaded into memory 302 where it is accessible to client 310. Resource 320 may be an action, which includes any of a number of atomic business acts, such as those provided above; See par 77 - FIGS. 5A-5B are block diagrams of an embodiment of a business process development environment for developing a workflow from one of multiple management perspectives. System 500 may have design-time components that define components and workflows.) and a second layout panel for summarizing the workflow once started (Beringer – See par 85 - Managing a business process may refer to configuring a business process (e.g., creating a business process) or viewing, editing, monitoring, or otherwise accessing a business process layout. See par 94, FIG. 8 - Layout tools 860 represent functions that can facilitate the development of the workflow being generated in development layout 810. In one embodiment, layout tools 860 includes different tabs to switch to different tool sets, for example, performers 862 and block 864; 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. 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; … the status layout allows a view of various parts of a workflow, and their relationships.)
See also Herter – see par 24- implementations of the current subject matter can, among other possible advantages, provide a process-centric view that gives an overview of a business process, which can include a sequential view of the process steps or sub-processes involved in completion of the business process as well as progress in completing those process steps and/or sub-processes for a specific instance of the business process).
at runtime of the entity-based application, creating or modifying by the entity-based application a workflow template responsive to user input received by the entity-based application via user interaction with the first layout panel (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 68 - . The Roles can be any type of business role, such as manager, purchaser, lead engineer, system architect, etc. With the process flow of system 400 represented in terms of "Role" actors, the resulting process flow can be generic and useful for any of a number of business scenarios, where Roles and actions are variable in a template, and specific when instantiated. 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. Functions may be available, for example, for accessing workflow building block components, drilling down into particular components, saving a template, loading a template, etc. 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);
at runtime of the entity-based application, instantiating by the entity-based application an instance of the workflow template responsive to user interaction with the first layout panel (Beringer – see par 24 - The individual activities can be instantiated and related with RTP relationships to result in a workflow that can be generated and managed by the enterprise system. Interactions between users can be captured within the system as part of the workflow, and represented in the workflow management environment. see par 57 - runtime components include instantiated versions of the templates and building blocks in a workflow for execution; see par 77 - System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow. Functions may be available, for example, for accessing workflow building block components, drilling down into particular components, saving a template, loading a template, etc. ); and
at runtime of the instance, displaying the second layout panel in a user interface (UI), the second layout panel providing a view of steps and tasks included in the instance and including a UI element linked to an add-task … of the UI (Beringer –see par 57 - runtime components include instantiated versions of the templates and building blocks in a workflow for execution; see par 77 - FIGS. 5A-5B are block diagrams of an embodiment of a business process development environment for developing a workflow from one of multiple management perspectives. . System 500 illustrates a workflow management environment, which may be embodied in a client or application that can provide a representation of a workflow to a user. System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow. . Tool panel 510 illustrates a toolbar or panel from which various functions can be available. See par 80 - 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).
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. Herter discloses ‘modifications to a process template to reflect customer-specific features of a customized business process can be performed via "drag and drop" or some other user-interface interactive functionality via which user interface elements or screens can be linked to icons or other user interface elements in a business process guidance pane to enable rapid navigation throughout a specific instance of a business process” (See par 25). However, it is unclear if either discloses an add-task “window” as claimed.
Crew discloses having an add-task “window” (Crew discloses entire limitation - See FIG. 4C, “add activity 315” and FIG. 5 – “Add/ Edit Activity” as separate window).
PNG
media_image2.png
392
488
media_image2.png
Greyscale
PNG
media_image3.png
676
492
media_image3.png
Greyscale
Beringer, Herter, and Crew disclose:
at runtime of the instance, receiving via the second layout panel user input navigating to the add-task window (Beringer - 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
Herter – see par 25 - modifications to a process template to reflect customer-specific features of a customized business process can be performed via "drag and drop" or some other user-interface interactive functionality via which user interface elements or screens can be linked to icons or other user interface elements in a business process guidance pane to enable rapid navigation throughout a specific instance of a business process.
See for “window” and rest of limitation - 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”) ;
at runtime of the instance, receiving user input via the add-task window 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");
at runtime of the instance, dynamically adding the additional step and the additional task to the instance responsive to the user input received via the add-task window, wherein the add-task window enables, while the instance is ongoing, user input to configure a task type using a corresponding task type building block and a task configuration of the additional task using a corresponding task configuration building block (Applicant’s specification [0085] as published states “The workflow summary view 2500 allows a user permitted to access the workflow 2510 to change a fairly linear process of the workflow 2510, virtually at any point beyond the current step. The user interaction with the workflow summary view 2500, and any changes made to the workflow 2510, is used to update a workflow definition associated with the workflow 2510”
Beringer – see par 62 - Resource 320 represents any of a number of workflow building block components that can be accessed and provided to a layout in process map designer 312. Resource 320 may be an action, which includes any of a number of atomic business acts, such as those provided above. Resource 320 may also be any type of workflow resource, such as a document, a file, an enterprise service, a business object, etc. see par 96, FIG. 8 - layout tools 860 also includes tools to create new performer 872, or create new block 874 (See lower left in FIG. 8), which can enable a developer or user to define new components to include within the workflow. see par 98 - Perform block 920 represents any type of perform block that may be assigned to a performer in a workflow layout. Perform block 920 is represented with define task 922 disclosing task type building block), describe performer 924, and measure performance 926; see par 102 - declare 960 provides an output to the system and/or to a user to represent the results of the work performed in actions 950. (disclosing task configuration building block); 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. (disclosing “task configuration building block”)
See also Herter – see par 8-9 - The method can optionally further include receiving, via a second user interface, a change to the definition of the business process. The change can optionally include one or more of rearrangement of an order of two or more of the plurality of process steps, addition of a new process step. see par 25 - modifications to a process template to reflect customer-specific features of a customized business process can be performed via "drag and drop" or some other user-interface interactive functionality via which user interface elements or screens can be linked to icons or other user interface elements in a business process guidance pane to enable rapid navigation throughout a specific instance of a business process. As used herein, the term "instance of a business process" and similar descriptive terminology is intended to refer to a specific execution of the business process; see par 27 - For each instance or set of instances of a given business process, the business object can be modified via user interface interactions to enable customizations that reflect one or more customer-specific business process aspects. see par 34 - While an instance of the business process is in progress, or alternatively after the instance is completed, each first user interface element 306 can provide information that can include one or more of status information to show which process steps have already been already performed, links to concrete instances of business objects containing data relevant to a specific process step or sub-process, (e.g. order number, customer identifiers or locations, etc.), name or identity of one or more responsible users, …, due date, or the like. Individual first user interface elements 306 can be expandable upon being selected to show additional information;
See also Crew – See FIG. 5, par 111-113 – 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; add/edit activity includes “Activity Category”; process type, document path; see par 84 - Steps 801-806 described above effectively build a selected workflow process display 302 within the GUI 301 into a form that may then be user manipulated to create a new or modified workflow process. From the Workflow Builder screen 301, the following actions can then be performed, as further depicted in FIG. 8; see par 91 - Step 813 (shown in FIG. 8 as “Activity Configuration”) may be used to select the "New" option from the initial activity selector 316. This initiates a request to the server 103. The web application 105 records that the "New" option was selected from the initial activity selector 316 and then builds the activity configuration screen as shown in FIG. 5);
at runtime of the instance, responsive to user interaction with the task configuration building block, creating or specifying a layout for the task type (Beringer – See par 41 - Actions as reusable building blocks can be used to construct complex activities of a distributed workflow. Actions are connected to the enterprise backend (ESA), and may contain embedded navigation (e.g., object links, multiple screens such as guided activities). Examples of actions might be: Post Message, …, Request Missing Document, Choose Between Candidates, Evaluate Candidate, …, Create Invoice, etc., or anything that can be perceived as an atomic work action from a business perspective or atomic enterprise business work activity. 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 77 - System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow. The workflow management environment is stored persistently in a database or other non-volatile storage device, and loaded to memory for execution. Both runtime and design-time components can be defined in storage and loaded to memory. FIG. 5A represents one management perspective of the workflow, illustrating a task layout in "list" view. FIG. 5B represents a management perspective of the same workflow, illustrating the task layout in "role" view. Tool panel 510 illustrates a toolbar or panel from which various functions can be available. Functions may be available, for example, for accessing workflow building block components, drilling down into particular components, saving a template, loading a template, etc.
See also Herter – see par 24 - A combined process visualization, guidance, and navigation tool consistent with one or more implementations of the current subject matter can provide visualization of customer-specific business processes that are based on packaged, predefined process templates delivered by the ERP vendor and/or defined by on-site consultants or other key users. and presented in the business language of the customer. A predefined business processes can be changed, extended, created, or the like to create customer-specific combinations; see par 27 - For each instance or set of instances of a given business process, the business object can be modified via user interface interactions to enable customizations that reflect one or more customer-specific business process aspects. The underlying business object can provide the basis for user interface elements that act as a visual guide or map through a general template or scheme illustrating process steps and/or sub-processes within a business process and how the various process steps and/or sub-processes are sequentially related. These user interface elements can reflect details regarding completed and to-be-completed sub-processes and steps. A user interface element representing a specific process, sub-process, task, or other aspect of a business process can be expandable to show additional granularity of underlying sub-processes or steps).
Beringer, Herter, and Crew are analogous art as they are directed to workflows or business processes (see Beringer Abstract, Herter Abstract, Crew Abstract). 1) Beringer discloses measuring performance (926) and defining workflow (984 ; FIG. 9, par 97-98). Herter improves upon Bering by disclosing having a workflow progress set up at design time of the workflow/process that allows a template to show how steps are sequentially related and reflect details of completion (see Herter par 11, 27, 34, FIG. 3) and also disclose that implementations can include a view that gives “an overview of a business process, which can include a sequential view of process steps” (See par 24). One of ordinary skill in the art would be motivated to further include a template in design time that will then show sequential relations and status of completion and allow modifications to efficiently improve upon the measure of performance of workflow/tasks in Beringer (See par 97-98). 2) Bering discloses in FIGS. 5A-5B having additions made to a workflow using tool panel 510. Herter discloses modifying a process template using user interface elements or screens and a business process guidance pane (See par 25-26). Crew improves upon Bering and Herter 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 modifying processes with a customized business process in a graphical user interface in Herter.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify template for a workflow at design-time, and allowing additional actions included after design-time in Beringer, to further include defining statuses of a sequential process and showing status of completion in a process that can be displayed during a business process as disclosed in Herter, 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 Herter 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 Herter for the same reasons as claim 1.
Concerning independent claim 15, Beringer and Herter 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 Herter for the same reasons as claim 1.
Concerning claim 2, 9, and 16, Beringer and Herter disclose:
The method according to claim 1, further comprising:
responsive to the dynamically adding, updating a workflow definition file for the instance and storing the workflow definition file thus updated in a database (Beringer – see par 56 - Record 252 represents any type of system storage of a task. The storage may be in the form of data in a field of a database; see par 77 - Note that as mentioned above, 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. The workflow management environment is stored persistently in a database or other non-volatile storage device, and loaded to memory for execution. Both runtime and design-time components can be defined in storage and loaded to memory.).
See also Herter – see par 7 – method includes access a definition of a business process that includes a designation of a plurality of process steps required for completion of the business process; See par 8 - The definition can optionally include a business object stored in a database; See par 9 - The method can optionally further include receiving, via a second user interface, a change to the definition of the business process. The change can optionally include one or more of rearrangement of an order of two or more of the plurality of process steps, addition of a new process step, deletion of one of the plurality of process steps, and re-definition of an aspect of one of the plurality of process steps. The received change can optionally be saved to the definition).
It would be obvious to combine Beringer and Herter for the same reasons as claim 1.
Concerning claim 3, 10, and 17, Beringer and Herter disclose:
The method according to claim 1, wherein the creating or modifying a workflow template is performed responsive to user interaction with the first layout panel, the method further comprising:
saving an instance of the workflow template thus created or modified as a new workflow template (Beringer – See par 27 - Collaborative definitions allow a performer to model activities based on how work is actually accomplished. Such an ad hoc definition can become a template; 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 85 - The management environment may receive a request to generate a workflow, 702. Such a workflow may be created from scratch (e.g., a new template), or may be created from a template (e.g., specific components and relationships can be generated within a model for a workflow;
See also Herter par 41, 42 - Each individual tenant 510A-510C can customize that standard template according to the individual business process features specific to business of the organization to which that tenant is assigned. Customizations can be stored as extensions in the metadata repository.).
It would be obvious to combine Beringer and Herter for the same reasons as claim 1.
Concerning claim 4, 11, and 18, Beringer and Herter disclose:
The method according to claim 1, wherein the second layout panel comprises the dynamic workflow progress panel and wherein the dynamic workflow progress panel shows the instance as the instance progresses from step to step (Herter - See par 11, 27 - Process guidance can be provided in an integrated manner while a current (e.g. in-progress or otherwise not yet completed) live instance of the business process is being executed. An overview of the business process can be provided that informs a user what the next process steps or other business process features (e.g. tasks, activities, etc.) are from the current process step. par 34, FIG. 3 - While an instance of the business process is in progress, or alternatively after the instance is completed, each first user interface element 306 can provide information that can include one or more of status information to show which process steps have already been already performed).
It would be obvious to combine Beringer and Herter for the same reasons as claim 1.
Concerning claim 5, 12, and 19, Beringer and Herter disclose:
The method according to claim 1, wherein both the first layout panel and the second layout panel comprise a step menu, wherein the step menu of the first layout panel is for adding a first set of steps to the workflow or workflow template at design time (Beringer – See par 77, FIG. 5 - System 500 may have design-time components that define components and workflows. See par 97, FIG. 9 - FIG. 9 is a block diagram of an embodiment of an activity modeler; The workflow management environment can include functionality to define perform blocks of a workflow. Performances tab 904 may be selected to define the various perform blocks, such as those seen in FIG. 8; See par 99 - actions 950 that define what work is required to complete the task, and declare 960 that define the output of the task; see par 104, FIG. 9 - 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) and wherein the step menu of the second layout panel is for dynamically adding one or more additional steps to the instance at runtime of the instance (Beringer – See par 77 - System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow; See par 85 - Relationships between parts of a workflow can be explicitly defined, defined in the abstract, or not defined at design-time, but left to be defined at run-time; see par 96, FIG. 8 - layout tools 860 also includes tools to create new performer 872, or create new block 874 (See lower left in FIG. 8), which can enable a developer or user to define new components to include within the workflow; see also Herter – see par 8-9 - The method can optionally further include receiving, via a second user interface, a change to the definition of the business process. The change can optionally include one or more of rearrangement of an order of two or more of the plurality of process steps, addition of a new process step. see par 27 - For each instance or set of instances of a given business process, the business object can be modified via user interface interactions to enable customizations that reflect one or more customer-specific business process aspects).
Examiner notes claim 19 recites both limitations from claims 5-6 above. Claim 19 is rejected for the same reasons as claims 5-6 above.
It would be obvious to combine Beringer and Herter for the same reasons as claim 1.
Concerning claim 6, 13, and 19, Beringer and Herter disclose:
The method according to claim 1, wherein both the first layout panel and the second layout panel comprise a task menu, wherein the task menu of the first layout panel is for adding a task to a step of a workflow or workflow template at design time (Herter – see par 28 - a design time modification engine can be implemented to enable business process configuration and customization via drag and drop or other user interface features that permit rearrangement, addition, deletion, etc. of feature of a business process (sub-processes, related business processes, steps, tasks, etc.).) and wherein the task menu of the second layout panel is for dynamically adding the additional task to the additional step of the instance at runtime of the instance (Beringer – see par 35 - By modeling business processes as a collection of loosely coupled individual contributions of individuals, the control structure of the distributed workflow more closely resembles the actual work practice of enterprise users. The same technology can also be used to model simple activities consisting of a single task or complex activities consisting of tasks including sub-activities. See par 40 - An activity block is a collection of actions, information, and related resources that one user needs to accomplish the requested task. Each activity block may provide guidance for individual performers in terms of what actions to perform, and the checking of preconditions, required resources, and business rules. Each activity can be enriched to offer related information and actions. The system can also model activities recursively, so that a request within one activity can trigger sub-activities or entire new work situations (scenarios); see par 77 - System 500 may also have runtime components that allow ad hoc collaboration and runtime additions to a workflow.
See also Herter – par 8 - At least one of the plurality of process steps can optionally include a sub-process comprising additional process steps, and a second selection of the one of the first plurality of user interface elements corresponding to the sub-process can optionally result in expansion of the one of the first plurality of user interface elements to display an additional first user interface element corresponding to each of the additional process steps. See par 27 - run time user interface elements can be supported by an underlying business object defined at design time to comply with a generic business process template… business object can be modified via user interface interactions to enable customizations that reflect one or more customer-specific business process aspects).
Examiner notes claim 19 recites both limitations from claims 5-6 above. Claim 19 is rejected for the same reasons as claims 5-6 above.
It would be obvious to combine Beringer and Herter 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.
Applicant’s arguments with regards to 103 are moot in view of the new rejections necessitated by the amendments. Applicant argues that limitations of claim 7 are now in claim 1, and cites only to paragraphs 41, 57, 68, and 106 of Beringer and that Beringer does not have a “layout for a task type” as in the last limitation of new claim 1. Remarks, pages 16-17. In response, Examiner respectfully disagrees. Bering paragraph 41 has constructing “complex activities of a distributed workflow.” That alone, discloses a “layout” for a task. New rejection above cites paragraph 57 having associations or relationships that relate actions/activities to a context. This also discloses a “layout” for a task. Paragraph 77 has runtime additions to a “workflow”. The current claim gives no specifics as to what is required in the layout – one just needs to be defined. This occurs in Beringer. Paragraph 77 also has details on a task layout in a role view; where runtime components can be defined. Applicant then argues that paragraphs 24 and 28 of Herter do not disclose the new limitations. Remarks, pages 17-18. In response, Examiner respectfully disagrees. Herter paragraph 24 states that there is a visualization of a customer-specific business process that can be defined by consultants or users and changed/extended. This alone discloses the limitations. Herter paragraph 27 disclose that having customizations for customer-specific business process aspects where steps and/or subprocesses are sequentially related.
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