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 .
Notice to Applicant
The following is a Final Office action. In response to Examiner’s Non-Final Rejection of 2/5/26, Applicant, on 6/5/26, amended claims. Claims 1-20 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The 112(b) rejections of claims 8 and 16 are withdrawn in light of the amendments.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119(e) as follows:
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 nonprovisional 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 35 U.S.C. 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. 63/435,634, 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 regarding “user stories” (all claims).
Accordingly, the priority for this application goes back to 18/392,554 and 63/458,306, with a filing date of 4/10/23.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a system which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
A system to provide dynamic digital construction of a process flow implementation specification, comprising:
…
receive an entry of a dynamic activity or event description required to perform a process;
generate at least one draft user story and at least one draft functional description, based on data in the received activity or event description; and
display to a user a process flow implementation specification including information selected from the group consisting of the at least one user story, the at least one functional description, and additional documentation to illustrate a work flow process to a user.
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity” (managing personal behavior or relationships or interactions between people (including following rules or instructions), as the claim involves a user describing a process, such as human-related activities and steps within a business process according to Applicant’s [0306] as published and “business process flows” in e.g. Applicant’s [0422-0423] as published. The claim is receiving description for performing a process (e.g. a business process), then generating a draft user story and draft functional description; then displaying to a user a process flow specification requiring only one of either “the at least one user story, the at least one functional description,” or “additional documentation” which either illustrate a work flow process for a user to view. One of Applicant’s example is having a report checked and then approved or rejected (FIG. 9B). Accordingly, at this time, claim 1 is directed to an abstract idea.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. In particular, the claim recites additional elements that are:
A system to provide dynamic digital construction of a process flow implementation specification, comprising:
a processor communicatively coupled to a storage device, wherein the processor executes application code instructions that are stored in the storage device to cause the system to:
receive an entry of a dynamic activity or event description required to perform a process;
generate at least one draft user story and at least one draft functional description, based on data in the received activity or event description; and
display to a user a process flow implementation specification including information selected from the group consisting of the at least one user story, the at least one functional description, and additional documentation to illustrate a work flow process to a user.
The claims, individually or when viewed in combination, are viewed reciting the computer at a high-level of generality (i.e., as a generic processor performing each step) such that it amounts no more than mere instructions to apply the exception using a generic computer component. See MPEP 2106.05(f). At best it is “field of use” (MPEP 2106.05h) in that the processor is used to “generate” a user story and functional description based on entry of activity/event description for the process, and then “display” story/functional description/documentation to illustrate to the user the work flow (e.g. reports and being approved; or [0322-324] as published – “make headcount adjustments”). Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim also fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, and/or an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See 84 Fed. Reg. 55. The claim is directed to an abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in claim 1 of “processor and instructions to cause the system to display”; are “apply it” on a computer. (See MPEP 2106.05(f) – Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. The claim is not patent eligible. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent claim 9 is directed to an article of manufacture at step 1, which is a statutory category. Claim 9 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one. At step 2a, prong 2, claim 9 recites a non-transitory computer-readable storage device having computer-executable program instructions executed to perform each step. Similar to the analysis of claim 1 above, this is just “apply it” on a computer (MPEP 2106.05f) for the same reasons stated above with regards to claim 1 at step 2a, prong 2 and step 2B. The claim is not patent eligible.
Independent claim 17 is directed to a method at step 1, which is a statutory category. Claim 17 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one. At step 2a, prong 2, claim 17 recites a computer devices to perform each step. Similar to the analysis of claim 1 above, this is just “apply it” on a computer (MPEP 2106.05f) for the same reasons stated above with regards to claim 1 at step 2a, prong 2 and step 2B. The claim is not patent eligible.
Claims 2, 10, and 18 have additional elements of executing “application code instructions stored in storage device” to determine whether entered dynamic activity/event description corresponds to a description already stored within the system. This is viewed as “apply it [abstract idea] on a computer” MPEP 2106.05(f); and “field of use” (MPEP 2106.05h) for similar reasons as claim 1.
Claims 3, 11, and 19 narrow the abstract idea by allowing the user to edit the draft user story and draft functional description; to extent it is on a computer, it is also viewed as an additional element of “apply it [abstract idea] on a computer” MPEP 2106.05(f). Claims 7, 15 depend from claims 3, 11 and narrow the abstract idea by allowing a user to tag elements from a catalog for the story and functional description generation. See e.g. Applicant’s [0307] as published – “enabling users to pull elements directly from the catalog and to tag those elements within the text of a description.”
Claims 4, 12, and 20 narrow the abstract idea by selecting aspects of a draft user story and draft functional description; to extent it is on a computer as it is “automatically selected”, it is also viewed as an additional element of “apply it [abstract idea] on a computer” MPEP 2106.05(f). Claims 5, 13 depend from 4 and 12, and narrow the abstract idea as they have “aspects” of user story and functional description that have “references” to traits and characteristics.
Claims 6, 14 narrow the abstract idea by stating the user has already generated the draft user story.
Claims 8, 16, is similar to claim 7 but not depending from claim 3. Claim 8, 16 narrow the abstract idea by having draft functional description based on a tool catalog element tagged to received activity or event description. See e.g. Applicant’s [0307] as published – “enabling users to pull elements directly from the catalog and to tag those elements within the text of a description.” To extent it is on a computer, it is also viewed as an additional element of “apply it [abstract idea] on a computer” MPEP 2106.05(f).
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Higgins (US 2019/0220252) in view of Srinath (US 2023/0153723).
Concerning claim 1, Higgins discloses:
A system to provide dynamic digital construction of a process flow implementation specification (Higgins – see par 27 – computing device 104 stores a requirement data generator application 152; See par 28 - output requirement data is collected before (for software development following the waterfall model) or during (for software development following the Agile model) the development of a new software application in order to document the desired functionality of the new application; see par 29 - User stories generally define a requirement of the new software application in terms of the functionality expected by a user of the application), comprising:
To any extent Higgins does not disclose a “process flow implementation specification,” K Srinath discloses (K Srinath – See par 32 – generating of workflows in computing systems, software applications; workflow manager engine/system 1048 may include… workflow templates 108, configuration specifications 110, workflow generator 112, workflow manager interface 116; see par 49 - Upon completion of the workflow and the connection object setup, the workflow may be generated, at 214, as shown in FIG. 2. The generated workflow may be tested (e.g., using button 308 shown in FIG. 3). If the testing of the workflow results in any errors, the errors may need to be fixed prior to workflow being implemented. Upon satisfactory completion of testing (e.g., no errors), the workflow may be saved to the storage location 106 (shown in FIG. 1). Additionally, the workflow, the connection object and/or any other configuration data, parameters, etc. may be saved as a workflow template 108).
Higgins and K Srinath disclose:
a processor communicatively coupled to a storage device, wherein the processor executes application code instructions that are stored in the storage device to cause the system ((Higgins – see par 27 - Computing device 104 stores, in memory 112, a requirement data generator application 152 (also referred to herein as “application 152”), comprising a plurality of computer-readable instructions executable by processor 108. Processor 108, via execution of the instructions of application 152, is configured to provide certain input interfaces on display 120, as will be described below. Processor 108 is further configured to automatically generate various types of output requirement data (e.g. user story data, use case data, test case data, and the like) from input received via the above-mentioned interfaces in connection with the development of a software application (referred to herein as a “new” or “proposed” application, to be distinguished from application 152)) to:
receive an entry of a dynamic activity or event description required to perform a process (Higgins – see par 27 - Processor 108 is further configured to automatically generate various types of output requirement data (e.g. user story data, use case data, test case data, and the like) from input received via the above-mentioned interfaces in connection with the development of a software application (referred to herein as a “new” or “proposed” application, to be distinguished from application 152).
see also K Srinath – see par 7 – request may be received using … a natural language processing query);
generate at least one draft user story and at least one draft functional description, based on data in the received activity or event description (Applicant’s [0312] as published states “A user story is a standard documentation method that describes a goal for a particular person, and how a future piece of work, such as software development, may accomplish that goal. User stories are often used in software development to break down work processes into smaller tasks that developers can work to produce. Developers may then test the software to verify that the software accomplishes the goals that have been set
Higgins discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 29 - User stories generally define a requirement of the new software application in terms of the functionality expected by a user of the application. User story data will be described below in greater detail. Use case data includes elements describing interactions between a user and a system (that is, the system to be governed by the new application). Test case data, meanwhile, includes test step definitions describing various steps used to test the functionality of the system during execution of the new application. see par 63 - An example set of conversion rules for converting the input records to user story data elements is shown below in Table 1. The user story fields in Table 1 are illustrated in FIG. 12, which depicts an example user story interface 1200 generated on display 120); and
display to a user a process flow implementation specification including information selected from the group consisting of the at least one user story, the at least one functional description, and additional documentation to illustrate a work flow process to a user (Higgins – see par 51 - Referring now to FIG. 9, an example interface 900 present on display 120 is depicted, following multiple performances of method 200. In particular, a plurality of tasks 904-1, 904-2, 904-3, 900-4 and 900-5 (collectively referred to as tasks 900) are depicted, each with a prior state 908-1, 908-2, 908-3 and 908-4 (collectively referred to as prior states 904) representing a system task. A final system task 908-5 is also shown. The illustrated tasks and decisions together define a sequence of operations performed by the above-mentioned airline check-in application, in response to various inputs provided to the airline check-in application by a user. see par 53 - Turning now to FIG. 10, example task and decision records as stored in memory 112 are depicted, corresponding to the process flow shown in FIG. 9. In particular, a plurality of records 1000, 1004, 1008, 1012, 1016, 1020 and 1024 are shown as stored in memory 112. Each record contains record data defining a task or a decision, and may also contain a link to another record. The records of FIG. 10, in other words, reconstruct the process flow shown in FIG. 9;
see also K Srinath – see par 63 - At 908, the plurality of functions may be arranged for execution in a predetermined order using the determining plurality of configuration parameters and identified one or more connection objects. The predetermined order may be specified using one or more configuration parameters in the plurality of configuration parameters. An exemplary order is illustrated in FIG. 6, where workflow function 502c follows workflow function 502b.)
Both Higgins and Srinath are analogous art as they are directed to forming process flow/workflows for business processes (See Higgins Abstract, par 65; Srinath Abstract, par 23-24, 37). Higgins discloses receiving requirements and then performing software development for functionality expected by a user (See par 27-29). Srinath improves upon Higgins by disclosing having workflow templates, configuration specifications (See par 32) where workflow to be implemented with configuration data and parameters can then be saved as a template (See par 49). One of ordinary skill in the art would be motivated to further include having workflow templates and configuration specifications to efficiently have specifications to prepare workflows for implementation and further the requirements expected by a user in Higgins.
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 the system and method of defining and generating requirement data in Higgins to further have workflow templates, configuration specifications (See par 32) where workflow to be implemented with configuration data and parameters can then be saved as a template (See par 49) as disclosed in Srinath, 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 9, Higgins discloses:
A computer program product, comprising:
a non-transitory computer-readable storage device having computer-executable program instructions embodied thereon that when executed by a computer cause the computer to provide digital construction of a process flow implementation specification, the computer-executable program instructions comprising (Higgins – see par 20 - Computing device 104 includes a central processing unit (CPU), also referred to as a processor 108 interconnected with a non-transitory computer readable storage medium such as a memory 112. see par 27 - Computing device 104 stores, in memory 112, a requirement data generator application 152 (also referred to herein as “application 152”), comprising a plurality of computer-readable instructions executable by processor 108. Processor 108, via execution of the instructions of application 152, is configured to provide certain input interfaces on display 120, as will be described below. Processor 108 is further configured to automatically generate various types of output requirement data (e.g. user story data, use case data, test case data, and the like) from input received via the above-mentioned interfaces in connection with the development of a software application (referred to herein as a “new” or “proposed” application, to be distinguished from application 152)):
The remaining limitations are similar to claim 1. Claim 9 is rejected for the same reasons as claim 1.
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1.
Concerning independent claim 17, Higgins discloses:
A method to provide digital construction of a process flow implementation specification, comprising:
by one or more computing device: (Higgins – see par 20 - computing device 104 includes a central processing unit (CPU), also referred to as a processor 108 interconnected with a non-transitory computer readable storage medium such as a memory 112. see par 27 - Computing device 104 stores, in memory 112, a requirement data generator application 152 (also referred to herein as “application 152”), comprising a plurality of computer-readable instructions executable by processor 108. Processor 108, via execution of the instructions of application 152, is configured to provide certain input interfaces on display 120, as will be described below. Processor 108 is further configured to automatically generate various types of output requirement data (e.g. user story data, use case data, test case data, and the like) from input received via the above-mentioned interfaces in connection with the development of a software application (referred to herein as a “new” or “proposed” application, to be distinguished from application 152)):
The remaining limitations are similar to claim 1. Claim 17 is rejected for the same reasons as claim 1.
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1.
Concerning claims 2, 10, and 18, Higgins and Srinath disclose:
The system of claim 1, wherein the processor executes application code instructions that are stored in the storage device (Higgins – see par 27 - Computing device 104 stores, in memory 112, a requirement data generator application 152 (also referred to herein as “application 152”), comprising a plurality of computer-readable instructions executable by processor 108. ) to further cause the system to determine whether the entered dynamic activity or event description corresponds to activity or event description data stored within the system (Higgins – See par 27 - memory 112 also maintains a data store 156 containing a collection of data for the new application, and a set of conversion rules 160. see par 33 - As a further example, a traces element (not shown; which may also be referred to as a relationships element) can be selectable to cause device 104 to present yet another interface displaying connections stored in memory 104 between the task identified in field 308 and other portions of repository 156 (e.g. other requirement data for the application under development). see par 35 - Processor 108 can be configured, upon receiving a selection of field 304 from an input device such as pointing device 118, to present a plurality of previously configured actor identifiers stored in repository 156 (for example, in a drop-down menu). see par 65 - Business rules may be entered in field 1248 as strings of text, or as references to business rules stored elsewhere in repository 156.
see also Srinath – see par 43 - he configuration file may be configured to include one or more APIs (e.g., external APIs that may be required for connection to an external data source, database, an external computing component, application, etc.) that may be needed for a particular workflow. see par 50 - The workflows may each include a name, an identifier, and/or any other way to identify the workflows. The workflows 502 may be accessible to users 102 and/or may be used by the users 102 for performing various tasks. To access a particular workflow, the user 102 may issue a query. For example, “Create model with live data source”. This would search templates 502 using identifiers, tags, etc. which may have been added during workflow template generation process (e.g., process 200 shown in FIG. 2).).
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1.
Concerning claims 3, 11, and 19, Higgins and Srinath disclose:
The system of claim 1, wherein the at least one draft user story and the at least one draft functional description are editable by the user (Higgins –see par 29 - User stories generally define a requirement of the new software application in terms of the functionality expected by a user of the application. User story data will be described below in greater detail; see par 65 - Field 1248, on the other hand, can receive input data representing one or more business rules that modify the relevant stage of the process flow in FIG. 9. For example, a business rule may be received in connection with a user story generated from record 1012 (at which the user enters a number of bags) specifying that a number of bags greater than two should provoke a modified response from the system.
see also par Srinath par 30 - using the user interface of the workflow manager, users may select one or more pre-defined workflows from one or more user interface panels and then drag-and-drop the workflows into workflow manager’s canvas area. In some implementations, the workflow manager may be configured to provide a compiling functionality of the generated workflow to ensure that when the generated workflow is put in a production environment, it will operate in accordance with its requirements and/or any requirements; see par 36 - If the workflow does not exist …, the user 102 may transmit a query (e.g., a search query) to the workflow manager engine 104, for example, via the workflow manager interface 116, seeking user-desired workflow(s); see par 37 - The administrator user 102 may be configured to cause (e.g., via the workflow manager interface 116) generation one or more workflows using one or more workflow templates 108, one or more configuration parameters, one or more configuration specifications 110. The configuration specification 110 may also specific one or more connection computing components (e.g., connection objects) 114 that may be needed for the purposes of connecting various computing components and/or data that may be stored at the storage location 106.).
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1.
Concerning claims 4, 12, and 20, Higgins and Srinath disclose:
The system of claim 1, wherein aspects of the at least one draft user story and the at least one draft functional description are automatically selected (Higgins – see par 68 - It is contemplated that more complex conversion rules may be provided to handle the automatic generation of user story elements from underlying task records that are adjacent to decision records. For example, conversion rules 160 may specify that when a task record is selected for conversion that is adjacent to a decision record, one user story element is generated for each branch of the decision. see par 70 - for example, the above systems and methods can lead to a reduction in the need (and storage requirements) for input data, particularly in connection with the generation of user stories, use cases and the like, by automatically assigning actor identifiers in certain use case data elements.
see also Srinath – see par 53 - The workflow templates 708 may be generated for specific workflow (e.g., by a user, automatically, manually, etc.). see par 54 - The workflow manager engine 704 may be configured to generate a workflow that a user may wish to use; may include artificial intelligence and/or learning capabilities that may… identify one or more workflows previously generated).
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1.
Concerning claims 6 and 14, Higgins and Srinath disclose:
The system of claim 1, wherein aspects of the at least one draft user story are user-generated (Higgins – see par 27 - Processor 108 is further configured to automatically generate various types of output requirement data (e.g. user story data, use case data, test case data, and the like) from input received via the above-mentioned interfaces in connection with the development of a software application; see par 29 - User stories generally define a requirement of the new software application in terms of the functionality expected by a user of the application.).
Concerning claims 7 and 15, Higgins discloses “Processor 108 can be configured, upon receiving a selection of field 304 from an input device such as pointing device 118, to present a plurality of previously configured actor identifiers stored in repository 156 (for example, in a drop-down menu). The receipt of an actor identifier at block 210 can therefore include the selection of an actor identifier from such a drop-down menu” (See par 35) and “processor 108 can be configured to receive a requirement type identifier. The requirement type identifier received at block 1105 can be received as input data from an input device. For example, the requirement type can be received as a selection of a requirement type identifier presented on display 120” (See par 58).
Srinath discloses:
The system of claim 3, wherein the at least one draft user story and the at least one functional description are generated based on catalog elements tagged to the activity or event (Applicant’s [0034] as published - The process model application 112 may utilize a catalog 113. The catalog 113 may represent any database or other compilation of data that may be used to populate a process model, such as a database of persons, equipment and other enterprise assets, data, materials, instructions, attributes, features, or other aspects of an event or feature. [0342-0344, 0404] as published state “The draft functional requirements may be generated in the background based on an activity's smart description 903, short description 905, the catalog elements tagged 904, inputs/outputs, and other attributes for that specific activity. Draft functional requirements may be generated for activities when a tool catalog element has been tagged to it and input/output associations.”
Srinath discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 29 - The workflow manager may be configured to provide one or more templates (e.g., predefined structures) for generating a portion and/or an entire a workflow; see par 50 - The workflows 502 may have been previously generated, such as, for example, using process 200 shown in FIG. 2, and may have been saved as one or more templates 108 (e.g., either by the workflow manager engine 104 and/or at the storage location 106). The workflows may each include a name, an identifier, and/or any other way to identify the workflows. The workflows 502 may be accessible to users 102 and/or may be used by the users 102 for performing various tasks. To access a particular workflow, the user 102 may issue a query. The query may identify a specific workflow (e.g., using workflow identifier). Alternatively, or in addition, the query may be a free text query (e.g., “find me procurement workflow”). For example, “Create model with live data source”. This would search templates 502 using identifiers, tags, etc. which may have been added during workflow template generation process (e.g., process 200 shown in FIG. 2).
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1. In addition, Higgins discloses “receiving a selection of field 304 from an input device such as pointing device 118, to present a plurality of previously configured actor identifiers stored in repository 156 (for example, in a drop-down menu) (See par 35) and “requirement type identifier received at block 1105 can be received as input data... the requirement type can be received as a selection of a requirement type identifier presented on display 120” (See par 58). Srinath improves upon Higgins by disclosing using templates to generate a portion and/or an entire workflow (See par 29) and querying for saved/template workflows using text/identifiers/tags (See par 50). One of ordinary skill in the art would be motivated to further include having workflow templates where identifiers/tags used to find templates to efficiently further the requirements expected by a user in Higgins.
Concerning claims 8 and 16, Higgins and Srinath disclose:
The system of claim 1, wherein the at least one draft functional description is generated based on a tool catalog element tagged to the received activity or event description (Applicant’s [0034] as published - The process model application 112 may utilize a catalog 113. The catalog 113 may represent any database or other compilation of data that may be used to populate a process model, such as a database of persons, equipment and other enterprise assets, data, materials, instructions, attributes, features, or other aspects of an event or feature. [0342-0344, 0404] as published state “The draft functional requirements may be generated in the background based on an activity's smart description 903, short description 905, the catalog elements tagged 904, inputs/outputs, and other attributes for that specific activity. Draft functional requirements may be generated for activities when a tool catalog element has been tagged to it and input/output associations.”
Srinath discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 29 - The workflow manager may be configured to provide one or more templates (e.g., predefined structures) for generating a portion and/or an entire a workflow; see par 50 - The workflows 502 may have been previously generated, such as, for example, using process 200 shown in FIG. 2, and may have been saved as one or more templates 108 (e.g., either by the workflow manager engine 104 and/or at the storage location 106). The workflows may each include a name, an identifier, and/or any other way to identify the workflows. The workflows 502 may be accessible to users 102 and/or may be used by the users 102 for performing various tasks. To access a particular workflow, the user 102 may issue a query. The query may identify a specific workflow (e.g., using workflow identifier). Alternatively, or in addition, the query may be a free text query (e.g., “find me procurement workflow”). For example, “Create model with live data source”. This would search templates 502 using identifiers, tags, etc. which may have been added during workflow template generation process (e.g., process 200 shown in FIG. 2).
It would have been obvious to combine Higgins and Srinath for the same reasons as discussed with regards to claim 1 and claim 7.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Higgins (US 2019/0220252) in view of Srinath (US 2023/0153723), as applied to claims 1-4, 6-12, and 14-20 above, and further in view of Boyer (US 2017/0364824).
Concerning claims 5 and 13, Higgins discloses automatically generating output requirement data (See par 27), “automatically” generating various types of requirement data upon completion of method 200 (See par 57-58), and automatic generation of user story elements from underlying task records adjacent to decision records (See par 68). Srinath discloses automatically generating workflow templates for a “specific” workflow (See par 53).
Boyer discloses:
The system of claim 4, wherein the aspects include references to traits and characteristics (Applicant’s [0109] as published states “Attributes specific to the category of the catalog 113, such as a category of persons or places, are associated with each element to add context to that element.” Applicant’s [0266] as published states “Traits are attributes of both activities and catalog elements.” Applicant’s [0268] as published states “The trait data may be collected from any other source, such as being extracted from metadata associated with an automated process.” Boyer discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 30 - By providing a method for extracting contextual semantic information from the graphical representation and metadata of a business process model allowing for injection of organizational characteristics in a project management system; some embodiments of the present invention include one or more programs 440 that comprise tools that perform a tool-based semantic analysis of any human-created user stories and automatically generate respective work items and estimates that impact the process model; tool-based semantic analysis of business process model artifacts with missing user stories and automatically generate user stories).
Higgins, Srinath, and Boyer are analogous art as they are directed to forming process flow/workflows for business processes (See Higgins Abstract, par 65; Srinath Abstract, par 23-24, 37; Boyer Abstract, par 21, 23). Higgins disclose automatic generation of user story elements from underlying task records adjacent to decision records (See par 68) and automatically generating output requirement data (See par 27) and “automatically” generating various types of requirement data upon completion of method 200 (See par 57-58). Srinath discloses automatically generating workflow templates for a “specific” workflow (See par 53). Boyer improves upon Higgins and Srinath by disclosing automatically generating user stories based on context, semantic, and metadata. One of ordinary skill in the art would be motivated to further include using context, semantic, and metadata to efficiently automatically generate user stories and/or work items to further refine the automatic generation of requirement data and user story elements in Higgins and the automatic generation of workflow templates for “specific” workflow in Srinath.
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 the system and method of defining and generating requirement data in Higgins to further have workflow templates, configuration specifications (See par 32) where workflow to be implemented with configuration data and parameters can then be saved as a template (See par 49) as disclosed in Srinath, and to further use context, semantic, and metadata for automatically generating user stories as disclosed in Boyer, 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.
Response to Arguments
Applicant's arguments filed 6/5/26 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With regards to 101, Applicant argues that the claim is not directed to an abstract idea because it is a computer-implemented process for digitally constructing a process flow, where the focus is the digital construction of a process implementation specification based on data in a received activity or event description. Remarks, page 7. In response, Examiner respectfully disagrees. Applicant appears to be arguing “there is a computer”, so therefore it’s not directed to an abstract idea. However, additional elements, such as a computer, are analyzed under step 2a, prong two and step 2B. Here, the arguments that there is a process flow, based on receiving entry of dynamic activity or “event description” of process, and then a resulting generation of a draft user story and functional description, to then display a process flow specification that includes either user story, description, OR additional documentation is still directed to an abstract idea. The claim involves a user describing a process, such as human-related activities and steps within a business process according to Applicant’s [0306] as published and “business process flows” in e.g. Applicant’s [0422-0423] as published. The claim is receiving description for performing a process (e.g. a business process), then generating a draft user story and draft functional description; then displaying to a user a process flow specification requiring only one of either “the at least one user story, the at least one functional description,” or “additional documentation” which either illustrate a work flow process for a user to view. One of Applicant’s example is having a report checked and then approved or rejected (FIG. 9B).
Applicant then argues that the claim is “dynamic digital construction”, “dynamic activity OR event description” and based on “data”, so therefore is not directed to an abstract idea. Remarks, page 8. In response, Examiner respectfully disagrees. First, there are no details as to what the “dynamic” in the two instances in claim 1, or any dependent claim, are referring to. At this time, this is interpreted as referring to just receiving information and generating a resulting process flow. Should there be some technical details, or specific aspects tied to being “dynamic” in the specification, Applicant is welcome to recite them. The other arguments here are just referring to the fact there is a computer. The computer is an additional element, but here, reciting a computer at such a high level is considered “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong two and step 2B. Applicant then argues that [0002] of the specification, describing “Field of the Invention” is for “logic-based parameters.” Remarks, page 7. Examiner respectfully disagrees with this analysis. First, there are no parameters or logic even recited in the claim. Second, it appears even if they were referred to, in at least one example from Applicant’s specification, the parameters could just be the same manual process values and conditions that would be followed in a manual process, such as FIG. 10B and [0440-0442], and checking if “10 minute time limit on process steps.” Applicant then argues that [0003] of the specification states that here there are “data-driven and dynamic features.” Remarks, page 7. Examiner respectfully disagrees with this analysis. [0003] states : “provide opportunities for data-driven and dynamic features that allow individuals to capture, visualize, measure the interdependent aspects of the process flow, and provide an assessment of its quality, feasibility, and other benefits.” First, it is unclear how “features” or other aspects of [0003] is required by the claims. Second, this statement appears to be discussing “individuals” in different regards.
With regards to Step 2a, Prong two, Applicant argues the ordered combination in computer processing to “generate at least one draft user story and at least one draft functional description based on data in the received activity or event description and display the claimed process flow implementation specification” makes the claim a practical application. Remarks, page 8-9. In response, Examiner respectfully disagrees. Here, there are no details on how the user story and functional description is generated. The result is “apply it [abstract idea] on a computer,” when viewing the limitations individually or in combination. See MPEP 2106.05(f)- “The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it". See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015).”
Applicant further argues a catalog may represent a compilation of persons, equipment…attributes…features, or other aspects of an event or feature in [0034, 0039]. Remarks, page 9. In response, Examiner respectfully disagrees. First, this is not recited in the claims. Second, catalog is only recited in claims 7-8, but not to this specificity of [0034, [0039]. Third, even if it was, just stating that the story represents various descriptive elements is not helpful for eligibility. None of these aspects are explained in a way towards achieving a user story.
Applicant further argues a process model application “automatically translates a dynamic event into several outputs… including user stories, functional requirements, and other documentation”’ in [0355]; there are “exact moments in a work event that a goal or task or work event must be accomplished [0367, 0401]. Remarks, page 9. In response, Examiner respectfully disagrees. There is no “translate” or “exact moments” in any of the claims. The ”exact timing” or scheduling requirements appears to be part of the abstract idea if it were to be claimed.
With regards to Step 2B, Applicant argues the computer operations of “receive, generate, and display” are not properly rejected as conventional under step 2B and evidence is required. Remarks, page 8-9. In response, Examiner respectfully disagrees. With regards to step 2B, only those additional elements (analyzed under 2B) that are deemed “conventional” need to comply with Berkheimer. When elements are just part of “apply it” [abstract idea] on a computer, under MPEP 2106.05(f); or “field of use” under MPEP 2106.05h, no evidence is needed.
With regards to 103, Applicant argues that Higgins does not disclose the claimed context of “receiving an activity of event description required to perform a process.” Remarks, page 11. In response, Examiner respectfully disagrees. Higgins disclose generating output requirement (e.g. user story data) from “input received” in paragraph 27. Applicant’s argument is not persuasive.
Applicant then appears to be arguing that Higgins does not disclose “generate at least one draft user story and at least one draft functional description, based on data in the received activity or event description.” Remarks, page 11. In response, Examiner respectfully disagrees. Higgins disclose generating output requirement (e.g. user story data) from “input received” in paragraph 27. Higgins then discloses that user stories define a requirement “in terms of the functionality”, as well as testing functionality in paragraph 29. Applicant’s argument is not persuasive.
Applicant then appears to be arguing that Higgins does not disclose “a process flow implementation specification” in FIG.s 9-10 and Higgins [0051-0053] because Higgins only has “reconstruct[ed] execution steps. Remarks, page 11. In response, Examiner respectfully disagrees. Higgins explicitly states its software forms a “process flow”. Srinath was also applied in the alternative in [0063] where functions are arranged for execution in a predetermined order. Applicant’s arguments are not persuasive. Applicant then argues that the specification describes the process model as translating dynamic events into outputs [0355], that user stories may be generated on an activity’s smart description, short description, and catalog elements tagged to a specific activity ([0365, 0368]); that functional requirements correspond to draft functional description, specific to processes occurring in different activities across various tools and as based on smart descriptions… tagged catalog elements…and other attributes ([0399-0403]). Remarks, page 11-12. In response, Examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., translating, smart description, catalog elements for generating user stories; various tools based on smart descriptions, tagged catalog elements, and other attributes) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant then argues that Higgins disclosure of use case data or test case data is unrelated to “draft functional description”. Remarks, page 12. In response, Examiner respectfully disagrees. First, the claim does not give specifics for the “draft user story and at least one draft functional description.” Second, Applicant’s [0312] states “A user story is a standard documentation method that describes a goal for a particular person, and how a future piece of work, such as software development, may accomplish that goal. User stories are often used in software development to break down work processes into smaller tasks that developers can work to produce. Developers may then test the software to verify that the software accomplishes the goals that have been set.” Thus, Applicant’s specification even gives an example where the user story encompasses a test process by developers; and under this interpretation, Higgins discloses the limitation and makes it obvious. Applicant is invited to amend the claim to distinguish from the art.
Applicant then argues Srinath but appears to be arguing all the limitations Srinath are not applied for. Remarks, page 12-13. Examiner respectfully disagrees. The arguments are not persuasive as they do not address the substantive citations – e.g. Srinath par 32, 49 applied for “process flow implementation specification”; receive an entry of a dynamic activity or event description required to perform a process (par 7); “display to a user a process flow implementation specification including information selected from the group consisting of the at least one user story, the at least one functional description, and additional documentation to illustrate a work flow process to a user” (par 63). Srinath is for receiving a request for a workflow, and generating and compiling the workflow in FIG. 9 step 908 cited in paragraph 63. Paragraph 63 also points to FIG. 6 showing workflow templates and a display of predetermined order of steps. Notably, as pointed to in the explanation of combining Higgins and Srinath, Srinath par 23-24 is for building software to serve business objectives (see par 23).
Applicant then argues that Higgins and Srinath cannot be combined because Srinath does not say “user story.” Remarks, page 13. Examiner respectfully disagrees. In response to applicant's argument that Higgins and Srinath can only exist side-by-side due to lack of phrase “user story”, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
Applicant then argues there is no sufficient explanation of why Higgins and Srinath are combined and it is impermissible hindsight to do so. Remarks, page 13-14. Examiner respectfully disagrees. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Applicant then argues there that combining the references would change the character of the systems, and they could only exist in parallel. Remarks, page 14. Examiner respectfully disagrees. Higgins discloses receiving requirements and then performing software development for functionality expected by a user (See par 27-29). Srinath improves upon Higgins by disclosing having workflow templates, configuration specifications (See par 32) where workflow to be implemented with configuration data and parameters can then be saved as a template (See par 49). The workflow in Srinath is for software applications, such as for a specific business purpose (Srinath par 37) which is able to be used with the same requirements for software application in Higgins (par 27).
Regarding claim 5, Applicant only argues that Boyer does not disclose limitations that Higgins and Srinath were applied for. Remarks, page 14. Examiner respectfully disagrees with the piecemeal analysis.
Conclusion
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 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