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 submission filed on 2/17/26 has been entered.
Notice to Applicant
The following is a Non-Final Office action. In response to Examiner’s Final Rejection of 11/18/26, Applicant, on 2/17/26, amended claims. Claims 1-2, 4-5, 7-14, 16-17, 19-28 are pending in this application and have been rejected below.
Claim Objections
Claim 24 is objected to because of the following informalities: it recites “transaction state h”. Appropriate correction is required – it appears the “h” is a typographical error. It appears the claim should recite “transaction state [[h]]”.
Reasons for Subject Matter Eligibility under 35 USC 101
The claim 1 overcomes the 101 rejections based on Applicant’s remarks (pages 14-16) and because the claim is now: user interface including one or more integrated visual overlay elements positioned in proximity… and then generate a web-based user interface form based upon the state of the guided workflow transaction path, the web-based user interface form including visual overlay elements positioned in proximity to corresponding user interface elements according to the guided workflow transaction path and updating the state of the guided workflow transaction path upon processing the transaction. When viewing the claim as a whole, 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). The same reasons also apply to independent claim 13 which has similar limitations, and the remaining claims depend from these.
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-2, 4-5, 7-14, 16-17, 19-28 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. Claim 1 now recites “generate a web-based user interface form based upon the state of the guided workflow transaction path by reconstructing the guided workflow transaction path using the overlay configuration files without rebuilding the underlying web application, the web-based user interface form comprising the captured data elements from the retrieved data structure”. Examiner is unable to find sufficient 112(a) support for this limitation. The closest Examiner can find is [0005] as published stating “a client representative does not need to leave the guided service framework, because the system provides user interface overlay configuration files by leveraging existing web application flows. This allows developers and software personnel to build once for customer and employee—increasing speed to market, reducing internal applications (maintenance, support), and obviating the need to obtain associate mindshare for new integrations introduced to associates or other digital pathways.” However, this portion does not explain what the “reconstruction” of the guided workflow transaction path may be, let alone “without rebuilding” underlying web application. [0039] as published states “Another important feature of the guided workflow transaction path is the ability to maintain and track a current state of the transaction based upon, e.g., the node in the guided workflow transaction path which is currently being processed by module 106b-so that the transaction can be saved and continued to completion on any number of different devices. In some embodiments, guided workflow module 106b maintains a record of the current state of the transaction path (including but not limited to completed nodes, incomplete nodes, and currently active node) so when the guided workflow transaction is continued on another device, module 106b can quickly configure the user interface and application functions to continue from the point at which the transaction was most recently updated or accessed.” Perhaps this is more the portion the claim limitation is intended to be based upon, where the “without rebuilding” is somehow referring to “configure the user interface and application functions to continue from the point at which the transaction was most recently updated or accessed.” Examiner is not sure how the limitation is supported nor what the odd “reconstruction” that is at the same time “without rebuilding.” Applicant is invited to explain this, point to support, and/or amend the claim as needed to have sufficient 112(a) support.
Claim 13 is rejected for reciting the same limitations.
Claims 2, 4-5, 7-12, 14, 16-17, 19-28 depend from claims 1 and 13 are rejected for the same reasons.
Claim 11 and 23 now recite: “updating the state of the guided workflow transaction path as completed without modifying the underlying client service software application”. It is unclear how the application supports the negative limitation, or what is being referred to here. Applicant is invited to explain this, point to support, and/or amend the claim as needed to have sufficient 112(a) support.
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-2, 4-5, 7-14, 16-17, 19-28 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.
Claim 1 recites the terms of “reconstructing and “rebuilding” in “generate a web-based user interface form based upon the state of the guided workflow transaction path by reconstructing the guided workflow transaction path using the overlay configuration files without rebuilding the underlying web application, the web-based user interface form comprising the captured data elements from the retrieved data structure” in claim 1 are relative terms which renders the claim indefinite. The earlier limitation in the claim (lines 8-9) states that “including displaying a user interface associated with the guided workflow transaction path on the first client computing device, wherein the user interface corresponds to an existing web application flow.” Thus, the claim starts with workflow transaction path being displayed corresponding to the “web application” flow. Then, later in the claim, the term “reconstructing the guided workflow transaction path… without rebuilding the underlying web application” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. It is unclear what exactly the claim is referring to, that satisfies both “reconstructing” the workflow transaction path (which on lines 8-9 is corresponding to “web application”), but also “without rebuilding” a web application. These are logically opposite at the end of the claim and Examiner is unable to have any idea what Applicant subjectively believes this to include or exclude. In addition, there was never any “building” of the web application, the only earlier recitation is “the user interface corresponds to an existing web application flow”. Examiner is not sure what to suggest as Examiner is also not sure how this is supported. For purposes of applying prior art only, Examiner interprets claim 1 as reciting: “generate a web-based user interface form based upon the state of the guided workflow transaction path by reconstructing the guided workflow transaction path using the overlay configuration files with the underlying web application.”
Claim 13 is rejected for reciting the same limitations.
Claims 2, 4-5, 7-12, 14, 16-17, 19-28 depend from claims 1 and 13 are rejected for the same reasons.
Claim 11 and 23 now recite: “updating the state of the guided workflow transaction path as completed without modifying the underlying client service software application”. The limitation of “updating” but at the same time “without modifying” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. It is unclear what is happening – as “updating” the workflow transaction path, which the earlier part of the claim states is “in a client service software application”, can somehow be updating “without modifying.” Applicant is invited to explain this, point to support, and/or amend the claim as needed to have sufficient 112(a) support.
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-2, 4-5, 7-14, 16-17, 19-28 are rejected under 35 U.S.C. 103 as being unpatentable over Represas (US 2023/0004424), Bodnick (US 2014/0281967), and Allison (US 10,733,364).
Concerning claim 1, Represas discloses:
A system for guided workflow processing in client service software applications (Represas – see par 190, FIG. 5 - example embodiment of the architecture of a distributed computer system 500. Boxes in FIG. 5 indicate functional components that can be sets of stored program instructions. Arrows in FIG. 5 indicate network links and/or paths of communication of digital messages; see par 194 – FIG. 5 – solution for commercial bank in issuing and administration credit to customers; decisioning party consists of bank employees and third parties representing the bank; requesting party consists of borrows, guarantors; FIG. 6 represents schematic of sample embodiment; FIG. 7 expands on sample implementation), the system comprising a server computing device with a memory for storing computer-executable instructions and a processor that executes the computer-executable instructions (Represas – see par 255 – FIG. 14 – example computer system; 258-259, FIG. 14 – computer system 1400 includes memory 1406 and storage 1410; storage 1410 is an example of non-transitory computer-readable storage medium, used to store instructions, executed by processor 1404 to cause computer-implemented methods) to:
determine a guided workflow transaction path in a client service software application based upon input received from a first client computing device (Represas – see FIG. 5, par 191 - The internet-enabled devices of requesting parties may include, but are not limited to, a workstation 502, portable computer system 504, or handheld device 506. One or more internet-enabled devices of a requesting party may communicate with one or more communications channels such as requestor web user interface (“UI”) 508, requesting party's email server(s) 510, and/or other channel communication platforms 512, such as SMS. Via path 514, the communications channels may transmit the following to the multi-channel communications controller (“MCCC”) 518: i) messages between parties and their metadata, including sender/receiver information, ii) processed documents and their metadata, and iii) unprocessed documents and their metadata; see par 192 - Native components, such as the DP 516, MCCC 518, and decisioner web UI 520 ... In some embodiments, back-end components may include a system of record (“SOR”) 540, workflow/customer relationship management (“W/CRM”) 542, and/or content management system (“CMS”) 544), including displaying a user interface associated with the guided workflow transaction path on the first client computing device (Represas – see par 123-125 - Given information about the borrowing party and/or the particular workflow the borrowing party has been assigned to (for example a loan application), the SOR (System-of-record) can be queried to retrieve a result set of which documents are still needed by the institution to complete the requirements of the workflow or of a specific workflow stage; See par 127 - A workflow/customer relationship management (“W/CRM”) component maintains demographic/firmographic information about the various customer relationships in which the institution is in business (or potential business), … and an index of various workflows that the customer relationship can be assigned to (for example a loan application, a monitoring request, etc.). If assigned to a workflow, the W/CRM will additionally have information related to that relationship's progress within the workflow such as the current state and upcoming/necessary tasks and actions for the workflow.), wherein the user interface corresponds to an existing web application flow (Represas – see par 138 - an online web-based user interface such as requestor UI 508 of FIG. 5 may be hosted by the decisioning institution (or a third party servicing the decisioning institution) and acts as an interface accessible via a web browser where the requesting and decisioning parties can securely exchange information; see par 235 - In each case, the Requestor's web UI 508 and Decisioner's web UI 520 may use a purpose-built, web application hosted in single-tenant public cloud infrastructure (for example Heroku Runtime) accessible by public internet clients through a web (HTTP/S) browser 810. The front-end of the web application presents a user interface accessible to the lending party (e.g., decisioning party) from which they may send and receive messages (along with their attachments and embeddings), view, modify and validate data submitted to the requesting party, and perform other actions such as document preparation and annotation), the user interface including one or more integrated visual…elements defined by one or more … configuration files and positioned relative to corresponding user interface elements according to the guided workflow transaction path, wherein at least a portion of the visual overlay elements comprise prompts instructing a user of the first client computing device to interact with the user interface in a defined manner to continue the guided workflow transaction path (Represas – see par 163 - Tasks may then be composed together in sequential or parallel order to form journeys, which ensure execution of tasks can only occur in a certain order from the time a journey starts until the journey concludes. Journeys themselves may be associated with workflows from the W/CRM. a task can be triggered when a relationship in the institution's W/CRM is transitioned from the “underwriting” to the “closing” stages of some workflow. See par 166 - users may decide to incorporate into any task an information exception embedding (hereafter “embedding”) that details the difference between the corpus of documents that the decisioning institution needs at some point of time and the current state of those requested documents (that is, the “exceptions”). The embedding is an abstraction that can be pre-defined during task creating and performs just-in-time rendering of the exceptions upon task execution. See par 185 - In the case of real-time embeddings, the above sequence is identical, except instead of replacing the placeholder variable with rendered exceptions, the placeholder variable is replaced with source code that will itself fetch the exception data from the document processor and SOR and dynamically render the user interface for the exceptions on an on-demand basis. See par 243, FIG. 10 - illustrates a diagram 1000 of an example graphical user interface in which a checklist functionality may operate. In particular embodiments… provides instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508. Browser 810 may display checklist interface 1010, in which a checklist tracking the state of various needed 102 documents may be displayed; status bar 1020 may display an indication of which state and/or stage in the process the requestor is currently in. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase,… and/or “Funding” phase; see FIG. 10).
PNG
media_image1.png
558
758
media_image1.png
Greyscale
Represas discloses having an embedding that “details” the difference between the current state and the current state (see par 163), dynamically render a user interface with the embedding (See par 185), and having a checklist along with a status bar for the stage the requestor is in (See FIG. 10, par 243). FIG. 10 also shows on the right icons with exclamation marks.
To any extent the “exclamation marks” are not considered, “overlay,” Bodnick and Allison also disclose:
wherein the user interface corresponds to an existing web application flow, the user interface including one or more integrated visual “overlay” elements defined by one or more “overlay” configuration files and positioned relative to corresponding user interface elements according to the guided workflow transaction path, wherein at least a portion of the visual overlay elements comprise prompts instructing a user of the first client computing device to interact with the user interface in a defined manner to continue the guided workflow transaction path (Bodnick see par 71 - when a user opts to include a "Show Me" presentation of slides, using an interface 904 that may be presented by a hardware processor of a computing device, the hardware processor can present a popup window 902, as shown in FIG. 9A. Upon navigating through the thumbnail previews, the hardware processor can present a snippet 906 of entered text when the user hovers over that slide as shown in interface 908 of FIG. 9B; see par 165, FIG. 112 - The hardware processor can receive a user input (e.g., by clicking on a step) to edit or complete it. Upon receiving the user input at an individual step, the hardware processor can present a step screen shown in interface 11200. Here, the hardware processor can display a step label, step instructions, and response choices. The user can take actions such as respond/edit response, add/edit text details, or add photos or video to the step (disclosing “overlay configuration files,” as this shows how the instructions to a user are edited)
PNG
media_image2.png
742
808
media_image2.png
Greyscale
PNG
media_image3.png
578
430
media_image3.png
Greyscale
Allison – See col. 9, lines 1-14 - similar to FIG. 3, the screen of FIG. 4 can include a contract acceptance selection 408 (“Sign Here”) and require confirmation of the user and/or authentication by user. Labels 410 can provide identifying indicia to assist the user. The simplified form interface presented on the screen 400 beneficially presents information to the user in a more user friendly manner; col. 9, lines 15-31 - In FIG. 3, the screen 300 that is presented can require the user to view the form to ascertain what particular fields 304, 306 represent in the form (“INITIAL”). One method to assist the user is to provide an identifying label near the field, for example a pop up box that identifies the field (e.g. “INITIAL”).).
PNG
media_image4.png
756
524
media_image4.png
Greyscale
Represas discloses:
initiate a transaction based upon the guided workflow transaction path, including capturing one or more data elements associated with a user of a second client computing device via the displayed user interface (Represas – See par 129-130 - Store and serve information regarding requesting organizations (customers) and/or individual requestors, including contact information as well as communication activity with each person; Store and serve information regarding a relationship's status within a pre-defined workflow, (for example the various stages of a loan application), as well as metadata about the relationship's progress within the workflow (for example time at each stage); see par 161 - One or more triggers that will cause the task to be either surfaced or executed. An event is defined as any change (or lack thereof) to the internal state kept by SOR, the document processor or the W/CRM. For example: the addition of a new document into the SOR, the transition of a relationship within one stage to another of a workflow within the W/CRM; See par 248-249 – FIG. 13 – example graphical user interface in one embodiment… for internet-enabled devices of requesting party; list interface 1310 may request data in the form of an editable text response; list interface 1310 may display a comment from the decisioning party, such as, “This number here is an issue as it doesn't line up with 12a, Mark how should this be considered?” As an example… the requesting party may view the forementioned comment, and select resolve functionality 1340… generate an editable text box in which the requesting party may input a text response in response to the item indicated as needed 102 by the list interface 1310.);
store the captured data elements in a data structure for the transaction, the data structure including a transaction identification token (Represas – see par 236 - browser 810 may include a matter functionality 812 (e.g., “Project 1”), in which the decisioning party may view a compilation of datum from a particular requesting party marked with a state of received 104 and/or validated 106 by the decisioning party. For example, datum compiled from a particular requesting party may be stored by the platform and tagged by a matter title (e.g., Project 1), so the decisioning party may navigate between client matters within the platform UI (e.g., Decisioner's web UI 520).) and a state of the guided workflow transaction path (Represas – see par 131 - Store and serve metadata about workflows, such as the tasks needed to complete the workflow, or that workflow's association with some financial instrument or facility (for example a loan or a depository account opening). See par 164 - For example, a task, such as Task A, may be triggered when a relationship in the institution's W/CRM is transitioned from the “underwriting” to “closing” stages of some workflow. It is understood that tasks may have more than one trigger and the completion of one task may trigger a different task. As demonstrated in FIG. 3, the triggering conditions for Task E are execution of Task C, execution of Task D, and the W/CRM indication that the relationship is in the “Underwriting” stage. See par 243, FIG. 10 - status bar 1020 may display an indication of which state and/or stage in the process the requestor is currently in. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase, “Closing” phase, and/or “Funding” phase), wherein the transaction identification token enables continuation of the transaction independently of an active user interface session (FIG. 12 – appears the example refers to authenticating the CSR (Customer service representative)
Bodnick – see par 74 - In accordance with some embodiments, using an interface 1202 that may be presented by a hardware processor of a computing device, the hardware processor can receive login information from a user. Upon receiving the login information, the hardware processor can present a dashboard, as shown in interface 1202 of FIG. 12A. The dashboard can contain one or more useful widgets that can help the user resume their work. see par 122 - the hardware processor can present a "My Account" page (e.g., for each user) as shown, for example, in FIG. 50A. Here, the hardware processor can display a user's basic information, the user's group memberships, and/or the user's interactive checklists. The hardware processor can receive a user input to indicate the user's interactive checklist preferences and/or receive a user input to indicate a user would like to change their password;
See also Allison – Col. 10, lines 36-40 - The system can optionally include an authentication module 608 to authenticate users. Authentication techniques can include password, encryption, certificates, key management, and other authentication techniques.);
Represas refers to needing logs of people to view or approve a document (See par 192).
Bodnick discloses:
receive a request to continue the transaction from the second client computing device (Bodnick – see par 74 - In accordance with some embodiments, using an interface 1202 that may be presented by a hardware processor of a computing device, the hardware processor can receive login information from a user. Upon receiving the login information, the hardware processor can present a dashboard, as shown in interface 1202 of FIG. 12A. The dashboard can contain one or more useful widgets that can help the user resume their work. ).
Represas and Bodnick and Allison disclose:
retrieve the data structure for the transaction upon authenticating the user of the second client computing device (Represas – see par 199 - In addition, it manages its own data store (in the form of a MongoDB high availability cluster) for the purpose of managing application authentication and access control, as well as storing and presenting other data beyond the scope of the system. see par 204 - Further, the web and API services 704 manages its own data stores 706 for the purpose of managing application authentication and access control, as well as storing and presenting other data beyond the scope of the system;
see also Bodnick - see par 74 - In accordance with some embodiments, using an interface 1202 that may be presented by a hardware processor of a computing device, the hardware processor can receive login information from a user. Upon receiving the login information, the hardware processor can present a dashboard);
generate a web-based user interface form based upon the state of the guided workflow transaction path by reconstructing the guided workflow transaction path using the overlay configuration files without rebuilding the underlying web application, the web-based user interface form comprising the captured data elements from the retrieved data structure (Represas –see par 218-219 - Consider the scenario of a bank requesting documents required to originate a commercial loan. This will typically imply collecting dozens of documents belonging to a business (for example company financials, articles of organization/incorporation and bylaws, proofs of insurance etc.) as well as documents for each of the individual guarantors and select officers of the company (for example personal financial statements, mortgages or deeds used as collateral, tax returns etc.). see par 235 - In each case, the Requestor's web UI 508 and Decisioner's web UI 520 may use a purpose-built, web application hosted in single-tenant public cloud infrastructure (for example Heroku Runtime) accessible by public internet clients through a web (HTTP/S) browser 810. The front-end of the web application presents a user interface accessible to the lending party (e.g., decisioning party) from which they may send and receive messages (along with their attachments and embeddings), view, modify and validate data submitted to the requesting party, and perform other actions such as document preparation and annotation. see FIG. 10, par 243 – internet-enabled devices of the decisioning party (e.g., workstation 550, portable computer system 552, and/or handheld device 554) may provide instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508; In the example of diagram 1000, browser 810 may display checklist interface 1010, in which a checklist tracking the state of various needed 102 documents may be displayed. In particular embodiments, status bar 1020 may display an indication of which state and/or stage in the process the requestor is currently in. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase, “Closing” phase, and/or “Funding” phase (see “profit & loss statement” is example that is needed by the Borrower Julianna Land)).
the web-based user interface form including one or more visual overlay elements positioned in proximity to corresponding user interface elements according to the guided workflow transaction path, wherein at least a portion of the visual overlay elements comprise prompts instructing a user of the first client computing device to interact with the user interface in a defined manner to continue the guided workflow transaction path (Represas - See par 185 - In the case of real-time embeddings, the above sequence is identical, except instead of replacing the placeholder variable with rendered exceptions, the placeholder variable is replaced with source code that will itself fetch the exception data from the document processor and SOR and dynamically render the user interface for the exceptions on an on-demand basis. See par 243, FIG. 10 - illustrates a diagram 1000 of an example graphical user interface in which a checklist functionality may operate. In particular embodiments… provides instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508.
See also Allison –see col. 9, lines 15-31 - In FIG. 3, the screen 300 that is presented can require the user to view the form to ascertain what particular fields 304, 306 represent in the form. One method to assist the user is to provide an identifying label near the field, for example a pop up box that identifies the field. In FIG. 4 however, the screen 400 of the simplified form interface can beneficially use labels 410 to more easily identify data entry fields 404, 406 for the user);
display the web-based user interface form on the second client computing device ([0054] as published - In this example, module 106b processes the new child node to generate (step 212) a web-based user interface form based upon the state of the transaction path and display (step 214) the web-based user interface form to the customer at client computing device 103. The web-based user interface form includes at least a portion Represas - see FIG. 10, par 243 – user interface can be for Requestor’s web UI 508; In the example of diagram 1000, browser 810 may display checklist interface 1010, in which a checklist tracking the state of various needed 102 documents may be displayed. document checklist includes last one in list “profit & loss statement” is example that is needed by the Borrower Julianna Land)); See par 249, FIG. 13 - In particular embodiments, list interface 1310 may request data in the form of an editable text response. For example, in diagram 1300, list interface 1310 may display a comment from the decisioning party, such as, “This number here is an issue as it doesn't line up with 12a, Mark how should this be considered?” As an example and not by way of limitation, the requesting party may view the forementioned comment, and select resolve functionality 1340. The resolve functionality 1340, once selected, may generate an editable text box in which the requesting party may input a text response in response to the item indicated as needed 102 by the list interface 1310.); and
process the transaction based upon input received from the second client computing device via the web-based user interface form, including updating the state of the guided workflow transaction path upon processing the transaction (Represas – see FIG. 10 – can click “add checklist item”; see par 249 - As another example and not by way of limitation, the resolve functionality 1340, once selected, may generate an option to mark the item as “Resolved,” wherein the status of the item of list interface 1310 may be transferred from “needed” 102 to “sent” 112 and/or “validated” 106. See par 209 - The task service 724 continuously polls active journeys in MongoDB and checks for the execution conditions of their first-most uncompleted task(s), querying the various internal and external services and data stores 726 to verify if execution conditions have been met. If the execution conditions are met, the task service 724 will either automatically execute the task according to the aforementioned task description (and subsequently update the MCCC 518 state to reflect the task has been executed) or store the task in a staging collection. When tasks involve the sending of messages and their associated metadata, these are also passed to the propagation service 734.)
Represas, Bodnick, and Allison are analogous art as they are directed to performing workflow/activities, which can include approvals (See Represas Abstract, par 125-127, 132 – workflow for a borrowing party for a loan application; Bodnick Abstract, par 85 – approvers or assignment; See Allison, Col. 8, lines 52-67). 1) Represas discloses needing logs of people to view or approve a document (See par 192). 1) Bodnick improves upon Represas by disclosing having users being able to resume their work upon receiving their login information (See par 74). One of ordinary skill in the art would be motivated to further have users resume their work upon logging in to efficiently improve upon the approvals of documents (see par 192) and the process of using journeys, tasks, and workflows for loans (See par 132, 217-220) in Represas. 2) Represas discloses having an embedding that “details” the difference between the current state and the current state (see par 163), dynamically render a user interface with the embedding (See par 185), and having a checklist along with a status bar for the stage the requestor is in (See FIG. 10, par 243). FIG. 10 also shows on the right icons with exclamation marks. Bodnick improves upon Represas by disclosing having a snippet of entered when the user hovers over a slide (See par 71) and displaying step labels or step instructions for editing or completing a step (See par 165, FIG. 112). Allison improves upon Represas and Bodnick by disclosing having labels that assist the user and pop up boxes to easily identify data entry fields for the user (See col. 9, FIG. 3-4). One of ordinary skill in the art would be motivated to further have snippets of text appear when a user hovers that can include step labels or instructions in Bodnick and/or labels and pop up boxes in Allison to efficiently improve upon the approvals of documents (see par 192) and the process of using journeys, tasks, and workflows for loans (See par 132, 217-220) with dynamically rendered user interface in Represas.
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 use of data processing with workflows for loan applications (see par 125-127, 132, 217-220) in Represas, to further snippets of text appearing when a user hovers with step instructions, along with allowing a logged in user to resume work in Bodnick, and to further include pop up boxes and identifying labels as disclosed in Allison, 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 13, Represas and Bodnick and Allison disclose:
A computerized method of guided workflow processing in client service software applications (Represas – see par 190, FIG. 5 - example embodiment of the architecture of a distributed computer system 500. Boxes in FIG. 5 indicate functional components that can be sets of stored program instructions. Arrows in FIG. 5 indicate network links and/or paths of communication of digital messages; see par 194 – FIG. 5 – solution for commercial bank in issuing and administration credit to customers; decisioning party consists of bank employees and third parties representing the bank; requesting party consists of borrows, guarantors; FIG. 6 represents schematic of sample embodiment; FIG. 7 expands on sample implementation), the method comprising:
determining, by a server computing device…(Represas – see par 255 – FIG. 14 – example computer system; 258-259, FIG. 14 – computer system 1400 includes memory 1406 and storage 1410; storage 1410 is an example of non-transitory computer-readable storage medium, used to store instructions, executed by processor 1404 to cause computer-implemented methods).
The remaining limitations are similar to claim 1 above. Claim 13 is rejected for the same reasons.
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 2 and 14, Represas, Bodnick, and Allison disclose:
The system of claim 1, wherein the server computing device, the first client computing device, and the second client computing device are coupled to each other via a web server computing device that hosts the client service software application (Represas – see par 199-2000, FIG. 5 - Further, the sample embodiment as described uses a purpose-built, web application hosted in single-tenant public cloud infrastructure, (for example Heroku Runtime) accessible by public internet clients through a web (HTTP/S) browser; see par 260, FIG. 14 – instructions may implement a web server; par 265 – can have server 1430, host 1424), the guided workflow transaction path being implemented as an overlay atop the client service software application hosted by the web server computing device (Represas – see par 163 - Tasks may then be composed together in sequential or parallel order to form journeys, which ensure execution of tasks can only occur in a certain order from the time a journey starts until the journey concludes. Journeys themselves may be associated with workflows from the W/CRM; See par 166 - users may decide to incorporate into any task an information exception embedding (hereafter “embedding”) that details the difference between the corpus of documents that the decisioning institution needs at some point of time and the current state of those requested documents (that is, the “exceptions”). See par 185 - In the case of real-time embeddings, the above sequence is identical, except instead of replacing the placeholder variable with rendered exceptions, the placeholder variable is replaced with source code that will itself fetch the exception data from the document processor and SOR and dynamically render the user interface for the exceptions on an on-demand basis. See par 243, FIG. 10 - illustrates a diagram 1000 of an example graphical user interface in which a checklist functionality may operate. In particular embodiments… provides instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase,… and/or “Funding” phase; see FIG. 10;
see also Bodnick for “overlay” as in claim 1 - Upon navigating through the thumbnail previews, the hardware processor can present a snippet 906 of entered text when the user hovers over that slide as shown in interface 908 of FIG. 9B; see par 165, FIG. 112 - The hardware processor can receive a user input (e.g., by clicking on a step) to edit or complete it. Upon receiving the user input at an individual step, the hardware processor can present a step screen shown in interface 11200. Here, the hardware processor can display a step label, step instructions, and response choices;
see also Allison for “overlay” as in claim 1 - See col. 9, lines 1-31 - similar to FIG. 3, the screen of FIG. 4 can include a contract acceptance selection 408 (“Sign Here”) and require confirmation of the user and/or authentication by user. Labels 410 can provide identifying indicia to assist the user; In FIG. 3, the screen 300 that is presented can require the user to view the form to ascertain what particular fields 304, 306 represent in the form (“INITIAL”). One method to assist the user is to provide an identifying label near the field, for example a pop up box that identifies the field (e.g. “INITIAL).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 4 and 16, Represas and Bodnick disclose:
The system of claim 2, wherein the web-based user interface form displayed on the second client computing device comprises the webpage of the client service software application (Represas – see FIG. 10, par 243 - provide instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508. See par 248 - FIG. 13 illustrates a diagram 1300 of an example graphical user interface in which one embodiment of the portal may operate. In particular embodiments, in response to the requestor selecting login button 1220 of the information request and/or logging into the portal through a browser application, one or more processors of the internet-enabled devices of the requesting party may provide instructions to browser 810 to render the platform (e.g., portal) as part of a GUI to appear on the Requestor's web UI 508.), the webpage being reconstructed for the second client computing device based on the state of the guided workflow transaction path and the overlay configuration files (Represas – see par 163 -. Journeys themselves may be associated with workflows from the W/CRM; See par 166 - users may decide to incorporate into any task an information exception embedding (hereafter “embedding”) that details the difference between the corpus of documents that the decisioning institution needs at some point of time and the current state of those requested documents (that is, the “exceptions”). See par 185 - In the case of real-time embeddings, the above sequence is identical, except instead of replacing the placeholder variable with rendered exceptions, the placeholder variable is replaced with source code that will itself fetch the exception data from the document processor and SOR and dynamically render the user interface for the exceptions on an on-demand basis. See par 243, FIG. 10 - illustrates a diagram 1000 of an example graphical user interface in which a checklist functionality may operate. In particular embodiments… provides instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase,… and/or “Funding” phase; see FIG. 10;
see also Bodnick for “overlay” as in claim 1 - Upon navigating through the thumbnail previews, the hardware processor can present a snippet 906 of entered text when the user hovers over that slide as shown in interface 908 of FIG. 9B; see par 165, FIG. 112 - The hardware processor can receive a user input (e.g., by clicking on a step) to edit or complete it. Upon receiving the user input at an individual step, the hardware processor can present a step screen shown in interface 11200. Here, the hardware processor can display a step label, step instructions, and response choices;
see also Allison for “overlay” as in claim 1 - See col. 9, lines 1-31 - similar to FIG. 3, the screen of FIG. 4 can include a contract acceptance selection 408 (“Sign Here”) and require confirmation of the user and/or authentication by user. Labels 410 can provide identifying indicia to assist the user; In FIG. 3, the screen 300 that is presented can require the user to view the form to ascertain what particular fields 304, 306 represent in the form (“INITIAL”). One method to assist the user is to provide an identifying label near the field, for example a pop up box that identifies the field (e.g. “INITIAL).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 5 and 17, Represas discloses requestor (e.g. of loans) may login to the platform (See par 247-248) and that there is “authentication” (See par 199).
Bodnick and Allison disclose:
The system of claim 1, wherein retrieving the data structure for the transaction upon authenticating the user of the second client computing device comprises:
identifying the user of the second client computing device based upon authentication credentials in the request (Bodnick – see par 161 - Turning back to FIG. 106A, the hardware processor can receive login information from a user. Upon receiving the login information, the hardware processor can present a dashboard, where the user can view messages, approval notifications, their personal list of activities, and/or a list of activities for their groups as shown, for example, in interface 10602 of FIG. 106A;
See also Allison – Col. 10, lines 36-40 - The system can optionally include an authentication module 608 to authenticate users. Authentication techniques can include password, encryption, certificates, key management, and other authentication techniques);
authenticating the user of the second client computing device by validating the authentication credentials (Bodnick – see par 161 - Turning back to FIG. 106A, the hardware processor can receive login information from a user. Upon receiving the login information, the hardware processor can present a dashboard, where the user can view messages, approval notifications, their personal list of activities, and/or a list of activities for their groups as shown, for example, in interface 10602 of FIG. 106A;
See also Allison – Col. 10, lines 36-40 - The system can optionally include an authentication module 608 to authenticate users. Authentication techniques can include password, encryption, certificates, key management, and other authentication techniques)
Represas and Bodnick and Allison disclose:
determining one or more in-process transactions based upon the user identity (Represas – see par 236 - browser 810 may render the platform on the internet-enabled devices of the decisioning party, wherein the decisioning party may be presented with a metadata from documents provided by the requesting party. As an example and not by way of limitation, browser 810 may include a matter functionality 812 (e.g., “Project 1”), in which the decisioning party may view a compilation of datum from a particular requesting party marked with a state of received 104 and/or validated 106 by the decisioning party; see also par 248 - FIG. 13 illustrates a diagram 1300 of an example graphical user interface; in response to the requestor selecting login button 1220 of the information request and/or logging into the portal through a browser application, one or more processors of the internet-enabled devices of the requesting party may provide instructions to browser 810 to render the platform (e.g., portal) as part of a GUI to appear on the Requestor's web UI 508);
selecting one of the in-process transactions associated with a transaction identification token in the request (Represas – see par 236 - For example, datum compiled from a particular requesting party may be stored by the platform and tagged by a matter title (e.g., Project 1), so the decisioning party may navigate between client matters within the platform UI (e.g., Decisioner's web UI 520)); and
retrieving the data structure for the in-process transaction (Represas – see par 236 - For example, datum compiled from a particular requesting party may be stored by the platform and tagged by a matter title (e.g., Project 1), so the decisioning party may navigate between client matters within the platform UI (e.g., Decisioner's web UI 520); see also FIG. 13 where there are “All items,” “my items,” “my files”, as well as button at top left for specific matter here – “Umbrella Inc. Business Expansion 6/2022.), wherein the retrieved data structure represents workflow state independent of an active user interface session (Represas – see par 163 -. Journeys themselves may be associated with workflows from the W/CRM; See par 166 - users may decide to incorporate into any task an information exception embedding (hereafter “embedding”) that details the difference between the corpus of documents that the decisioning institution needs at some point of time and the current state of those requested documents (that is, the “exceptions”). See par 185 - In the case of real-time embeddings, the above sequence is identical, except instead of replacing the placeholder variable with rendered exceptions, the placeholder variable is replaced with source code that will itself fetch the exception data from the document processor and SOR and dynamically render the user interface for the exceptions on an on-demand basis. See par 243, FIG. 10 - illustrates a diagram 1000 of an example graphical user interface in which a checklist functionality may operate. In particular embodiments… provides instructions to browser 810 to render the platform as part of a GUI to appear on the Decisioner's Web UI 520 and/or the Requestor's web UI 508. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase,… and/or “Funding” phase; see FIG. 10;
see also Bodnick par 74 - The dashboard can contain one or more useful widgets that can help the user resume their work).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 7 and 19, Represas and Bodnick and Allison disclose:
The system of claim 1, wherein the guided workflow transaction path corresponds to an electronic document signature workflow (Represas – See par 98, 146-147 - if the decisioning party needs to send a loan agreement to the requesting party for signature by all guarantors, this may represent the datum sent 112 state; if signature absent, mark the document as needing a lending agent's intervention on the correct transformation, category or association (that is, “the expert's judgments”), and hold in an internal store or third-party data store until the appropriate judgments have been made by an expert; see par 227 – Documents submitted by the requesting party will typically need validation in part of the decisioning party (for example verifying signatures, execution date, and entity names match expectations) and may result in additional questions by the decisioning agent or specific instructions on how the document should change so as to be validated), the electronic document signature workflow being guided using visual overlay elements applied to an existing web application flow (Allison – see FIG. 3-4 – showing user “SIGN HERE”).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 8 and 20, Represas and Bodnick and Allison disclose:
The system of claim 7, wherein capturing one or more data elements associated with a user of a second client computing device via the displayed user interface comprises:
receiving a user identifier associated with the user of the second client computing device via the displayed user interface (Represas – see par 142 - Automatically infer the subjects and named entities (for example people, locations, businesses) mentioned in the document, and, when applicable, associate the document with the matching entities present in the W/CRM and/or SOR (relationships, leads, prospects, accounts, etc.). In an embodiment, code to associate the subjects may be programmed to store, in a record of the electronic document in the system of record, references to one or more entities that are identified in the CRM system and that match the one or more subjects, after transmitting to the CRM system a query identifying the subjects and configured to return a result set of the matching entities in the CRM system. par 247, FIG. 12 - In particular embodiments, the requestor may be prompted to Login via Login button 1220, wherein the requestor may login to the platform and upload the documents indicated as needed 102); and
retrieving the one or more data elements associated with the user of the second client computing device from a data store based upon the user identifier (Represas – see par 241 - the platform may review document 920 and automatically infer the subjects and named entities (for example people, locations, businesses) mentioned in document 920, and, when applicable, associate the document with the matching entities present in the W/CRM and/or SOR (relationships, leads, prospects, accounts, etc.); see par 248, FIG. 13 - FIG. 13 illustrates a diagram 1300 of an example graphical user interface in which one embodiment of the portal may operate. in response to the requestor selecting login button 1220 of the information request and/or logging into the portal through a browser application, one or more processors of the internet-enabled devices of the requesting party… may provide instructions to browser 810 to render the platform (e.g., portal) ... In this example, browser 810 may display a checklist of tasks labeled “needed” 102 corresponding to the information request as generated by the decisioning party), the retrieved data elements being stored in the data structure and reused upon reconstruction of the guided workflow transaction path (Represas – see par 163 - Tasks may then be composed together in sequential or parallel order to form journeys, which ensure execution of tasks can only occur in a certain order from the time a journey starts until the journey concludes. Journeys themselves may be associated with workflows from the W/CRM. a task can be triggered when a relationship in the institution's W/CRM is transitioned from the “underwriting” to the “closing” stages of some workflow; see par 165 - Journeys may represent a cyclic graph of one or more tasks, wherein not all of which may result in an outbound message. As an example and not by way of limitation, if a first task of the Journey is a null (e.g., “BEGIN” task), a second task may contain a first message. For example, tasks may be conditionally triggered, and a manual (e.g., “execute”) instruction may be a viable or acceptable condition. See par 170 - When a journey is created by the agent, it acts as a reusable component that can be attached to any of the relationships found in the W/CRM. One says an arbitrary journey “J” can be attached to some relationship “R” by creating a copy of the journey at the initial state (with all tasks un-executed) and assigning it to R. At that point, it is said that “journey J is active for the relationship R”. The journey's tasks can then be executed for that relationship, according to the triggers in each task, until all tasks conclude their execution, or the journey is forcefully detached from the relationship).
Concerning claims 9 and 21, Represas and Bodnick disclose:
The system of claim 8, wherein the server computing device transmits a signature request notification to the second client computing device upon storing the captured data elements in the data structure for the transaction, the signature request notification including the transaction identification token (Represas – see par 133-134 – Content management system (CMS) - content consisting of templated communications (for example email messages) and documents (for example term sheets) that are typically interchanged between agents of the financial institution and those of the borrowing party. The CMS can be programmed to perform the following: Store and serve templates (template documents or template text for use in other channels), including metadata about the modifiable fields and segments of the template. See par 200 - The Document Processor further uses MongoDB as a data layer to store and retrieve inferences, judgments, statistical learning models, documents, and other metadata on documents such as commentary from decisioning and requesting agents; see par 249 - list interface 1310 may request data in the form of an editable text response. For example, in diagram 1300, list interface 1310 may display a comment from the decisioning party, such as, “This number here is an issue as it doesn't line up with 12a, Mark how should this be considered?” As an example and not by way of limitation, the requesting party may view the forementioned comment, and select resolve functionality 1340. The resolve functionality 1340, once selected, may generate an editable text box in which the requesting party may input a text response in response to the item indicated as needed 102 by the list interface 1310;
Allison – see FIG. 3-4 – showing user “SIGN HERE”; Col. 10, lines 36-40 - The system can optionally include an authentication module 608 to authenticate users. Authentication techniques can include password, encryption, certificates, key management, and other authentication techniques).
It would be obvious to combine Represas and Allison for the same reasons as claim 1.
Concerning claims 10 and 22, Represas, Bodnick, and Allison disclose:
The system of claim 9, wherein the second client computing device transmits the request to continue the transaction to the server computing device upon activation of the notification by the user of the second client computing device, the request referencing the transaction identification token to enable reconstruction of the guided workflow transaction path (Represas see par 164 - s demonstrated in FIG. 3, journeys may be associated with workflows from the W/CRM. It is understood that journeys, which represent automated or semi-automated communication steps, are independent of but may be associated with a W/CRM state 304. For example, a task, such as Task A, may be triggered when a relationship in the institution's W/CRM is transitioned from the “underwriting” to “closing” stages of some workflow. see par 169 - Aside from monitoring communications channels, the MCCC periodically polls the W/CRM, the SOR, and its internal store to obtain the present state of the system and determine if any presently active journeys have tasks that should be triggered. see par 170 - When a journey is created by the agent, it acts as a reusable component that can be attached to any of the relationships found in the W/CRM. One says an arbitrary journey “J” can be attached to some relationship “R” by creating a copy of the journey at the initial state (with all tasks un-executed) and assigning it to R. At that point, it is said that “journey J is active for the relationship R”. The journey's tasks can then be executed for that relationship, according to the triggers in each task, until all tasks conclude their execution, or the journey is forcefully detached from the relationship.).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 11 and 23, Represas discloses:
The system of claim 10, wherein processing the transaction based upon input received from the second client computing device via the web-based user interface form comprises:
generating an electronic document signed by the user of the second client computing device, the electronic document comprising the captured data elements from the retrieved data structure (Represas – see par 52 - Some example documents include: Agreements which members of the borrowing party will have to sign
see also Allison – see FIG. 3-4, “SIGN here”; see Col. 6, lines 35-57 - For a typical business transaction, there may be multiple ways of entering information into the various forms 100 needed to formalize the transaction, including editing text in a Word™ document, filling in a field of a PDF form, and signing a printed form; see col. 14, lines 23-32 - For example, the party can select an accept offer button as is described with regard to FIG. 5. In various configurations, the system can require additional confirmation steps or authentication of the party. Authentication methods can include those methods described with regard to the authentication module of FIG. 6. For example, a state may have a legal requirement that a form be physically signed and authenticated by a licensed real estate agent.); and
updating the state of the guided workflow transaction path as completed without modifying the underlying client service software application (Represas – see par 209 - If the execution conditions are met, the task service 724 will either automatically execute the task according to the aforementioned task description (and subsequently update the MCCC 518 state to reflect the task has been executed) or store the task in a staging collection. see par 226 - these requests can consist of personalized messages with attached embeddings that correctly reflect the state of documents as received by the bank, allowing the lender to specify which documents are needed and which ones have already been received without needing to build this list of documents themselves. see par 243 - In particular embodiments, status bar 1020 may display an indication of which state and/or stage in the process the requestor is currently in. For example, the status bar may indicate the requestor is in the “Application” phase, “Pre-underwriting” phase, “Underwriting” phase, “Term Sheet Review” phase, “Closing” phase, and/or “Funding” phase; ).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1 and claim 10.
Concerning claims 12 and 24, Allison disclose:
The system of claim 11, wherein the server computing device transmits a copy of the generated electronic document to the second client computing device upon processing the transaction, the transmission occurring after completion of the guided workflow transaction path represented by the transaction state (Allison – See col. 14, lines 15-36 - In process block 830, if the party has accepted the offer in decision block 818, then the party may optionally need to acknowledge certain terms in the offer similar to process block 820. For example, a buyer may accept a seller's offer for a sale of a property; In process block 832, the party accepts the offer from the other party. For example, the party can select an accept offer button as is described with regard to FIG. 5. In various configurations, the system can require additional confirmation steps or authentication of the party. Authentication methods can include those methods described with regard to the authentication module of FIG. 6. For example, a state may have a legal requirement that a form be physically signed and authenticated by a licensed real estate agent. Processing continues to process block 834; In process block 834, the form and data entered into fields associated with the form can optionally be printed out or otherwise saved, for example as a PDF in a cloud server).
It would be obvious to combine Represas and Allison for the same reasons as claim 1. Represas discloses having parties sign documents (See par 52). Allison improves upon Represas by further having a copy transmitted for availability in a cloud server (See col. 14).
Concerning claims 25 and 27, Represas, Bodnick, and Allison discloses:
The system of claim 1, wherein each visual overlay element comprises a prompt that directs a user to interact with a specific user interface element of the client service software application, and wherein the server computing device generates the visual overlay elements for integration into underlying content served by a web server based on a current state of the guided workflow transaction path (Bodnick – see par 70 - . In response to the hardware processor receiving a user input (e.g., by clicking on a "Show Me" button);
Allison - See col. 9, lines 1-14 - similar to FIG. 3, the screen of FIG. 4 can include a contract acceptance selection 408 (“Sign Here”) and require confirmation of the user and/or authentication by user. Labels 410 can provide identifying indicia to assist the user. The simplified form interface presented on the screen 400 beneficially presents information to the user in a more user friendly manner; col. 9, lines 15-31 - In FIG. 3, the screen 300 that is presented can require the user to view the form to ascertain what particular fields 304, 306 represent in the form (“INITIAL”). One method to assist the user is to provide an identifying label near the field, for example a pop up box that identifies the field (e.g. “INITIAL).
It would be obvious to combine Represas and Bodnick and Allison for the same reasons as claim 1.
Concerning claims 26 and 28, Represas, Bodnick, and Allison discloses:
The system of claim 1, wherein the guided workflow transaction path is represented as a data structure comprising a plurality of workflow nodes, and wherein the server computing device controls progression between the workflow nodes by updating the state of the guided workflow transaction path based on detected user interactions and one or more validation or regulatory compliance steps (Represas – see par 164 - Users may create an arbitrary number of different journeys, each of which codifies a composition of tasks running in series or in parallel. Since tasks can have more than one trigger and the completion of a task can trigger a different task, it is assumed journeys can be modeled as a directed graph, as shown in FIG. 3. FIG. 3 displays an example embodiment of a graph representation 300 of journeys, tasks, and their functionalities. For example, a task, such as Task A, may be triggered when a relationship in the institution's W/CRM is transitioned from the “underwriting” to “closing” stages of some workflow. see par 165 Journeys may represent a cyclic graph of one or more tasks. see par 170 - ] When a journey is created by the agent, it acts as a reusable component that can be attached to any of the relationships found in the W/CRM. One says an arbitrary journey “J” can be attached to some relationship “R” by creating a copy of the journey at the initial state (with all tasks un-executed) and assigning it to R. At that point, it is said that “journey J is active for the relationship R”. The journey's tasks can then be executed for that relationship, according to the triggers in each task, until all tasks conclude their execution, or the journey is forcefully detached from the relationship. see par 172 - FIG. 4A demonstrates an example embodiment of a journey flow 400 that is active for relationship A. It is understood that once a journey is created, it may be assigned more than one relationship, and the progress of each journey within that relationship may be tracked individually.).
Response to Arguments
Applicant's arguments filed 2/17/26 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With respect to 103, Applicant argues limitations, such as “guiding a user by … generating visual overlay elements”. The arguments are moot in view of the revised rejections. Briefly, Bodnick and Allison (pop-up boxes) disclose the overly as explained in the rejection.
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