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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's RCE submission filed on 12/29/25, to enter the claims of 10/28/25, has been entered.
Notice to Applicant
The following is a Non-Final Office action. In response to Examiner’s Final Rejection of 9/16/25, Applicant, on 10/28/25, amended claims. Claims 1-6, 8-14, and 16-22 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The 101 rejection is withdrawn for claims 1-6, 8-14, and 16-22, as the claim is now: 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, reconfigure pixel locations of a plurality of widgets on the dashboard by moving the plurality of widgets based on inputs to the dashboard, detect navigation away from the reconfigured dashboard by the software application, persist a state of the reconfigured pixel locations of the plurality of widgets to a database via an application programming interface (API) of the database after navigation away from the reconfigured dashboard. 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). Similar reasoning also applies to independent claims 9 and 17 which have similar limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 21 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 21 is new, but recites limitations now also present in claim 1, from which it depends from. Claim 1 recites: “persist a state of the reconfigured pixel locations of the plurality of widgets to a database via an application programming interface (API) of the database after navigation away from the reconfigured dashboard.” Claim 21 recites the same limitations of “to persist the state of the reconfigured pixel locations of the plurality of widgets to the database after navigation away from the reconfigured dashboard is detected.”
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 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 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 discloses:
reconfigure pixel locations of a plurality of widgets on the dashboard by moving the plurality of widgets based on inputs to the dashboard (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 (tiles disclose “widgets”) 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;
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.);
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:
detect navigation away from the reconfigured dashboard by the software application (Thangeswaran 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.),
persist a state of the reconfigured pixel locations of the plurality of widgets to a database via an application programming interface (API) of the database after navigation away from the reconfigured dashboard (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 – Col. 11, lines 21-36, FIG. 12a - an overview graphic interface display screen 12000 is shown which may be referred to as an “underwriter dashboard” and is referred to as such throughout. 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 – Col. 11, lines 21-36, FIG. 12a - an overview graphic interface display screen 12000 is shown which may be referred to as an “underwriter dashboard” and is referred to as such throughout. 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, determine approval of the activity ([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 changes within the software application based on 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 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 1, wherein the processor is configured to execute a time-to-live job for the activity based on a timing parameter associated with the workflow and store… the time-to-live job within the queue (Thangeswaran – see par 101 - Embodiments enable setting an expiry to a dashboard widget. In cases where there is a requirement to show a widget for only a certain time and discontinue showing after some time, an expiry date/time can be set against the widget. Once the widget expires, it may be removed from a specific dashboard without any additional effort by the user. For example, in some web applications there may be a need to show information about an event coming up in a future date and to use a widget to direct the user's attention to that event. In such cases, the user may add an expiry to the widget, so that once the event is over the widget can be removed from the dashboard.)
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 a 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. In addition, 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 improves upon Scarfutti and Konson by disclosing having expiration for a widget within the dashboard for a certain event. One of ordinary skill in the art would be motivated to further include expiration for an event to efficiently improve upon the APIs and “currently executing workflows” with workflow states in Scarfutti and the dashboard in Konson.
Concerning claim 8 and 16, Scarfutti, Konson, and Thangeswaran disclose:
The apparatus of claim 1, wherein the processor is configured to enable a specific type of input on the dashboard based on the executable instructions (Scarfutti see par 78 - 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; see par 86 - FIG. 13 illustrates a decision client task that enables a specialized task 182 to be defined that relies on a manual decision 184 from a user through the decision client 134 (interfaced to the decision service 132). For example, the routing sub-layer 144 can contain a BPMN user task that immediately follows an intermediate message event (throw or catch), immediately precedes an XOR gateway that immediately precedes message throw events (intermediate or end); FIG. 14 illustrates another type of decision client that includes a timer boundary event 186 (interrupting or non-interrupting) that can be associated with a service level agreement (SLA), for example. The interrupting timer on a decision service 132 deactivates the XOR gateway and enables the alternative path (e.g., for an escalation) as shown in FIG. 15, and the non-interrupting timer on the decision service 132 keeps the XOR gateway activated as shown in FIG. 16 (e.g., for initiating a reminder).) and prevent other types of inputs (Applicant’s [0043] as published states “ 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”
Konson Col. 18, lines 53-67, col. 19, lines 1-11 - FIG. 15 represents an enlarged view of the overall status/progress indicator and alert banner 1320 of the loan dashboard 1300. For the example shown in FIG. 15, the status/progress indicator 1504 is displayed as a stoplight, and is referred to throughout as such. In this embodiment, the status indicator stoplight 1504 shows if the application is all good (green), has minor issues (orange), or has major issues (red). In the example shown in FIG. 15, “Legal Review” 1512 and “Cuts” 1516 parameters are highlighted next to the “Check” label 1508 in a manner indicating that the underwriter must check these tiles before the application can move forward in the approval process. Such an indication may be accomplished by the program highlighting the “Legal Review” 1512 and “Cuts” 1516 parameters in a pre-programmed color, such as red. The “Personal” 1520 parameter in the example is highlighted a different color (such as yellow) to indicate a different action is required by the underwriter. Col. 19, lines 44-67 - 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; 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 tiles (1305A-1305L) in FIG. 13 are color coded for quick recognition by user, for example, red means that the underwriter needs to look at this information in more depth. The data is structured and everything is available to the underwriters digitally. The systems guide the underwriter on where to look and where to take action; see FIG. 19A, Col. 40, lines 51-63 - When the user selects the ACTION tile 3140, the view shown in FIG. 19D is displayed. This provides the user a sidebar 3182 menu of all available actions available to the user. Examples of available actions are shown as “Soft Pull Transunion” 3184, “Generate Approval Model” 3186, “Export” 3188, “Reset” 3190, and “Hard Reset” 3192. ).
It would be obvious to combine Scarfutti, Konson, and Thangeswaran for the same reasons as claim 1.
Concerning claim 21, Scarfutti, Konson, and Thangeswaran disclose:
The apparatus of claim 1, wherein the processor is configured to persist the state of the reconfigured pixel locations of the plurality of widgets to the database after navigation away from the reconfigured dashboard is detected (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).
It would be obvious to combine Scarfutti, Konson, and Thangeswaran for the same reasons as claim 1.
Concerning claim 22, Scarfutti, Konson, and Thangeswaran discloses:
Konson – see col. 20, lines 60-67 - Returning to the loan dashboard of FIG. 13, a tile display area 1350 displays a selectable set of the tiles (1305A-1305L).). 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).
The apparatus of claim 1, wherein the processor is configured to reconfigure a type of content shown within a widget on the dashboard and persist the reconfigured type of content to the database after navigation away from the reconfigured dashboard is detected (Thangeswaran see par 123, 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. The state may also include active context in the dashboard).
It would be obvious to combine Scarfutti, Konson, and Thangeswaran for the same reasons as claim 1.
Response to Arguments
Applicant's arguments filed 10/28/25 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
The 103 rejections are moot in view of the new rejections necessitated by the amendments. Applicant’s arguments appear to use the previous claim language of 7/31/25 regarding “aggregated” which was then removed on 10/28/2025. Remarks, pages 12-13. To extent arguments may be applicable to the current claims of 10/28/2025, Applicant then argues Thangeswaran is adding/removing UI features and saving a current state of the dashboard in paragraph 100. Remarks, pages 12-13. None of the arguments address paragraph 141 of Thangeswaran which discloses that positions of widgets and widget data is stored and retained, so that whenever the user logs in again, the same layout can be shown as well as using a cached state of arrangement of the widgets.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Coupe can be reached at 571-270-3614. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619
Prosecution Insights