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 5/5/20, Applicant, on 7/31/25, amended claims. Claims 1-20 are pending in this application and have been rejected below.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 5/11/25 and 8/15/25 are being considered by the examiner.
Response to Amendment
Applicant’s amendments are acknowledged.
The 101 rejection is withdrawn for claims 1-8 in light of the amendments, as the claim is now configure the dashboard by moving at least one widget within the dashboard based on the workflow, reconfigure the dashboard by moving the at least one widget within the dashboard based on inputs to the dashboard, aggregate a state of the configured dashboard and the reconfigured dashboard, in response to detection of navigation away from the dashboard within the software application, persist the state to a database via an API of the database and use the state in a subsequent workflow. When viewing the claim as a whole, this is not directed to an abstract idea, and, this when combined with the earlier limitations is viewed as a practical application under step 2a, prong 2, as the claim is improving another technology when viewing all the limitations listed above (See MPEP 2106.05a) and/or is viewed as a using a judicial exception in a meaningful way under MPEP 2106.05(e). Examiner notes this could possibly change depending on 112 issues and subsequent amendments. Similar reasoning also applies to claim 17 which have similar limitations.
Please note claims 9-16 are still rejected under 101 at this time, as the claim encompasses manual operations, but would overcome 101 issues below with an amendment for a computer performing each step.
Please note claims 17-20 also are rejected under 101 for still covering a signal per se, but the rejection would be overcome by reciting “non-transitory” in the preamble.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claims now introduce an “aggregate state”, of both a “configured dashboard and reconfigured dashboard. [0046] does support this as it states “the dashboard state (including any reconfigurations) can be persisted to a database via an API of the database.” However, the claim now ends in “in response to detection of navigation away from the dashboard within the software application, persist the aggregate state to a database via an application programming interface (API) of the database, and use the aggregated state in a subsequent workflow.” It is unclear how the disclosure supports “use” an “aggregated state”, if the aggregated state is allegedly referring to both the original and the second position. Examiner does see [0046] state: “ To minimize database calls, the dashboard state may only be persisted to the database upon navigation changes away from the dashboard” and [0047] states: “Upon making these changes, the locations (pixel positions) of the widgets on the screen may be persisted locally within a browser where the configurable dashboard 500 is displayed. As another example, the locations of the widgets can be persisted in a database (not shown), such as when the user leaves the dashboard.” It appears to Examiner, that the claim is intending to return the dashboard to the “reconfigured dashboard”, not to the “configured dashboard” [or initial dashboard]. For purposes of applying prior art only, this is how the claim is viewed at this time, where it appears the second to last limitation could possibly recite : “aggregating a state of the configured dashboard and the reconfigured dashboard in storage”; and the last limitation would end with “using the reconfigured state in a subsequent workflow.” Applicant is invited to explain how the claim is supported, pursue other amendments to clarify, etc.
Independent Claims 9 and 17 are rejected for the same reasons.
Claims 2-8, 10-16, and 18-20 depend from the independent claims and are rejected for the same reasons.
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 1-20 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 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: how the dashboard is going to be displayed with two different positions simultaneously. It appears to Examiner, based on [0046-0047] as published referenced in the 112a above, that the claim is intending to return the dashboard to the “reconfigured dashboard”, not to the “configured dashboard” [or initial dashboard] at the same time, or not to the initial state in the alternative. For purposes of applying prior art only, this is how the claim is viewed at this time, where the claim is viewed as persisting/saving the dashboard in the “reconfigured” or newer state.
Independent Claims 9 and 17 are rejected for the same reasons.
Claims 2-8, 10-16, and 18-20 depend from the independent claims and are rejected for the same reasons.
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 17-20 are rejected under 35 U.S.C. 101 because the claim(s) 17 does/do not fall within at least one of the four categories of patent eligible subject matter. Claim 17 (and depending claims 18-20) are not directed to a statutory category at step 1, as it is a “storage medium”. This is considered “signal per se.” The broadest reasonable interpretation of a claim drawn to a recording medium typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media, particularly when the specification is silent, or open-ended (as seen in Applicant’s specification, ¶ 0059, 0062, 0070 as published). See MPEP 2106. Therefore, given the broadest reasonable interpretation of the claim in light of the specification, the recited recording medium could be interpreted as a transitory propagating signal per se. As such, the claim is rejected as covering a signal per se, which is not directed towards statutory subject matter. In order to overcome this rejection under 35 U.S.C. 101, a claim drawn to such a recording medium that covers both transitory and non-transitory embodiments may be amended to narrow the claim to cover only statutory embodiments by adding the limitation "non-transitory" in the claim to recite a “computer-readable non-transitory storage medium.” Should the claim 17 be amended to recite “non-transitory,” claim 17 would be directed to an article of manufacture at step 1, which is a statutory category.
Claims 9-16 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 the claimed invention is directed to non-statutory subject matter.
Claims 9-16 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 9 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
“An method comprising:
…
receive a call to execute an activity …, wherein the call comprises an identifier of a workflow,
retrieve … instructions for executing the workflow of the activity …,
configuring the… by moving at least one widget within the dashboard based on the workflow;
… to perform the workflow …,
Reconfiguring the dashboard by moving the at least one widget within the dashboard based on inputs to the dashboard;
Determining an activity is approved based on execution of the workflow;
Aggregating a state of the configured dashboard and the reconfigured dashboard; and
In response to detection of navigation away from the dashboard…, persisting the aggregate state to…, and using the aggregated state in a subsequent workflow.”
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity – managing personal behavior ore relationships or interactions between people (following rules or instructions) as here we are performing an identified/named workflow (e.g. “applying for a loan approval”), recording named workflow and a state of the activity (e.g. pending, progress), determining that additional input is needed, preventing other/further inputs until the needed information (e.g. approval, financial documents from a customer) is provided, upon receiving needed input, continuing the workflow/”business process” and update state of activity (e.g. progressing, completed, etc) with a number of steps in claim 9 encompassing a person executing activity, workflow, moving a widget manually, reconfiguring a display by moving a widget again, determining an activity is approved, storing a dashboard. In summary, the claim somehow never requires a computer so instead appears to encompass a person manually performing a number of the steps. Suggestion: positively recite a computer performing steps of the method to avoid inadvertently having a manual method in many of the steps.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. In particular, the claim 9 recites additional elements that are:
Receiving a call to execute an activity of a Software application via a dashboard, wherein the call comprises an identifier of a workflow;
retrieve executable instructions for executing the workflow of the activity
configuring the dashboard by moving at least one widget within the dashboard based on the workflow;
executing the executable instructions [a person manually operating] to cause the software application “to perform the workflow via the dashboard of the software application,
Reconfiguring the dashboard by moving the at least one widget within the dashboard based on inputs to the dashboard;
Aggregating a state of the configured dashboard and the reconfigured dashboard; and
In response to detection of navigation away from the dashboard…, persisting the aggregate state to a database via an AP of the database, and using the aggregated state in a subsequent workflow.”
(MPEP 2106.05f applies –the claim somehow never applies a computer so instead appears to encompass a person manually performing operations and “apply it [the abstract idea] on a computer”; merely uses a computer as a tool to perform an abstract idea; MPEP 2106.05h “field of use” for combination). An additional element of “storing” data is considered at step 2a, prong 2 and step 2B part of 2106.05f (apply it [abstract idea] on a computer). Suggestion: positively recite a computer performing steps of the method to avoid inadvertently having a manual method in many of the steps.
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 element of a computing system, is treated as 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); MPEP 2106.05h (field of use)). 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.
Should the claim 17 be amended to recite “non-transitory,” claim 17 would be directed to an article of manufacture at step 1, which is a statutory category. Claim 17 recites similar limitations as claim 1 and claim 9 and is rejected for the same reasons at step 2a, prong one, 2a, prong 2, and step 2b. The additional limitations, of “processor”, computer readable storage media, are part of “apply it on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2b. The claim is not patent eligible.
Claims 10 narrow the abstract idea by having different types of user accounts.
Claims 11 narrow the abstract idea by having approval messages communicated to people. There also are additional elements similar to claim 1 of “displaying”, and this is viewed as “field of use” (MPEP 2106.05h).
Claims 12-13 narrow the abstract idea by having approvals and account changes.
Claims 14 narrow the abstract idea by identifying a user. An additional element of “storing” data is considered at step 2a, prong 2 and step 2B part of 2106.05f (apply it [abstract idea] on a computer) as above. At step 2B, “storing” is also considered a conventional computer function (See MPEP 2106.05d - iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306).
Claims 15 narrows the abstract idea by having an expiration time for the task.
Claim 16 narrows the abstract idea by having a user give a “specific” type of input.
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-6, 8-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Scarfutti ‘911 (US 2022/0214911), Konson (US 11,922,510) and Thangeswaran (US 2022/0114224).
Concerning claim 1, Scarfutti ‘911 discloses:
An apparatus (Scarfutti ‘911 – see par 61 – example configuration of enterprise system 60) comprising:
a storage device (Scarfutti ‘911 – see par 61 – system 60 includes at least one memory or memory device that can include a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by one or more processors; The enterprise system 60 may also include one or more data storage elements for storing and providing data for use in such services, such as data storage for storing client data 68); and
a processor configured (Scarfutti ‘911 – see par 61 – system 60 includes at least one memory or memory device that can include a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by one or more processors) to:
receive, a call to execute an activity of a software application via a dashboard, wherein the call comprises an identifier of a workflow (Scarfutti ‘911 – see par 57 - The application development environment 12 also includes or is provided with (e.g., via an application programming interface, (API)), a development environment interface 38, As shown in FIG. 2, the development environment interface 38 can connect to the communication network 14 to send/receive data and communications to/from the application testing environment 10; see par 78 – management service an interface with a designer client 135 to enable process workflows to be created, as well as other clients 137 to provide dashboards to certain users; see par 90 - Referring now to FIG. 20, a sub-process task 198 is shown. A sub-process task 198 is a task that invokes another subprocess. The routing sub-layer 144 can contain a BPMN call activity that immediately follows an intermediate message catch event, and immediately precedes an event-based gateway that catches messages from the sub-process. The call activity can also dictate that the messages should correspond to end message events in the sub-process).
Scarfutti discloses the “calling” is for a “sub-process” (See par 90), but it does not explicitly refer to an API in that paragraph. Scarfutti also discloses having bitemporal modeling, to handle historical data along two different timelines, so one can “rewind information” as it was recorded to circle back to previous tasks and previous states (See par 80) where there are names for sub-processes (See par 96- a, b, c; topics xa1, xa2, xa3), and where the bitemporal support allows querying of “quantum” properties that include “unique name that identifies… workflow, task, etc” (See par 103, 106).
Konson also discloses:
receive, via an application programming interface, “a call” to execute an activity of a software application via a dashboard, wherein the call comprises an identifier of a workflow (Konson – see col. 6, lines 19-27 - It displays the status of each application to underwriting and sales teams, and has a built in workflow checklist and notes repository. This service makes API calls to the External API service to retrieve necessary data for underwriting. It also makes API calls to Equifax and TransUnion; See Col. 24, lines 40-50 - The data that is fed to the tile 1305, supporting data and/or raw data may be accessed by selecting an information icon that will display the documents, API-collected information, and any other available data for the user; col. 46, lines 23-39 - FIG. 22 – overall process; When the underwriter initiates the data collection 3420, the system processes the request and sends data requests 3424 to various API programs to search for the data required. The API programs search for requested data and information 3428 and return the data to the system to be automatically updated in the application 3432. The underwriter will be able to quickly see the progress by viewing the loan dashboard 1300 of FIG. 13).
Scarfutti ‘911 and Konson disclose:
retrieve executable instructions for executing the workflow of the activity from an instruction database ([0026] as published - The workflow process may be performed by the host platform when a user, software program, system, etc., needs approval to take an action such as to modify a credit limit, change user entitlements, make payments, etc.) The workflow process may be managed by a workflow module within the host platform, which controls the process and ensures that only the necessary users are able to interact with the process at the correct times and in the correct order.
Scarfutti ‘911 – See par 59, FIG. 2 - While not delineated in FIG. 2, the application development environment 12 (and any of its devices, servers, databases, etc.) includes at least one memory or memory device that can include a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by the one or more processors. see par 71 – The platform 22 in the configuration shown in FIG. 5 includes a workflow manager 100 that uses a management service 102 to determine and display currently executing workflows as well as to define workflows as a graph. The management service 102 is connected to a workflow graph database 106. See par 78, FIG. 6 – technology stack for implement business process platform 22; The workflow orchestration layer 130 includes one or more servers to provide the management service 102, the navigation service 108, the workflow graph database 106 coupled to the navigation service 108, and a decision service 132. The decision service 132 is provided as an interface with a decision client 134, for example, a user that interfaces with the business process platform 22 to execute a task such as an approval),
Scarfutti discloses having a dashboard user interface 270 for designing a business process workflow (See par 114, FIG. 31-32, see user interfaces 260, 270) where platform 22 can store workflow as a graph and employ microservices according to the implied state of the graph (See par 114).
Konson discloses:
configuring the dashboard by moving at least one widget within the dashboard based on the workflow (Konson – see Col. 21, lines 43-64 – FIG. 13, loan dashboard 1300 contains task management for the user to interact with to perform functions associated with their role; One of these features is a tile display area 1350 including a series of customizable tiles (e.g., 1305A-1305L). A tile (generally referred to as 1305) is displayed on the screen as any shape, generally two-dimensional shapes but three dimensional may be used. Col. 22, lines 4-15 - The tile display area 1350 may be implemented as a tile or widget control (e.g., such as an Angularjs widget control like Angular gridster) to enable tiles to be placed on, drawn on, removed from, and reorganized on the tile display area 1350; Col. 23, lines 40-60 - For example, in some embodiments each tile may be clicked and dragged to any position within the tile display area 1350 provided for the tiles. In this manner, tiles 1305 can be rearranged or shuffled; )
Scarfutti and Konson disclose:
execute the executable instructions to cause the software application to perform the workflow via a plurality of screens of the software application (Scarfutti – See par 48, FIG. 1 - The application development environment 12 includes or is otherwise coupled to one or more repositories or other data storage elements for storing application build data 18. See par 49 - As used herein a “build” may refer to the process of creating an application program for a software release, by taking all the relevant source code files and compiling them and then creating build artifacts, such as binaries or executable program(s), etc. “Build data” may therefore refer to any files or other data associated with a build. see par 99 - FIG. 26 provides a screen shot of a user interface 240 for performing a service task configuration. The user interface 240 therefore can be used to integrate service tasks with the message broker 146 by providing a design tool for the business process and to onboard functionality to limit what the tenant can do with that service task;
see also Konson – see FIG. 3, col. 24, lines 40-50 - the tiles 1305 in the graphical user interface are continuously active and updating based on the collection of information with processing being performed in the background. The data that is fed to the tile 1305, supporting data and/or raw data may be accessed by selecting an information icon that will display the documents, API-collected information, and any other available data for the user. see col. 24, lines 60-67, Col. 25, lines 1-8 - When an underwriter clicks on a request ID (prospective borrower ID) (e.g., using the interface of FIG. 12E or 12F) the system shows the loan dashboard 1300 shown in FIG. 13, which, again, displays various tiles (illustrated as 1305A-1305L) to the underwriter; The systems guide the underwriter on where to look and where to take action.)
Scarfutti discloses having a workflow management and a management service to display executing workflows as well as to define workflows (See par 71).
reconfigure the dashboard by moving the at least one widget within the dashboard based on inputs to the dashboard (Konson – see col. 24, lines 12-25 - The user may want to move individual tiles for any number of reasons, including, but not limited to, focusing on specific data, developing a workflow, organizing by importance for certain types of loans, or customizing a display for a particular loan. The tiles 1305 may be independently moved by using a touchscreen, a mouse or other user input tool connected to the computer system to select and drag the tile to the desired location within the defined field. If the tile 1305 is moved to an area on the defined field that is currently occupied by another tile, the tiles 1305 will shift such that the selected tile is positioned in the location selected by the user, and the other tiles 1305 will move around that selected tile. For example, the tile may be selected by placing the mouse cursor at any location on the tile face or edge.);
determining an activity is approved based on execution of the workflow (Scarfutti – see par 111 - FIG. 30d illustrates another process workflow as a graph, in this example including distribution, issuance, and approval for a structured notes workflow ; see par 113, FIG. 31 - This allows the topic associate with a node to imply the state of the workflow at any given time in the process, while enabling not linear workflows to be implemented (e.g., to obtain multiple signature or contributions to a document in the workflow;
see also Konson – See col. 9, lines 30-35 - The work flow management systems for underwriting approval described herein may be accomplished through manual underwriter data entry, through an automated system, or through a combination of manual and automated systems. See col. 19, lines 56-67 - Referring now to FIG. 17, a workflow process reporting section 1340 of the loan dashboard 1300 shows what state 1704, 1712, 1720, 1732, 1744 the application is in, and the time length 1708, 1716, 1728, 1740, 1748 that the application has been in that state. An application can bump between the sales department for more documentation or underwriting for analysis. Each bump to the other team registers as another bump in the band to show how many times an application went back and forth. See col. 20, lines 49-54 - Once the underwriter has made a decision on the loan application, and either approved or disapproved the loan application, the workflow process reporting section 1340 will indicate that the application is in the “Decisioned” state 1744; see col. 23, lines 61-67, Col. 24, lines 1-11 - The “red-edge tiles” may be added to or replace tiles 1305 being displayed in the tile display area 1350. In an embodiment where red-tiles automatically replace existing tiles on the tile display area 1350, the system preferably removes tiles that do not need further attention (e.g., green tiles) to make room for the tiles being newly displayed);
aggregate a state of the configured dashboard and the reconfigured dashboard (Konson – see col. 25, lines 9-13 - Tiles can be moved, ordered, removed, or added, for best information flow based on underwriter's preference).
Konson discloses that users can move tiles and “customize a display for a particular loan” (See col. 24, lines 12-25) and that tiles in the GUI are updating based on API-collected information, and that documentation is maintained within a database that the computer system accesses and stores (See col. 6, col. 24 lines 40-50, col. 46 lines 23-39).
Thangeswaran discloses:
in response to detection of navigation away from the dashboard within the software application, persist the aggregate state to a database via an application programming interface (API) of the database, and use the aggregated state in a subsequent workflow (Thangeswaran – See par 100 - When a widget is added or removed using UI features (using an interface to add/remove widgets) such as that provided by core UI framework 314, the dashboard management system may update the UI and save the current state of the dashboard to a database. In the platform when a widget is added or removed using the UI features (there will be interface to add/remove cards) the DMS framework will update the UI and saves the current state of the dashboard to the database. If a new widget is added, the framework will show the widget in the UI and also make an API call to update the backend for the same; see par 106 - The dashboard framework 316 may include facilities to create and publish dashboards, render dashboards, add/remove widgets, manage layout (e.g., customize), copy dashboards, and to share dashboards and/or widgets. see par 141 - The state may be cached in different categories such as, for example, widget data, widget filter settings and widget positions (e.g., from Packery). The Packery positions of widgets, for example, may be read and retained at the user level, so that whenever the user logs in again, the same layout can be shown. In some embodiments, a caching library in the portal or in the dashboard SDK may facilitate caching dashboard and widgets at multiple levels. The cached state may include the set of widgets in the dashboard, a state of the data displayed in the dashboard, and the arrangement of the widgets.).
Scarfutti and Konson are analogous art as they are directed to performing workflow/activities for approvals of financials/lending (See Scarfutti Abstract, par 53; Konson Abstract). Scarfutti, Konson, and Thangeswaran are analogous art as they are directed to having dashboards with information (Scarfutti par 114; Konson Abstract; Thangeswaran Abstract, par 42). 1) Scarfutti discloses having a dashboard user interface 270 for designing a business process workflow (See par 114, FIG. 31-32, see user interfaces 260, 270) where platform 22 can store workflow as a graph and employ microservices according to the implied state of the graph (See par 114). Scarfutti discloses having a workflow management and a management service to display executing workflows as well as to define workflows (See par 71). Konson improves upon Scarfutti by reorganizing or dragging widgets or tiles in the dashboard (col. 21-23) and customizing a display by moving tiles and dragging tiles to different locations (See col. 24). One of ordinary skill in the art would be motivated to further include APIs and calls for performing workflow/tasks and dragging/moving tiles of a display dashboard to efficiently improve upon the APIs design of workflow in Scarfutti. 2) Scarfutti discloses the “calling” is for a “sub-process” (See par 90), but it does not explicitly refer to an API in that paragraph. Scarfutti also discloses having bitemporal modeling, to handle historical data along two different timelines, so one can “rewind information” as it was recorded to circle back to previous tasks and previous states (See par 80) where there are names for sub-processes (See par 96- a, b, c; topics xa1, xa2, xa3), and where the bitemporal support allows querying of “quantum” properties that include “unique name that identifies… workflow, task, etc” (See par 103, 106). Konson improves upon Scarfutti by disclosing having APIs, calls for workflow (See col. 6, 24, 46) and that users can move tiles and “customize a display for a particular loan” (Col. 24, liens 12-25). Thangeswaran improves upon Konson and Scarfutti by disclosing saving the current state of the dashboard to a database, making API calls to update database/backend (par 100) and using same layout next time user “logs in again” using same arrangement from cached state of widgets (See par 106). One of ordinary skill in the art would be motivated to further include customized displays for particular loans in Konson and using API calls to update database/backend for next time user logs in again using state of widgets to efficiently improve upon the APIs and “currently executing workflows” and having a design of workflows in Scarfutti.
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 workflow tasks relating to client’s financial data (See Abstract, par 64) in Scarfutti, to further include APIs and calls for performing workflow/tasks where a queue of tasks is waiting to be assigned as well as tracked as disclosed in Greenberg, 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, Scarfutti, Konson, and Thangeswaran disclose:
A method (Scarfutti par 36 - Certain example systems and methods described herein are able to execute dynamic routing of messages. In one aspect, there is provided a device for executing a dynamic routing service. The device includes a processor, a communications module coupled to the processor, and a memory coupled to the processor. The memory stores computer executable instructions that when executed by the processor cause the processor to i) subscribe to ingress a first topic for a current task in a process workflow and ii) receive a data object for the current task) comprising:
The remaining limitations are similar to claim 1 above. Claim 9 is rejected for the same reasons.
It would be obvious to combine Scarfutti, Konson, and Thangeswaran for the same reasons as claim 1.
Concerning independent claim 17, Scarfutti, Konson, and Thangeswaran disclose:
A computer-readable storage medium comprising instructions which when executed by a processor cause a computer to perform a method comprising (Scarfutti ‘911 – See par 36 – method; see par 38 – non-transitory computer readable medium; see par 61 – system 60 includes at least one memory or memory device that can include a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by one or more processors; The enterprise system 60 may also include one or more data storage elements for storing and providing data for use in such services, such as data storage for storing client data 68):
The remaining limitations are similar to claim 1 above. Claim 17 is rejected for the same reasons.
Concerning claim 2, 10, and 18, Scarfutti, Konson, and Thangeswaran disclose:
The apparatus of claim 1, wherein the processor is configured to execute the workflow via at least two different dashboards of the software application (Scarfutti par 88 – named service configuration for a task is permissioned for a tenant; par 114 - It can be appreciated that the dashboard user interfaces 260, 270 can also provide other dashboards, such as a workflow dashboard showing multiple workflows and sub-workflows with administrative tools and the ability to publish a workflow once designed.
See also Konson Col. 12, lines 48-55 - In one exemplary embodiment of the underwriting system described herein a user, such as a supervisor, who manages the workflows of other users (disclosing a 1st dashboard) can set up their display to include metrics on an associated set of other uses (e.g., all users who report to the supervisor), in addition to showing their own user specific workflow metrics (disclosing a 2nd dashboard); Col. 18, lines 21-40 - FIG. 13 shows a graphical user interface acting as a loan dashboard 1300 that displays information associated with a particular loan (also disclosing a 1st dashboard); see col. 19, lines 44-55 - Underwriter role 1612 is used to determine approval band permissions (example, Senior Credit Officer can approve any size offer). The underwriter role 1612 in the example shown in FIG. 16 is “SCO” 1616, which stands for “Senior Credit Officer.” Approval band permissions may be programmed into the system such that some functions or actions of the user are limited based on the criteria established for the approval band. For example, while a senior credit officer may be able to access every tile and make and save changes to the application, the system may be programmed to allow other roles, such as a junior credit officer, to only view tiles, but make no changes that can be saved within the system).
It would be obvious to combine Scarfutti, Konson, and Thangeswaran for the same reasons as claim 1. In addition, Scarfutti discloses multiple “dashboards” (par 114) and having named service configurations “permissioned” for a tenant (See par 88). Konson improves upon Scarfutti by having various dashboards based on roles/loans.
Concerning claim 3, 11, and 19, Scarfutti, Konson, and Thangeswaran disclose:
The apparatus of claim 1, wherein the processor is configured to:
generate a message associated with the activity (Scarfutti par 83 - The navigation service 108 and the routing service 110 operate using the underlying message broker 146 to perform task-based messaging and routing on the business process platform 22 to implement a process workflow that is based on the process workflow being designed and stored as a graph.); and
display the message via the dashboard of the software application and an approval function for an approval of the activity (Scarfutti par 110 - FIGS. 30a-30c illustrate a process workflow as a graph. As shown in FIG. 30a, the process includes a number of nodes that proceed through the business process and can include multiple sub-workflows that can each be constructed in a similar way. Various communication nodes are illustrated to indicate when the process passes between different parties by way of, for example, an email. The sub-workflows are shown in FIGS. 30b and 30c (showing two different people putting in an “input” amount in response to message/communication/email). par 111 - . 30d illustrates another process workflow as a graph, in this example including distribution, issuance, and approval for a structured notes workflow. The process in this example includes approval of the structure and intent to sell, distributor selection and routing, document drafting (prospectus, etc.), and final approval;
Konson – see col. 12, lines 13-28 - The display screen in FIG. 12A includes a Title 12015. In the example shown, this title 12015 is “My Queue.” Beneath or beside the title 12015, an alert banner (not shown) may be displayed that provides system messages to the user. Such alerts may include text or icons alerting the user that there are application(s) older than a certain number of days (for example, the company may specify in the system to alert when applications are over two weeks old), or that an application is ready for final underwriting, or that new information has been collected that requires the underwriters attention, or if a tile has changed status)
Concerning claim 4, 12, and 20, Scarfutti, Konson, and Thangeswaran disclose:
The apparatus of claim 3, wherein the processor is configured to detect approval of the activity via the dashboard (Scarfutti – see par 111 - FIG. 30d illustrates another process workflow as a graph, in this example including distribution, issuance, and approval for a structured notes workflow;
Konson – see col. 12, lines 13-28 - The display screen in FIG. 12A includes a Title 12015. In the example shown, this title 12015 is “My Queue.” Beneath or beside the title 12015, an alert banner (not shown) may be displayed that provides system messages to the user. Such alerts may include text or icons alerting the user that there are application(s) older than a certain number of days (for example, the company may specify in the system to alert when applications are over two weeks old), or that an application is ready for final underwriting, or that new information has been collected that requires the underwriters attention, or if a tile has changed status); and
in response to the detection, determine that the activity is approved ([0043] as published - In some embodiments, the workflow module 122 can be used for Approval capabilities within the platform. For example, the workflows may include user inputs being received via one or more user interfaces (user accounts) and may require specific inputs (e.g., box checks, signatures, values entered, etc.). The workflow module 122 can ensure that such steps are carried out on the screens that are allowed. The workflow module 122 can support different operations within the platform on both the employee side and the customer side
Scarfutti ‘911 discloses the limitation based on broadest reasonable interpretation in light of the specification – See par 112 - By utilizing a graph structure for the business process workflow, the topic (issued via the distribution cluster 112) implies the state and thus processes do need to be linear. This graphical representation also permits graphs to be chained together, allowing for sub-flows as discussed above. Documents in the process can pass through the workflow via the graph edges to microservices and users that receive and/or interact with the document (e.g., to add a signature).; see par 113, FIG. 31 - This allows the topic associate with a node to imply the state of the workflow at any given time in the process, while enabling not linear workflows to be implemented (e.g., to obtain multiple signature or contributions to a document in the workflow).
Konson – see FIG. 17, Col. 20, lines 49-59 - Once the underwriter has made a decision on the loan application, and either approved or disapproved the loan application, the workflow process reporting section 1340 will indicate that the application is in the “Decisioned” state 1744.).
It would be obvious to combine Scarfutti and Konson and Thangeswaran for the same reasons as claim 1.
Concerning claim 5 and 13, Scarfutti, Konson, and Thangeswaran disclose:
The apparatus of claim 1, wherein the processor is configured to execute one or more changes within the software application based on the execution of the activity within the software application (Scarfutti – see par 116 - At block 306 the workflow state change(s) can also be published with a topic for the current workflow task. This implies the state of the state machine implemented by the business process platform 22 and allows operations associated with the workflow to be controlled and implemented, e.g., having a document signed, verifying a payment, etc.
Konson col. 20, lines 4-23 - n the example shown in FIG. 17, this is done by the “Qualified” 1704 state being highlighted in a color such as blue. Once the potential borrower submits the application for approval, the workflow process reporting section 1340 will indicate that the application is in the “Applied” state 1712. In the example shown in FIG. 17, this would be represented by the “Applied” state 1712 being highlighted blue, and the “Qualified” state 1704 no longer being highlighted in blue. The system may be programmed to either revert the “Qualified” state 1704 to the original color or to another color indicative of completed workflow sections; col. 39, lines 30-49 - As with any other changes to the risk calculations herein, this also causes the corresponding tiles (and details pages) in various portions of the dashboard 1300 to be updated (in real-time) as well, such as by updating the Offers and Risk modifiers. If the underwriter moves the Counter-Offer sliding control 3104 to the left (thereby canceling the counter offer), the counter offer automatically increases the current cumulative risk modifier by 20%, and the maximum loan amounts, offers and risks are recalculated.).
It would be obvious to combine Scarfutti, Konson, and Thangeswaran for the same reasons as claim 1.
Concerning claim 6 and 14, Scarfutti discloses having a specialized task 182 relying on a manual decision 184 from a user through the decision client 134 (See par 86).
Konson discloses:
The apparatus of claim 1, wherein the processor is configured to store an identifier of the activity within the queue (Konson col. 5, lines 5-13 - A “Request ID” or “Request ID” is a system generated or user generated identification for an individual loan application. This may be either numerical, alpha-numerical, or any type of identification that the system is programmed to accept. This may be referred to throughout as an identification number, loan identification number, or application number for which an underwriting decision is made or is to be made; see col. 24, lines 60-67 - When an underwriter clicks on a request ID (prospective borrower ID) (e.g., using the interface of FIG. 12E or 12F) the system shows the loan dashboard 1300 shown in FIG. 13, which, again, displays various tiles (illustrated as 1305A-1305L) to the underwriter)
It would be obvious to combine Scarfutti and Greenberg for the same reasons as claim 1. In addition, Scarfutti discloses having a specialized task 182 relying on a manual decision 184 from a user through the decision client 134 (See par 86). Konson improves upon Scarfutti by disclosing having activities with an identifier for the loan/borrower.
Concerning claim 7 and 15, Scarfutti discloses in FIG. 14 having a timer boundary event, and can result in an escalation, and the timer resulting in a reminder is relied upon in claim 1 (See par 86, FIG. 14-15).
Thangeswaran discloses:
The apparatus of claim 6, wherein the processor is further configured to execute a time-to-live job for the activity based on a ti