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 Non-Final Office action, responsive to Applicant’s communication of 9/17/24, in which Applicant filed the application. Claims 1-20 are pending in this application and have been rejected below.
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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/17/24, 10/23/24, and 2/17/25 are being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8, 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 8, 16 recite the limitation "wherein the at least one draft functional description may be generated for an activity a tool catalog element has been tagged to it." There is insufficient antecedent basis for this limitation in the claim as “activity” is already recited, and some grammar issues as well, making it unclear what is happening here. In addition, claims 8, 16 also have “may be” language, which is renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d). For purposes of applying prior art only, Examiner’s best guess is to interpret claim 8 similar to claim 7 above, as reciting “wherein the at least one draft functional description is an]] the activity by a tool catalog element
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, as best understood in light of grammar/112 issues to be similar to claim 7 but not depending from claim 3, narrow the abstract idea by allowing a user to tag elements from a catalog for the 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.”
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 may be generated for an activity a tool catalog element has been tagged to it (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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Lee (US 10,248,385) – directed to users being able to search for workflows based on entering a user story and/or tags (See col. 4, lines 30-38).
Avhad (US 2022/0050969) – directed to analyzing a textual narrative and creating a feature corresponding to a textual narrative to realize the functionality (See par 123, FIG. 6) and checking user stories for quality (See par 108).
Baina et al, “Business Process Modelling Augmented: Model Driven transformation of User Stories to Processes”, 2020, Proceedings of the 13th International Conference on Intelligent Systems: Theories and Applications, pages 1-7 – directed to formulating user stories fusing a standard syntax, discovering a process map, and then modeling a process by drawing a basic BPMN diagram (See page 4, col. 2).
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