DETAILED ACTION
This office action is responsive to the applicant’s respond filed 1/16/2026. The application contains claims 1-3, 5-10, 12-16, 18-22, all examined and rejected.
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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application IN201741019037 filed in India on 5/30/2017.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original non-provisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. IN201741019037, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Claims 1-3, 5-10, 12-16, 18-20 concerning “first user interface having a tasks menu for setting up the task being added to the activity flow including naming the task setting a due date for the task and assigning the task to a role under management by the managerial-level user”, “responsive to the instruction from the managerial-level user to add the task to the activity flow, prompting the managerial-level user to provide task details and any follow-up task for the task being added to the activity flow, the prompting performed by the activity flow editor through the tasks menu displayed on the first user interface, wherein the tasks menu comprises an input field for the role and a submenu for adding or selecting a follow-up task”, “receiving, by the activity flow editor via the first user interface, the task details, the follow up task, and a trigger setting for triggering the activity flow, the trigger setting comprising a condition or a rule” which are not disclosed in the prior-filed application as Figs. 5A-6 are not part of prior-filed application, Application No. IN201741019037.
Accordingly, claims 1-3, 5-10, 12-16, 18-22 are not entitled to the benefit of the prior-filed application.
Applicant is encouraged to provide a support for the limitations in the parent application to be entitled to the benefit of the prior application.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1-3, 5-10, 12-16, 18-22 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Independent claims 1, 8, and 15 require “activity flow definition file lacks a complete copy of the executable logic defined by the case model of the stored singular building block“. Examiner was not able to find support the limitation. On the contrary paragraphs 70 and 71 disclose that activity flow uses “execution logic, case models” and “an activity flow itself can be a composition of entities”; paragraphs 75 show “the definition for the activity flow (as a building block for the “Invoice” entity) “ include case model structure inside ActivityflowBuildingBlock “<ActivityflowBuildingBlock type="" typeVersion="..."> … <Activities> <Events> <Followups> <CaseModel></HandlingModels></EntitycaseModel> …“. This show that the activity flow building block definition is not a thin reference file, but it contains the structural places for activity model, handling model. Activities, events, followups, and case model. Paragraph 76 provide more clarification by disclosing “the case model holds the definition of activities in the activity flow and can be compiled to, for instance, SCXML”. This shows that the case model holds the definition of activities. Since the case model is part of activity flow definition structure as clarified in paragraph 75, the text show the executable activity logic is contained in the activity flow definition (building block) and not omitted from it. Also, paragraph 76 disclose “Below is a non-limiting example of an executable activity flow Definition” showing a <CaseModel> with state onentry, releaseactivity, and transitions. This show that the activity flow definition include executable logic or at least include the case model logic that can be executed. Paragraph 77 disclose “The activity flow definition can hold a reference to the entity.”, this is reference to the entity not a separate executable logic. This support association with the entity, but not “definition file lacks executable logic”. Dependent claims inherit the independent claims deficiency.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1-3, 5-10, 12-16, 18-22 are rejected under 35 U.S.C. 103 as being unpatentable over https://www.youtube.com/watch?v=OLL7vB7OonA published on March 26, 2014 [hereinafter SharePoint] in view of Hatoun [US-20060069605-A1, hereinafter SharePoint1] in view of Higgins et al. [US20070067373, hereinafter Higgins].
Regarding claim 1,
SharePoint teach method for editing and using an activity flow, the method comprising:
receiving, by an activity flow editor executing on a processor via a first user interface, an instruction from a managerial level user, to add a task to the activity flows (Time 0:47, Time 33:08, SharePoint is entity based process application that process the entity “Employee Suggestions”, examiner notes that managerial-level user is a title that could be associated with any user that add tasks, Time 25:47 show different stages of workflow (i.e. “HR Approval”, “Custom Approval”, “Email Approval”, “Not Approved”) associated with “Jennifer-Live Demo” workflow, examiner further notes that under broadest reasonable interpretation, the workflow “Jennifer-Live Demo” represent Activity flow, while the stages (i.e. “HR Approval”, “Custom Approval”, “Email Approval”, “Not Approved” ) represent internal execution steps within the activity flow See at least Time 15:30, Time 16:35, Time 17:03-17:10, “start a task process” user add tasks into workflow, 17:16),
the first user interface having a tasks menu for setting up the task being added to the activity flow (Time 17:03-17:10, “start a task process”, 17:03 “here and I want to start a task process so I'm going to click”) including naming the task (Time 17:17, start task window show option to input Task title, Time 17:33, Time 20:38), setting a due date for the task (Time 17:17, start task window show option to input Task due date, “18:01 okay I can give it a due date”, Time 20:38), and assigning the task to a role under management by the managerial-level user (Time 17:17, start task window show option to input participants, Time 17:06, action drop down menu show “Assign a task” under “Task Actions”, Time 17:27, “17:17 here's where I could go in um and pick different people I have a group actually“, Time 20:38);
responsive to the instruction from the managerial-level user to add the task to the activity flow, prompting the managerial-level user to provide task details and any follow-up task for the task being added to the activity flow, the prompting performed by the activity flow editor through the tasks menu displayed on the first user interface, wherein the tasks menu comprises an input field for the role and a submenu for adding or selecting a follow-up task (system provide the user with clickable links to fill the task details as shown at Time 17:10 where the user selects “start a task process” and as the user interact with it the system show more options that allow the user to enter more details See Time 17:17-17:20 and follow up tasks See Time 19:14-19:42, Time 21:00-21:16, “Go to”, the system presents outcome based options and conditional logic, which is a selection of follow up tasks based on task outcome, examiner notes that managerial-level is a title that could be associated with any user that add tasks);
receiving, by the activity flow editor via the first user interface, the task details, the follow up task, and a trigger setting for triggering the activity flow, the trigger setting comprising a condition or a rule (Time 17:10-21:16, user add task details as name, due date, participants, etc. and IF-else rules to trigger different tasks or activity flows, Time 18:16, “wait for task completion” “completion criteria”); and
storing, by the activity flow editor, the activity flow with the added task, the task details, the trigger setting for triggering the activity flow, and the follow-up task together as a singular building block in a data store, the data store storing a plurality of building blocks, wherein the data store is accessible by an entity-based process application (Time11:30, Icons “Reusable Workflow”, “Save as Template”, workflow could be saved and reused as a stored unit, Time 16:30, workflow “Jennifer Live Demo” is generated with multiple stages and logic, the workflow include multiple tasks and stages (e.g. HR Approval, Custom Approval, Email Approval) that are stored within workflow “Jennifer Live Demo” as a single reusable unit with a task, task details, trigger setting, and follow-up task, Time 26:38, user is able to associate different conditions to start a workflow as “when an item is created” or “when item is changed”).
SharePoint show the ability to create and save workflow as template by selecting “save as Template” icon. However, as SharePoint do not explicitly disclose the singular building block comprising a case model defining executable logic for the activity flow, wherein the singular building block is configured as a reusable component for a plurality of different lifecycle models and is stored independently of any lifecycle model, and wherein the data store is accessible by an entity-based process application; wherein, responsive to an instruction instructions from a process administrator, the entity-based process application inserts the activity flow into a first particular pre-defined stage of a first lifecycle model and a second particular pre-defined stage of a second lifecycle model, wherein the activity flow is created independent of any lifecycle model, wherein the activity flow is inserted into the first lifecycle model and the second lifecycle model by adding, to an activity flow definition file, a first reference to the first lifecycle model and a second reference to the second lifecycle model, wherein the activity flow definition file is associated with the singular building block stored in the data store, and wherein the activity flow definition file lacks a complete copy of the executable logic defined by the case model of the stored singular building block; wherein the entity-based process application comprises a second user interface for customizing the activity flow, the second user interface including a user interface element for disabling an activity of the activity flow; and wherein, the trigger setting for triggering the activity flow is evaluated through the first reference and the second reference added to [[an]] the activity flow definition file and, responsive to the condition or rule being met, the activity flow is triggered [[and]] to automatically execute from the stored singular building block automatically executed without running the activity thus disabled.
SharePoint1 teach a method for editing and using an activity flow, the method comprising:
receiving, by an activity flow editor executing on a processor via a first user interface, an instruction from a managerial-level user, to add a task to the activity flow (Fig. 4B, ¶19, “graphical user interface for designing a workflow”, ¶42, “methods and apparatus for developing and using workflows, may be supported within a collaborative computer application such as Microsoft® SharePoint™ Portal Server (SharePoint)”, ¶87, “FIG. 7D is an exemplary GUI form 414 for setting the tasks in a workflow. The GUI form provides five views 416 of the tasks in a workflow: all of the tasks in a workflow; the tasks in a workflow assigned to a logged on user; tasks in a workflow that are due on the current day; active tasks in a workflow; and tasks in a workflow by assignment”),
the first user interface having a tasks menu for setting up the task being added to the activity flow including naming the task (Fig. 4B, Fig. 7D, ¶74, “field 241 in the GUI form is provided to enter the name of the step in the workflow”, ¶87, “FIG. 7D is an exemplary GUI form 414 for setting the tasks in a workflow. The GUI form provides five views 416 of the tasks in a workflow: all of the tasks in a workflow; the tasks in a workflow assigned to a logged on user; tasks in a workflow that are due on the current day; active tasks in a workflow; and tasks in a workflow by assignment”),
setting a due date for the task, and assigning the task to a role under management by the managerial-level user (Fig. 1, Fig. 7D, ¶12, “Tasks may be assigned to one or more users, delegated to one or more users, and/or forwarded to one or more users”, “12, “Developing a workflow, packaging a workflow, installing a workflow, deploying a workflow, enabling a workflow, associating a workflow with a schedule, instantiating a workflow, and terminating a workflow are controlled through graphical user interfaces that display computer-implemented forms” ¶48, “Workflow parameterization is the process of collecting and submitting to the workflow a set of parameters, such as participants, due date, routing order, and so on. Some parameterization happens when the workflow is associated with a list or a profile. Some parameterization happens when the workflow is initiated. The workflow designer, i.e., the workflow developer or workflow owner, decides what parameters to include and when to ask for their values”);
responsive to the instruction from the managerial-level user to add the task to the activity flow, prompting the managerial-level user to provide task details and any follow-up task for the task being added to the activity flow, the prompting performed by the activity flow editor through the tasks menu displayed on the first user interface, wherein the tasks menu comprises an input field for the role and a submenu for adding or selecting a follow-up task (Fig. 4B, “Add Conditional Branch”, Fig. 7D-7E, ¶88, “FIG. 7E an exemplary GUI form 422 for changing the parameter values of a workflow associated with a document library. The GUI form 422 is divided into four sections: “Participants and Routing Order”; “Due Date”; “Notification Options”; and “Approval Conditions.””);
receiving, by the activity flow editor via the first user interface, the task details, the follow-up task (Fig. 4B, “Set condition”, “Action”, ¶77, “left side of the block of conditions and actions 247, “Set Conditions” and “Actions” are selected from drop down menus. On the right side of the block of conditions and actions 247, the condition “when Amount is less than or equal to $1000” is selected from a drop down menu as is the condition “else when Amount is greater than $1000.””), and
a trigger setting for triggering the activity flow, the trigger setting comprising a condition or a rule (Fig. 4C, “Initiation Conditions”, ¶85, “In the “Initiation Conditions” section, the owner sets the conditions that will cause the workflow to start if all of the necessary workflow parameter values are set. At least one, and possibly more than one, initiation condition may be selected from the following conditions: “Allow this workflow to be manually started from an item or folder”; “Automatically start this workflow when a new item or folder is created.”; and “Automatically start this workflow whenever an item or folder is changed.””); and
storing, by the activity flow editor, the activity flow with the task, the task details, the trigger setting for triggering the activity flow, and any the follow-up task together as a singular building block in a data store (¶¶9-10, “A developed workflow is packaged for installation preferably by assigning values to parameters, inserting new parameters, and/or disabling existing parameters, and storing the workflow and related data in a persistent store”),
the data store storing a plurality of building blocks, wherein comprising a case model defining executable logic for the activity flow (claim 5, “wherein packaging the workflow includes: (a) inserting a workflow schedule into a package; (b) inserting task types into the package; (c) inserting forms into the package; (d) inserting resources into the package; and (e) adding metadata to the package manifest”, ¶48, “ A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow”),
wherein the singular building block is configured as a reusable component for a plurality of different lifecycle models (¶8, “The present invention is directed to reusing workflows by providing a method and apparatus for associating the structure and metadata of a workflow developed for one project with other projects”, ¶9,” The use of workflow templates allows the method and apparatus to associate the structure and metadata of a workflow developed for one project with other projects”) and is stored independently of any lifecycle model, and wherein the data store is accessible by an entity-based process application (¶81, Fig. 5A, Fig. 3, ¶¶67-68, “developer packages the workflow definition and installs the workflow definition on a server to enable the workflow owner to access the workflow definition”, “owner enables, i.e., activates, the deployed workflow definition, associates the deployed workflow definition with the set of documents for the project, and instantiates the deployed workflow definition, i.e., creates the workflow for the project”, workflow definition is created, packaged, and installed on a server before it is associated with any particular project. This support that the reusable activity flow/workflow template is stored independently of any lifecycle model. Fig. 7A-7E, ¶¶83-84, “workflow owner then adds metadata about the workflow into the package manifest 280. A package manifest is a detailed description of the contents of an package. The package manifest contains metadata describing the name, version, types, and resources in the package and the dependencies upon other packages”, ¶85);
wherein, responsive to model (¶68, “The owner enables, i.e., activates, the deployed workflow definition, associates the deployed workflow definition with the set of documents for the project, and instantiates the deployed workflow definition”, ¶50, “A workflow can be associated with a list (where a document library is a type of list) or a content type”, ¶85, “In the “Initiation Conditions” section, the owner sets the conditions that will cause the workflow to start”, user associate reusable workflow with a project and select initiation conditions. Those initiation conditions define where in the project lifecycle the workflow runs (i.e. pre-defined stage of lifecycle model),
wherein the activity flow is created independent of any lifecycle model, wherein the activity flow is inserted into the first lifecycle model and the second lifecycle model by adding, to an activity flow definition file, a first reference to the first lifecycle model and a second reference to the second lifecycle model (¶48, “A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow“,¶50, “ Workflow association settings are stored as properties of a list. These settings are preserved if the list is copied. These settings are preserved if the library is copied “, ¶91, “workflow association is a type of setting that can be added to content types. For example, one might add a Specification Approval workflow association to the Specification content type, and that workflow association will get copied to lists …”),
wherein the activity flow definition file is associated with the singular building block stored in the data store (¶48, “A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow“, ¶50, “ Workflow association settings are stored as properties of a list”), and wherein the activity flow definition file [is] a complete copy of the executable logic defined by the case model of the stored singular building block (¶48, “A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow“, ¶50, “ Workflow association settings are stored as properties of a list”);
wherein the entity-based process application comprises a second user interface for customizing the activity flow, the second user interface including a user interface element for disabling an activity of the activity flow (¶9, “use of workflow templates allows the method and apparatus to associate the structure and metadata of a workflow developed for one project with other projects. A workflow is associated with a schedule by assigning values to parameters, inserting new parameters, disabling existing parameters, enabling existing features, disabling existing features, and/or inserting computer-implemented forms. Associating a workflow with a schedule is controlled through graphical user interfaces that display computer-implemented forms”, ¶10, workflow components (parameters/features) represent the activities of activity flow within the lifecycle model); and
wherein the trigger setting for triggering the activity flow, is evaluated through the first reference and the second reference added to the activity flow definition file and, responsive to the condition or rule being met, the activity flow is triggered to automatically execute from the stored singular building block (¶85, “ the owner sets the conditions that will cause the workflow to start if all of the necessary workflow parameter values are set. At least one, and possibly more than one, initiation condition may be selected from the following conditions: “Allow this workflow to be manually started from an item or folder”; “Automatically start this workflow when a new item or folder is created.”; and “Automatically start this workflow whenever an item or folder is changed.””) without running the activity thus disabled (¶¶9-10, “workflow is developed using a workflow template. The template preferably allows preprogrammed workflow components to be inserted and/or removed, values to be assigned to parameters in workflow components, new parameters to be inserted into workflow components, and parameters already existing in a workflow component to be disabled. A developed workflow is packaged for installation preferably by assigning values to parameters, inserting new parameters, and/or disabling existing parameters, and storing the workflow and related data in a persistent store. Preferably, a workflow may be installed, deployed, and/or enabled. A workflow may be instantiated and/or terminated”).
SharePoint and SharePoint1 are analogous art io the claimed invention because they are from a similar field of endeavor of developing and managing workflows for projects management. Thus, i would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify SharePoint to include the ability to edit workflows by disabling certain activities resulting in resolutions as disclosed by SharePoint1 with a reasonable expectation of success.
One of ordinary skill in the art would be motivated to modify SharePoint as described above to allow more customization to amortize the labor and cost required to develop one workflow over many workflows by reusing a workflow for more than one project (SharePoint1, ¶8).
SharePoint and SharePoint1 does not explicitly disclose activity flow definition file lacks a complete copy of the executable logic defined by the case model.
Higgins disclose activity flow definition file lacks a complete copy of the executable logic defined by the case model of the stored singular building block (¶122, “workflow engine (223) parses a definition of a workflow and loads corresponding modules of the workflow for execution”, “workflow can be defined in a method file (e.g., as an application and/or as a module), which specifies the data connections between the modules in the workflow and the execution paths among the modules”, ¶136, “data package (219) contains the input data and the definition of the workflow but typically not the detailed instructions to perform the tasks”, ¶525, “tasks implemented as plug and play modules (1208), which may be provided in shared libraries. Some of the modules referenced in the workflows of the eMethods may be methods (1209) as workflow of tasks and/or methods, which may be provided in XML files. The workflow engine (1207) interprets the workflows of the eMethods to load and execute the task modules”);
wherein the trigger setting for triggering the activity flow, is evaluated through the first reference and the second reference added to the activity flow definition file and, responsive to the condition or rule being met, the activity flow is triggered to automatically execute (¶122-123, “workflow can be defined in a method file (e.g., as an application and/or as a module), which specifies the data connections between the modules in the workflow and the execution paths among the modules. The workflow engine causes the modules that are specified in the method file to be executed”).
SharePoint-SharePoint1 and Higgins are analogous art io the claimed invention because they are from a similar field of endeavor of generating, applying and using workflows for projects management. Thus, i would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify SharePoint-SharePoint1 resulting in resolutions as disclosed by Higgins with a reasonable expectation of success.
One of ordinary skill in the art would be motivated to modify SharePoint-SharePoint1 as described above to save storage space by making the definition files smaller and easier to manage. It also facilitate updating and modifying the shared logic of workflows by allowing a single update in one place (shared logic) to be reflected in every workflow, making maintenance faster and more efficient. This is simply combining prior art elements according to known methods to yield predictable results, use of known technique to improve similar devices (methods, or products) in the same way, and applying a known technique to a known device (method, or product) ready for improvement to yield predictable results (MPEP 2143).
Regarding claim 2,
SharePoint-SharePoint1-Higgins teach the method of claim 1, wherein the tasks menu contains a list of predefined tasks (SharePoint, Time 18:39, drop down menu of tasks).
The same motivation to combine for claim 1 equally applies for current claim
Regarding claim 3,
SharePoint-SharePoint1-Higgins teach the method of claim 1, wherein the activity flow is represented as an entity for querying at runtime (SharePoint, Time 26:34, prevent manual start of workflow and start workflow automatic when an item is created or changed, Time 22:00, adding time to start the building block (7 days), system is able to automatically execute the activity flow that include actions and settings in a specific stage of life cycle of the entity “Employee Suggestions”, SharePoint1, Fig. 7B, ¶43-44).
The same motivation to combine for claim 1 equally applies for current claim
Regarding claim 5,
SharePoint-SharePoint1-Higgins teach the method of claim 1, wherein the user interface has a settings menu for selecting, from a plurality of triggers, a trigger for the activity flow (SharePoint, Time 16:55, if, else condition is a trigger , Time 22:09, add time, Time 26:56, “allow this workflow to be manually started”, start workflow when an item is created or changed, SharePoint1, Fig. 7B, start workflow when an item is created or changed, examiner notes that starting a workflow consisting of activity flows automatically trigger the activity flows of the workflow).
The same motivation to combine for claim 1 equally applies for current claim
Regarding claim 6,
SharePoint-SharePoint1-Higgins teach the method of claim 5, wherein the trigger is configured for automatically or manually initiating the activity flow at runtime (SharePoint, Time 16:55, if, else condition is a trigger , Time 22:09, add time, Time 26:56, “allow this workflow to be manually started”, SharePoint1, Fig. 7B, start workflow when an item is created or changed, examiner notes that starting a workflow consisting of activity flows automatically trigger the activity flows of the workflow).
The same motivation to combine for claim 5 equally applies for current claim
Regarding claim 7,
SharePoint-SharePoint1-Higgins teach the method of claim 5, wherein the trigger is linked to creation of an instance of the entity, to a condition, to a rule, or to another activity flow (SharePoint, Time 16:55, if, else condition is a trigger , Time 22:09, add time, Time 26:56, “when an item is created”, SharePoint1, Fig. 7B, start workflow when an item is created or changed, examiner notes that starting a workflow consisting of activity flows automatically trigger the activity flows of the workflow).
The same motivation to combine for claim 5 equally applies for current claim
Regarding claims 8 and 15,
Claims 8 and 15 are similar in scope to claim 1; therefore they are rejected under similar rationale. Also, SharePoint1 teach a processor and a non-transitory computer medium (¶9, ¶39, “invention provide a computer-implemented method and apparatus (tool), including computer-readable medium, for associating the structure and metadata of a workflow developed for one project with other projects and for developing and using workflows and workflow templates”).
Regarding claim 9,
Claim 9 is similar in scope to claim 2; therefore it is rejected under similar rationale.
Regarding claims 10 and 16,
Claims 10 and 16 are similar in scope to claim 3; therefore they are rejected under similar rationale.
Regarding claims 12 and 18,
Claims 12 and 18 are similar in scope to claim 5; therefore they are rejected under similar rationale.
Regarding claims 13 and 19,
Claims 13 and 19 are similar in scope to claim 6; therefore they are rejected under similar rationale.
Regarding claims 14 and 20,
Claims 14 and 20 are similar in scope to claim 7; therefore they are rejected under similar rationale.
Regarding claim 21,
SharePoint-SharePoint1-Higgins teach the method of claim 1, further comprising re-using the first lifecycle model in another application (SharePoint, Time11:30, Icons “Reusable Workflow”, “Save as Template”, SharePoint1, ¶85, “workflow template is used to create a workflow specifically for the project to be managed by the workflow. For example, the workflow named “Product Review” may be used as a template to define a new workflow named “Video Editing Product Review.””, “selecting one of the two aforementioned workflow templates, the owner associates a workflow with the document library that contains the documents associated with a project, e.g., “Video Editing Project.”, ¶13, “method and apparatus for reusing the structure and metadata of existing workflows by associating the structure and metadata of a workflow developed for one project with other projects”, Fig. 10A-10D, ¶¶68-69, “During the Association stage the owner associates the workflow with a document library and/or lists”, ¶50, “workflow can be associated with a list (where a document library is a type of list) or a content type. Workflow association settings are stored as properties of a list. These settings are preserved if the list is copied. These settings are preserved if the library is copied”).
The same motivation to combine for claim 1 equally applies for current claim
Regarding claim 22,
SharePoint-SharePoint1-Higgins teach the method of claim 1, further comprising generating the follow-up task based on one of a plurality of outcomes to the task (SharePoint, Time 17:10-21:16, user add task details as name, due date, participants, etc. and IF-else rules to trigger different tasks or activity flows, SharePoint1, Fig. 4B, “Set condition”, “Action”, ¶77, “left side of the block of conditions and actions 247, “Set Conditions” and “Actions” are selected from drop down menus. On the right side of the block of conditions and actions 247, the condition “when Amount is less than or equal to $1000” is selected from a drop down menu as is the condition “else when Amount is greater than $1000.””). The same motivation to combine for claim 1 equally applies for current claim.
Response to Arguments
Applicant argue that the Office Action wholly fails to point to any particular elements of either Sharepoint or Sharepoint1 as being equivalent to an "activity flow definition file," wherein the "activity flow definition file" is a separate element than "the activity flow with the task, the task details, the trigger setting for triggering the activity flow, and the follow-up task" that is stored "as a building block in a data store", as set forth in independent claim 1.
Examiner respectfully disagrees, although Sharepoint1 does not use the exact term “activity flow definition file”, but it disclose a workflow definition implemented as an installable package that stores the workflow structure, parameters, triggers, and task logic that correspond to the claimed building block See at least ¶48, “A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow“, ¶¶67-68, “developer packages the workflow definition and installs the workflow definition on a server to enable the workflow owner to access the workflow definition”, “owner enables, i.e., activates, the deployed workflow definition, associates the deployed workflow definition with the set of documents for the project, and instantiates the deployed workflow definition, i.e., creates the workflow for the project”, workflow definition is created, packaged, and installed on a server before it is associated with any particular project. This support that the reusable activity flow/workflow template is stored independently of any lifecycle model ¶¶83-84, ¶85. In addition, Higgins further supports this limitation by disclosing that a workflow can be defined in a method file that specify the structure and execution paths among modules See at least ¶122 and ¶136.
Applicant argue that the Office action does not provide any citations or characterizations of the statement "storing the workflow and related data in a persistent store" that equate the "related data" to the trigger setting or the activity definition file of independent claim 1, and thus it is unclear which element is being mapped to the "related data" of Sharepoint1.
Examiner respectfully disagrees, the argument improperly equates “related data” in Sharepoint1 with the claimed elements. In Sharepoint1, the workflow definition itself is packaged unit that define workflow structure, tasks, parameters, and triggers See at least ¶48, ¶¶67-68, ¶¶83-85, and this workflow is stored in persistent storage. The “related data” relates to additional information associated with the workflow execution and not the workflow definition. This is clarified as ¶¶67-68 shows that the stored workflow and “related data” enable the workflow to be paused (hibernated) and resumed. This indicates that the related data includes runtime or state information and not the workflow itself which is separately described in ¶48. Accordingly, the claimed activity flow definition or building block is properly mapped to the workflow definition package, not to the “related data”.
Applicant argue that the disclosure does not appear to allege that Sharepoint1 teaches or suggests that "the trigger setting" included in the "building block" of the instant application is "evaluated through the reference added to activity flow definition file" wherein "the reference added to activity flow definition file" is a separate element from "the trigger setting" included in the "building block," as set forth in independent claim 1, pre-amendment.
Examiner respectfully disagrees, the argument relies on a narrow interpretation that require the reference to be structurally separate element from the trigger stting, which is not required in claim language. SharePoint1 workflow definition is created and stored as a reusable package independent of any specific project See at least ¶48, ¶¶67-68. Workflow is later associated with a particular project or list or library See at least ¶50, ¶85. This association link the stored reusable workflow definition and the execution context, corresponding to the claimed reference. The trigger setting as event or item creation is defined and applied within the associated context and is distinct from the workflow definition itself. As further show the stored workflow and related data allow workflow to be paused and resumed. Accordingly, the association (reference) and the trigger setting are functionally distinct elements and the trigger is evaluated through the association between the stored workflow and the execution.
Applicant argue that he currently cited prior art further fails to disclose "wherein the activity flow definition file is associated with the singular building block stored in the data store, and wherein the activity flow definition file lacks a complete copy of the executable logic defined by the case model of the stored singular building block," as set forth in amended independent claim 1.
Examiner respectfully disagrees, SharePoint1 disclose wherein the activity flow definition file is associated with the singular building block stored in the data store See at least ¶48, “A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow“, ¶50, “ Workflow association settings are stored as properties of a list” and wherein the activity flow definition file [is] a complete copy of the executable logic defined by the case model of the stored singular building block See at least ¶48, “A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow“, ¶50, “ Workflow association settings are stored as properties of a list”. SharePoint and SharePoint1 does not explicitly disclose activity flow definition file lacks a complete copy of the executable logic defined by the case model.
Higgins disclose activity flow definition file lacks a complete copy of the executable logic defined by the case model of the stored singular building block (¶122, “workflow engine (223) parses a definition of a workflow and loads corresponding modules of the workflow for execution”, “workflow can be defined in a method file (e.g., as an application and/or as a module), which specifies the data connections between the modules in the workflow and the execution paths among the modules”, ¶136, “data package (219) contains the input data and the definition of the workflow but typically not the detailed instructions to perform the tasks”, ¶525, “tasks implemented as plug and play modules (1208), which may be provided in shared libraries. Some of the modules referenced in the workflows of the eMethods may be methods (1209) as workflow of tasks and/or methods, which may be provided in XML files. The workflow engine (1207) interprets the workflows of the eMethods to load and execute the task modules”);
wherein the trigger setting for triggering the activity flow, is evaluated through the first reference and the second reference added to the activity flow definition file and, responsive to the condition or rule being met, the activity flow is triggered to automatically execute (¶122-123, “workflow can be defined in a method file (e.g., as an application and/or as a module), which specifies the data connections between the modules in the workflow and the execution paths among the modules. The workflow engine causes the modules that are specified in the method file to be executed”).
SharePoint-SharePoint1 and Higgins are analogous art io the claimed invention because they are from a similar field of endeavor of generating, applying and using workflows for projects management. Thus, i would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify SharePoint-SharePoint1 resulting in resolutions as disclosed by Higgins with a reasonable expectation of success.
One of ordinary skill in the art would be motivated to modify SharePoint-SharePoint1 as described above to save storage space by making the definition files smaller and easier to manage. It also facilitate updating and modifying the shared logic of workflows by allowing a single update in one place (shared logic) to be reflected in every workflow, making maintenance faster and more efficient. This is simply combining prior art elements according to known methods to yield predictable results, use of known technique to improve similar devices (methods, or products) in the same way, and applying a known technique to a known device (method, or product) ready for improvement to yield predictable results (MPEP 2143).
Applicant argue that the currently cited prior art wholly fails to disclose "activity flow definition file" which "lacks a complete copy of the executable logic defined by the case
model of the stored singular building block" and is a separate element from "the stored singular building block" for the reasons stated above.
Examiner respectfully disagrees, as previously explained the combined references SharePoint1 and Higgins meet the requirements that the activity flow definition does not include a complete copy of executable logic and is functionally distinct from the stored building block. Therefore the arguments are not persuasive.
Applicant argue that the references fails to disclose inserting "the activity flow" into "a first particular pre-defined stage of a first lifecycle model and a second particular pre-defined stage of a second lifecycle model" by "adding a first reference to the first lifecycle model and a second reference to the second lifecycle model" to the "activity flow definition file."
Examiner respectfully disagrees, the requirement disclose inserting an activity flow into pre-defined stages of lifecycle model by adding references to the activity flow definition file. Under broadest reasonable interpretation a “reference” corresponds to the association between stored workflow definition and a lifecycle context. SharePoint1 teach the workflow definition is created and stored independently and associated with project or list (See at least ¶50, ¶85) linking the workflow into lifecycle. Furthermore, execution occurs at pre-defined points based on conditions or events (e.g. item creation or modification) which is a predefined stage within lifecycle model. Accordingly, associating the same stored workflow definition with different contexts and execution points is adding first and second references to different lifecycle models and inserting the activity flow in different stages.
Response to applicant arguments related to claim 1 is applicable to claims 8 and 15 as they have been amended in the same manner to claim 1.
As to the remaining independent claims, applicant argue that they are allowable due to their respective direct and indirect dependencies upon one of the aforementioned Independent claims. The examiner respectfully disagrees, Independent claims were not allowable as stated in the paragraph above in this “Response to Arguments” section in this office action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
US Patent Application No. 20200126017 filled by Damonte et al. Disclose the usage of Graphical User Interface to create activity flow that include a number of tasks See at least Fig. 4, ¶127, ¶135,
US Patent Application No. 2006/0069605 filled by Hatoun Disclose the usage of Graphical User Interface to create reusable activity flow (workflow) that include a number of tasks See at least Fig. 4B, ¶8, ¶12, ¶49
US Patent Application No. 2006/0074736 filled by Shukla et al. Disclose the usage of Graphical User Interface to create reusable activity flow (Workflow Designer) that include a number of tasks See Fig. 5
US Patent Application No. 2010/0241990 filled by Gabriel et al. Disclose the usage of Graphical User Interface to create reusable activity flow (Workflow Designer) that include a number of tasks See ¶27
US Patent Application No. 20090222277 filled by Malek et al. Disclose the usage of Graphical User Interface to create activity flow that include a number of tasks See at least Fig. 5-10.
Examiner has pointed out particular references contained in the prior arts of record in the body of this action for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and Figures may apply as well. It is respectfully requested from the applicant, in preparing the response, to consider fully the entire references as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior arts or disclosed by the examiner. It is noted that any citation to specific pages, columns, figures, or lines in the prior art references any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331-33, 216 USPQ 1038-39 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968)).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED ABOU EL SEOUD whose telephone number is (303)297-4285. The examiner can normally be reached Monday-Thursday 9:00am-6:00pm MT.
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, Michelle Bechtold can be reached at (571) 431-0762. 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.
/MOHAMED ABOU EL SEOUD/Primary Examiner, Art Unit 2148
Prosecution Insights