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 . The following is a Final Action. Claims 1-20 are pending below.
Response to Amendments
Applicant’s amendments are acknowledged.
Response to Arguments
Objections to Claim 11 are withdrawn based on Applicant’s amendments.
Applicant’s arguments with respect to the 101 rejection have been fully considered but are moot in view of new grounds of rejection.
Applicant argues, “Applicant submits that the features of the independent claims, at least as now amended, cannot be considered as falling within the enumerated Mental Processes grouping, at least because the claimed subject matter is both not performed in the human mind and cannot practically be performed in the human mind. For example, the claims are directed to a process for configuring how the instance comments/reasons codes are displayed on a change status pop- up window on a user interface and when the change status pop-up window is displayed, which is not something that is performed in the human mind and cannot practically be performed in the human mind. See, e.g., para. [0026] of corresponding U.S. Publication No. 2025/0245593 ("Applicant's specification"). Therefore, the limitations of the independent claims are not directed to a judicial exception under Prong One.
Examiner responds the first three steps through “applying” are still within a mental process.
Applicant argues, “As described in Applicant's specification, a task scheduling tool may schedule interrelated and interdependent tasks (processes) into a predefined sequence referred to as a "schedule". As the tasks are executed, they may have a status assigned to them (e.g., "completed without errors" for tasks processed successfully; "completed with warnings" for tasks processed with warnings; and "completed with errors" for tasks processed with errors). A user may have the option to enter a reason for the status change. Conventional task scheduling tools only provide for the status change reason to be entered in a free text field, which is a general field that can accept any type of data in the form of text or numbers. Entering data in a free text form aspect for the status change reason may be a time consuming task for a user. Additionally, the free form aspect may make it challenging for a user to track the status change reasons and report on the status change reasons because they are all different. See, e.g., para. [0025] of Applicant's specification.
To resolve these problems, a status change explanation tool of embodiments provides predefined reason codes and free text reasons as flexible field control elements that may be applied to a manual status change of a scheduled process. A status of the execution for each process may be monitored, and the status may be manually updated to reflect a current status of the task. Pursuant to embodiments, the status may be updated in a change status pop-up window on a user interface. The change status pop-up window includes status change reason codes and free text reasons as field control elements for an end user to indicate why (e.g., provide a reason) they are manually changing the status of a process. The status change reason code provides for filtering on a status change reason code type (e.g., only show a list of reason codes relevant for approval) during reporting or other analysis. The free text reasons ("status change reason comments") field may receive free-form text from an end user. According to embodiments, and prior to application to one or more processes, a status change reason code field and/or status change reason comment field maybe configured per one or more status change explanation scenario elements ("scenarios"). The scenario may describe how (e.g., hidden or unhidden) the status change reason code field and the status change reason comment field are displayed, the condition (e.g., mandatory, optional, etc.) for their display, and rules (a value is mandatory, optional, etc.) associated with the fields. The scenario, as configured, is independent of any task.
Examiner recommends adding more details to the pop up window. In addition, the parameters are currently just being “linked” to a code. The “automatically display the explanation field parameters on the change status pop up window,” and inputting of values, does not go beyond a general link to display technology or beyond generic and routine display functions for displaying information. Because the claimed display functions are broadly claimed and are directed to the basic functions of display technology, the claims do not improve the functioning of the display and do not improve the technical field of visualization.
Applicant argues, “The end user executing the task may change the status of the task in the change status pop-up window populated based on the assigned configured scenario. The pre-defined list of reason codes may allow a user to quickly comment on process status changes. The pre-defined and configurable reason codes provide for quick and unified comments for status changes. Embodiments provide for the flexible definition (configuration) of scenarios to define in which instance comments/reason codes are hidden, optional or mandatory. Embodiments also provide for the re-use of scenarios for a unified behavior of the system with maximum flexibility. See, e.g., para. [0026] of Applicant's specification. (Emphasis added).
Examiner responds these elements are still generically recited, and fail to change the function of the display in a meaningful way that goes beyond a general link to display technology or beyond generic and routine display functions for displaying information.
Applicant’s arguments with respect to the 102 rejection have been fully considered but are moot in view of new grounds of rejection.
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., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Specifically, Claims 1-19 are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea.
Step 1 of the Alice/Mayo analysis is directed to determining whether or not the claims fall within a statutory class. Based on a facial reading of the claim elements, Claims 1-19 fall within a statutory class of process, machine, manufacture, or composition of matter.
With respect to Step 2A Prong One of the framework, the claims recite an abstract idea. Claim 1, 8 and 14 includes limitations reciting functionality for an algorithm for managing a list based on configurable parameters, including:
Select an explanation scenario from a plurality of explanation scenarios...
Configure each explanation scenario parameter for the selected explanation scenario, wherein configuration defines how one or more explanation fields and respective one or more explanation field parameters are displayed on a change status pop-up window of a user interface display;
Apply the configured explanation scenario to at least one process in a process list...
which is an abstract idea reasonably categorized as
mental processes – as each of the steps can be performed in the human mind (including an observation, evaluation, judgment, opinion).
Similarly, Claims 2-7, 9-13, 15-20 further recite operations that can be practically performed in the human mind and descriptive data that further narrows the abstract idea.
With respect to Step 2A Prong Two, the claims do not include additional elements that integrate the abstract idea into a practical application. Claim 1, 8 and 14 includes various elements that are not directed to the abstract idea under Step 2A Prong One of the framework. These additional elements include a memory, processor-executable program code, a processing unit, user interface. When considered in view of the claim as a whole, Examiner submits that the additional elements are not additional elements that integrate the abstract idea into a practical application because, these elements are generic computing elements performing generic computing functions and amount to mere instructions to apply the abstract idea on a computer under MPEP 2106.05(f). The “automatically display the explanation field parameters on the change status pop up window” fails to change the function of the display in a meaningful way that goes beyond a general link to display technology or beyond generic and routine display functions for displaying information. Because the claimed display functions are broadly claimed and are directed to the basic functions of display technology, the claims do not improve the functioning of the display and do not improve the technical field of visualization. As a result, Claim 1, 8 and 14 do not include additional elements that would integrate the abstract idea into a practical application under Step 2A Prong Two.
In Claim 4,10, and 16 the elements for a field receiving values amount to insignificant extrasolution data gathering activities to the judicial exception
Claims 2-3, 5-7, 9, 11-13, 15, and 17-19 do not include any additional elements beyond those recited with respect to claim 1 8 and 14. As a result, these claims do not include additional elements that would integrate the abstract idea into a practical application under Step 2A Prong Two for the same reasons as stated above with respect to claim 1 8 and 14.
With respect to Step 2B of the framework, the claims do not include additional elements amounting to significantly more than the abstract idea. As noted above, claim 1 includes various elements that are not directed to the abstract idea under Step 2A Prong One of the framework. These additional elements include a memory, processor-executable program code, a processing unit, user interface. Examiner submits that the additional elements do not amount to significantly more than the abstract idea because these elements are generic computing elements performing generic computing functions and amount to mere instructions to apply the abstract idea on a computer under MPEP 2106.05(f) and/or recite generic computer structure that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry.
The “automatically display the explanation field parameters on the change status pop up window” fail to change the function of the display in a meaningful way that goes beyond a general link to display technology or beyond generic and routine display functions for displaying information.
Further, looking at the additional elements as an ordered combination adds nothing that is not already present when looking at the additional elements individually. As a result, Claim 1, 11, and 14 do not include additional elements amounting to significantly more than the abstract idea under Step 2B.
In Claim 4,10, and 16 the elements for a free-field receiving values limitations are mere data gathering/data exchange and insignificant extrasolution activities which do not provide significantly more to the abstract idea (See MPEP 2106.05(g)); and these limitations are equivalent to receiving/transmitting data and are well-understood routine and conventional which do not provide significantly more to the abstract idea (See MPEP 2106.05(d)).
As noted above, Claims 2-3 5-7, 9, 11-13, 15, and 17-19 do not include any additional elements beyond those recited with respect to claims 1, 11, and 14. As a result, these claims do not include additional elements amounting to significantly more than the abstract idea under Step 2B for the same reasons as stated above with respect to claim 1, 11, and 14.
Accordingly, Claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Schubert (20100146427) in view of Jafari (20220215329)
Regarding Claim 1, Schubert discloses:
A system comprising: a memory storing processor-executable program code; and a processing unit to execute the processor-executable program code to cause the system to (0010 - machine-readable medium, instructions, computers, memory)
select an explanation scenario from a plurality of explanation scenarios, wherein each explanation scenario includes one or more configurable explanation field parameters; (Figure 4, 0031 – the message explaining the reason for the task creation (ie. “help me with this subtask” “urgent”) (explanation scenarios); each of the value fields for the task is a configurable explanation field parameter)
configure each explanation field parameter for the selected explanation scenario, wherein configuration defines how one or more explanation fields and respective one or more explanation field parameters are displayed on a change status window of a user interface display; (Figure 4- setting visibility right configurations for each of the fields representing the parameters; the window is interpreted as “change status window” because restrictions can be changed by “set all rights to” or individual restrictions (0024))
apply the configured explanation scenario to at least one process in a process list, wherein the configured explanation scenario is independent of any process in the process list; (0023-The selected task may be a task selected from a workflow (and/or worklist) of tasks, such as tasks associated with a workflow management system)
and automatically display the explanation field parameters on the change status window based on the applied configured explanation scenario and in response to a request to change a status of the at least one process (Figure 4, 0017- window displayed to different user after user requests to change the configurations of a parameter and requests information from a different user; window also sent back to the user;
0017 - The invitees may be presented via a user interface with the same form that the original task owner was presented with; however, the invitees may be presented with portions of the information (e.g., a form presented at the user interface) hidden, restricted, not editable, and the like. Furthermore, the original task owner may decide whether to have the task returned (e.g., in a task inbox) when the invitee provides information (e.g., in the case or the order approval above, the invitee may add information to the form presented at the user interface, and then the updated the form to the original task owner's inbox)
Schubert does not explicitly state a “pop up window”. Jafari, in analogous art, discloses a pop-up window on a dashboard (0049- the user may select the new task button or otherwise select a task to edit, causing the dashboard to open a window to create a new task or edit an existing task.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Schubert’s window to include Jafari’s pop up window, since the claimed invention is merely a combination of old elements, and in the 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.
Regarding Claim 2, Schubert discloses: The system of claim 1, wherein the configurable explanation field parameters are linked to at least one of a status change code and a status change free-form field. (under BRI- “status change” indicates the visibility of the parameters are changed; Figure 4 – the inputted values for each of the parameters (free form fields))
Regarding Claim 3, Schubert discloses: The system of claim 2. Schubert does not explicitly state; Jafari discloses: wherein the at least one of the status change codes are pre- defined. (0049-0050 – a checkmark (code) task status is linked to task parameters... “In some embodiments, the user may select the new task button or otherwise select a task to edit, causing the dashboard to open a window to create a new task or edit an existing task. FIG. 6 illustrates an embodiment of a task window 350. As shown, the task window 350 includes a task status bar 352 that tracks the status of a task from draft to completion. In the embodiment shown in FIG. 6, the status bar 352 includes indicators for each status, disposed in chronological order as the task moves from creation to completion. As the task moves through a status, a check mark, or some other indicator, may appear in the status indicator associated with the status. Further, the status indicator associated with the current status of the task may be shaded in order to indicate the current status of the task. For example, in the embodiment shown in FIG. 6, the task has been completed, so the “completed” status indicator is shaded (or otherwise visually modified or enhanced) and the status indicators to the left of the “completed” status indicator include check marks....) It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to associate Jafari’s pre-defined status change codes (ie. checkmark status) to Schubert’s task parameters, since the claimed invention is merely a combination of old elements, and in the 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.
Regarding Claim 4, Schubert discloses: The system of claim 2, wherein the status change free-form field receives free-form values. Figure 4 – inputted values for each of the parameters (free form fields))
Regarding Claim 5, Schubert discloses: The system of claim 1, wherein the process list is organized with at least one sub-process for a process and each process is in a level. (0023-The selected task may be a task selected from a workflow (and/or worklist) of tasks, such as tasks associated with a workflow management system) [0031] Form 400 also includes other features, such as a message field to allow embedded messages (e.g., a message stating "help me with this subtask," "hello," "urgent," and so forth); a stay responsible for process field (e.g., the user that delegates the decomposed task maintains control and responsibility for the subtask within the overall workflow) (the workflow is interpreted as the process on a higher level than the subtask(s) or decomposed tasks within the workflow)
Regarding Claim 6, Schubert discloses: The system of claim 5, wherein application of the configured explanation scenario to the process applies the configured explanation scenario to each sub-process dependent on the process. (Figure 4 – all of the fields can be a requested sub-task for an invitee to enter information for a workflow;
0025- a set all rights field (e.g., to set all visibility rights 418A) to, for example, one of the listed restrictions (e.g., writable, read-only, and invisible).
Regarding Claim 7, Schubert discloses: The system of claim 1, wherein the explanation scenario is a pre-existing explanation scenario or a create explanation scenario. (Figure 4, 0031 - (ie. “help me with this subtask” “urgent”) (explanation scenario))
Claims 8-19 stand rejected based on the same citations and rationale as applied to the Claims above.
Regarding Claim 20, Schubert discloses: The system of claim 1 further comprising processor-executable program code to cause the system to:
re-use the explanation scenario by applying the configured explanation scenario to a second process in the process list. (Figure 4, 0023, 0031 – the same message explaining a reason for the task creation (ie. “help me with this subtask” “urgent”) (explanation scenario) could be applied to another task in the workflow)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. [AltContent: rect]
PNG
media_image1.png
91
622
media_image1.png
Greyscale
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT ROSS whose telephone number is (571) 270-1555. The examiner can normally be reached on Monday-Friday 8:00 AM - 5:00 PM E.S.T..
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, Rutao Wu, can be reached on (571) 272-6045. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Scott Ross/
Examiner - Art Unit 3623
/RUTAO WU/Supervisory Patent Examiner, Art Unit 3623