PLATFORM

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional Patent Application No. 62/635212, filed February 26, 2018, and titled“EMAIL INTEGRATION TO GRAPH- BASED WORKFLOW PLATFORM”. This application also relates to International Patent Application Publication No. WO 2018/156781, published August 30, 2018, and titled “COMPACT PRESENTATION OF AUTOMATICALLY SUMMARIZED INFORMATION ACCORDING TO RULE-BASED GRAPHICALLY REPRESENTED INFORMATION” (“the’781 Publication”). The entire disclosure of each of the above items is hereby made part of this specification as if set forth fully herein and incorporated by reference for all purposes, for all that it contains.

[0002] Any and all applications for which a foreign or domestic priority claim is identified in the Application Data Sheet as filed with the present application are hereby incorporated by reference under 37 CFR 1.57 for all purposes and for all that they contain.

TECHNICAL FIELD

[0003] Embodiments of the present disclosure relate to systems and techniques for accessing one or more databases and providing user interfaces for dynamic interactions with various data items. Systems and techniques are disclosed, according to certain embodiments, for data integration, analysis, visualization and processing. Further, embodiments of the present disclosure relate to a user security model in which user roles and action on a computer network may be defined by graphs (e.g., directed graphs, for instance loop- digraphs). Yet further, embodiments of the present disclosure relate to integration of external electronic messaging into a graph-based workflow platform.

BACKGROUND

[0004] User security models can constrain implementation of actions associated with particular user roles, for instance a user account associated with a first user role may be allowed to perform an action on a network while a user account associated with a second user role may be blocked. Users can be assigned disparate roles, and through enforcing of actions available to be performed by each disparate role, complex networks can be tightly controlled and constrained. Furthermore, constraints with respect to available actions can be associated with rules, such as a rule that predicates access to particular data, use of system resources (e.g., virtualized central processing units, computer systems), and so on, on one or more complex conditions being satisfied. In this way, constraints on actions can be determined such that a user account assigned a particular user role may be limited to performing particular tasks.

[0005] Many fields in business and academia utilize documents that need to be signed, reviewed, distributed to, and collected from multiple parties. In some instances, the number of signatories and other interested parties to any given document may make the processes involved in handling the document complex, tedious and error-prone. Electronic documents are increasingly being used in transactions.

SUMMARY

[0006] The systems, methods, and devices described herein each have several embodiments and aspects, no single one of which is solely responsible for its desirable attributes and advantages. Without limiting the scope of this disclosure, several non-limiting features and implementations will now be discussed briefly.

[0007] According to various embodiments, a system of the present disclosure may access and utilize one or more graphs (e.g., directed graphs, for instance loop-digraphs) that enable users of disparate roles to perform goals through constraints on actions each user can perform. The system may monitor progression towards a plurality of goals, with the goals demarcated into a series of steps each including one or more tasks to be completed, and based on constraints of user actions (e.g., constraints on modifying data, uploading data, communications, and so on as will be described) the system can limit an extent to which users are free to progress in a direction not towards the goal. As an example, the system can manage a complex electronic engagement via a graph-based workflow platform, with the electronic engagement separated into multiple engagement modules and associated goals and steps (e.g., a first step may indicate obtaining a transaction record, such as a blockchain based electronic ledger including a series of records connected via electronic hashes, a second step may indicate processing of the transaction record to extract particular information, a third step may indicate providing extracted information for review and approval, and so on). The present disclosure further includes, according to various embodiments, email integration and workflow customization of the system by way of the various engagement models and the system structure.

[0008] The graph-based workflow platform can therefore describe an overall progression from an initial location to completion of a plurality of electronic goals, and each task associated with completion of the goals can be represented as a node within a graph connected via one or more edges to one or more other nodes. For instance, a first task associated with accessing a network can be connected with a subsequent task to obtain information from the network according to a particular communication scheme. This connection can be represented via an edge between these two tasks, and the system can utilize, for example, maintained information associated with adjacency matrices to describe edges. However, the graph may also indicate that, based on one or more user actions, the first task can also be connected with a task distinct from the task associated with obtaining information. That is, subsequent to the first task, the distinct task may be associated with accessing a different network, obtaining information (e.g., authentication information, information describing the particular communication scheme, and so on), and subsequently be connected to the task associated with obtaining information from the network according to the particular communication scheme. In this way, the graph can allow for variability in progression towards a goal, and as will be described, can nudge (e.g., generate notifications, prompt users, and so on) to continue on an optimal path of edges connecting nodes.

[0009] In this way, through role-based constraints on user actions that can be performed, for instance based on engagements, engagement modules, permissions, access rights, and so on, defined and described based on particular steps or tasks, the system can ensure progression towards complex goals and provide daylight into daunting electronic transactions/engagements .

[0010] The benefits of using electronic documents may be maximized by automating processes to create, process, sign, and/or review and analyze such documents and/or the information contained therein. As such, there remains a need for novel systems and methods that allow for more efficient use, management, and processing of electronic documents in a convenient and safe manner. [0011] Further, as described herein, the system may be configured and/or designed to generate user interface data useable for rendering the various interactive user interfaces described. The user interface data may be used by the system, and/or another computer system, device, and/or software program (for example, a browser program), to render the interactive user interfaces. The interactive user interfaces may be displayed on, for example, electronic displays (including, for example, touch-enabled displays).

[0012] It has been noted that design of computer user interfaces“that are useable and easily learned by humans is a non-trivial problem for software developers.” (Dillon, A. (2003) User Interface Design. MacMillan Encyclopedia of Cognitive Science, Vol. 4, London: MacMillan, 453-458.) The various embodiments of interactive and dynamic user interfaces of the present disclosure are the result of significant research, development, improvement, iteration, and testing. This non-trivial development has resulted in the user interfaces described herein which may provide significant cognitive and ergonomic efficiencies and advantages over previous systems. The interactive and dynamic user interfaces include improved human-computer interactions that may provide reduced mental workloads, improved decision-making, reduced work stress, and/or the like, for both general and limited users using the system.

[0013] In some embodiments, information may be presented in graphical representations, such as visual representations, such as charts and graphs, where appropriate, to allow the user to comfortably review the large amount of data and to take advantage of humans’ particularly strong pattern recognition abilities related to visual stimuli. In some embodiments, the system may present aggregate quantities, such as totals, counts, and averages.

[0014] In some embodiments, the systems of the present disclosure may assist in managing successive steps, or assist with managing a logical flow, between multiple participants in an engagement. These steps may be described by, e.g., a directed graph, wherein the nodes of the graph represent the individual tasks, and the edges of the graphs represent possible transitions. The graph may have special designated tasks designated as the beginning and the end of the respective workflow.

[0015] Additional embodiments of the disclosure are described below in reference to the appended claims, which may serve as an additional summary of the disclosure. [0016] In various embodiments, systems and/or computer systems are disclosed that comprise a computer readable storage medium having program instructions embodied therewith, and one or more processors configured to execute the program instructions to cause the one or more processors to perform operations comprising one or more aspects of the above- and/or below-described embodiments (including one or more aspects of the appended claims).

[0017] In various embodiments, computer-implemented methods are disclosed in which, by one or more processors executing program instructions, one or more aspects of the above- and/or below-described embodiments (including one or more aspects of the appended claims) are implemented and/or performed.

[0018] In various embodiments, computer program products comprising a computer readable storage medium are disclosed, wherein the computer readable storage medium has program instructions embodied therewith, the program instructions executable by one or more processors to cause the one or more processors to perform operations comprising one or more aspects of the above- and/or below-described embodiments (including one or more aspects of the appended claims).

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The following drawings and the associated descriptions are provided to illustrate embodiments of the present disclosure and do not limit the scope of the claims. Aspects and many of the attendant advantages of this disclosure will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

[0020] Figure 1 illustrates an example implementation of an engagement optimization system (also referred to herein as“the system”) in communication with user devices, according to various embodiments of the present disclosure.

[0021] Figure 2A illustrates an example interactive user interface of the system, according to an embodiment of the present disclosure.

[0022] Figure 2B illustrates example tasks identified in an example graph associated with an electronic goal, according to various embodiments of the present disclosure. [0023] Figure 2C illustrates tasks separated into example steps, according to various embodiments of the present disclosure.

[0024] Figure 2D illustrates examples of graphs and processes associated with storing graph information, according to various embodiments of the present disclosure.

[0025] Figure 3A is a flowchart of an example process of traversing an electronic graph associated with a goal, according to various embodiments of the present disclosure.

[0026] Figure 3B is a flowchart of an example process for constraining user actions according to user role, according to various embodiments of the present disclosure.

[0027] Figure 4 is a flowchart of an example process for determining a path through an electronic graph associated with a goa, according to various embodiments of the present disclosure 1.

[0028] Figure 5 is a flowchart of an example process for analyzing information associated with completions of goals, according to various embodiments of the present disclosure.

[0029] Figure 6 is a flowchart of an example process for assigning users to user roles, according to various embodiments of the present disclosure.

[0030] Figures 7A-7C illustrate example interactive user interfaces for creating an electronic goal, according to an embodiment of the present disclosure.

[0031] Figure 8 illustrates a computer system with which certain methods discussed herein may be implemented.

[0032] Figures 9, 10A-10B, and 11 illustrate example notifications or reports, according to various embodiments of the present disclosure.

[0033] Figures 12A-12C illustrate example block diagrams of the system, according to various embodiments of the present disclosure.

[0034] Figures 13A-13C are flowcharts of example processes for email integration of the system, according to various embodiments of the present disclosure.

[0035] Figure 14 is a diagram illustrating example associations of threads with engagements by the system, according to various embodiments of the present disclosure.

[0036] Figures 15A-15G are diagrams illustrating example email integration of the system, according to various embodiments of the present disclosure. [0037] Figures 16A-16B, 17, 18A-18D, and 19A-19H illustrate example user interfaces of the system, according to various embodiments of the present disclosure.

DETAILED DESCRIPTION

[0038] Although certain preferred embodiments and examples are disclosed below, inventive subject matter extends beyond the specifically disclosed embodiments to other alternative embodiments and/or uses and to modifications and equivalents thereof. Thus, the scope of the claims appended hereto is not limited by any of the particular embodiments described below. For example, in any method or process disclosed herein, the acts or operations of the method or process may be performed in any suitable sequence and are not necessarily limited to any particular disclosed sequence. Various operations may be described as multiple discrete operations in turn, in a manner that may be helpful in understanding certain embodiments; however, the order of description should not be construed to imply that these operations are order dependent. Additionally, the structures, systems, and/or devices described herein may be embodied as integrated components or as separate components. For purposes of comparing various embodiments, certain aspects and advantages of these embodiments are described. Not necessarily all such aspects or advantages are achieved by any particular embodiment. Thus, for example, various embodiments may be carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other aspects or advantages as may also be taught or suggested herein.

Terms

[0039] In order to facilitate an understanding of the systems and methods discussed herein, a number of terms are defined below. The terms defined below, as well as other terms used herein, should be construed broadly to include the provided definitions, the ordinary and customary meaning of the terms, and/or any other implied meaning for the respective terms. Thus, the definitions below do not limit the meaning of these terms, but only provide exemplary definitions.

[0040] User Input (also referred to as“Input”): Any interaction, data, indication, etc., received by the system from a user, a representative of a user, an entity associated with a user, and/or any other entity. Inputs may include any interactions that are intended to be received and/or stored by the system; to cause the system to access and/or store data items; to cause the system to analyze, integrate, and/or otherwise use data items; to cause the system to update to data that is displayed; to cause the system to update a way that data is displayed; and/or the like. Non-limiting examples of user inputs include keyboard inputs, mouse inputs, digital pen inputs, voice inputs, finger touch inputs (e.g., via touch sensitive display), gesture inputs (e.g., hand movements, finger movements, arm movements, movements of any other appendage, and/or body movements), and/or the like. Additionally, user inputs to the system may include inputs via tools and/or other objects manipulated by the user. For example, the user may move an object, such as a tool, stylus, or wand, to provide inputs. Further, user inputs may include motion, position, rotation, angle, alignment, orientation, configuration (e.g., fist, hand flat, one finger extended, etc.), and/or the like. For example, user inputs may comprise a position, orientation, and/or motion of a hand or other appendage, a body, a 3D mouse, and/or the like.

[0041] Data Store: Any computer readable storage medium and/or device (or collection of data storage mediums and/or devices). Examples of data stores include, but are not limited to, optical disks (e.g., CD-ROM, DVD-ROM, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), memory circuits (e.g., solid state drives, random-access memory (RAM), etc.), and/or the like. Another example of a data store is a hosted storage environment that includes a collection of physical data storage devices that may be remotely accessible and may be rapidly provisioned as needed (commonly referred to as“cloud” storage). Accordingly to certain implementations of the present disclosure, data stores may be encrypted, e.g., end-to-end-encrypted, to prevent unauthorized access or modification of data stored therein.

[0042] Database: Any data structure (and/or combinations of multiple data structures) for storing and/or organizing data, including, but not limited to, relational databases (e.g., Oracle databases, MySQL databases, etc.), non-relational databases (e.g., NoSQL databases, etc.), in-memory databases, spreadsheets, comma separated values (CSV) files, eXtendible markup language (XML) files, TeXT (TXT) files, flat files, spreadsheet files, and/or any other widely used or proprietary format for data storage. Databases are typically stored in one or more data stores. Accordingly, each database referred to herein (e.g., in the description herein and/or the figures of the present application) is to be understood as being stored in one or more data stores.

[0043] Goal: A step or intermediate state towards an outcome in a computer- assisted transaction. For example, a transaction involving obtaining signatures from multiple individuals may comprise multiple goals, wherein obtaining each signature is one goal. One goal may comprise multiple sub-goals or tasks, which may be sub-forms, form sections, or other action items. A goal may comprise a portion of an engagement module, and/or may comprise all or part of a plurality of engagement modules.

Example Systems and Methods

[0044] Embodiments of the disclosure will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the disclosure. Furthermore, embodiments of the disclosure may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the embodiments of the disclosure herein described.

[0045] According to various embodiments, disclosed herein is a system (e.g., the engagement optimization system 100 described below) that can monitor an overall state associated with completion of a plurality of electronic goals associated with electronic engagements, and can enforce constraints on user actions of users according to information associated with each user, such as a user role assigned to the user.

[0046] According to various embodiments, the system of the present disclosure provides efficient electronic management of engagements, including various interactive user interfaces, electronic messaging integration, and a graph -based workflow platform that manages user roles and permissioning. As used herein, the term“engagement” refers to any kind of interaction between two or more parties. Examples of engagements include, but are not limited to, transactions such as business deals, financing deals, investment deals, and the like. For illustrative purposes, the term“transaction” is frequently used within the present disclosure, but it is to be understood that such description applies similarly to various other types of engagements. [0047] As is described in detail below, and according to various implementations, user roles can be created, with each user role being associated with particular permissions, security rights, access rights, and so on, and based on these associations, the system can enforce constraints on available actions that each user can perform. For example, an electronic goal can include two entities performing a complex series of tasks associated with an engagement (e.g., to complete a contract, a venture financing round, stock transfer, and so on), and particular user roles (e.g., counsel, executive/partner roles, information technology roles, and so on) may have distinct actions that can be performed based on a state of the progression of the goal. For instance, a counsel for a first entity (e.g., a venture capital firm) may prepare an initial term sheet or contract (e.g., as will be described herein, the system can analyze a provided contract/term sheet, and utilizing one or more ontology models and/or machine learning models, extract terms for presentation), while executives for the first entity may be required to negotiate and ultimately sign the term sheet/contract before the goal can progress. Similarly, a second entity (e.g., a company requesting funding from the venture capital firm) may review, negotiate, and ultimately sign, the term sheet/contract. An example step (e.g., a step can represent one or more grouped tasks) can be associated with executing a term sheet or contract, and upon the first and the second entities execution of the term sheet or contract, subsequent steps can be accessible, such as agreement with respect to core financing, closing of the transaction, and so on. For simplicity, the present disclosure may refer interchangeably to contracts, term sheets, and documents as illustrative examples when describing the functionality of the system with respect to various types of engagements. However, any types of suitable documents or groups of documents may be used in the system in any type of engagement.

[0048] As used herein, a graph may describe relationships between nodes, such as edges connecting each node to itself or one or more other nodes, and can be stored as a graph data structure, stored in relational databases (and/or other suitable databases) along with information describing the relationships (e.g., adjacency lists, matrices; incidence lists, matrices; and so on). As will be described below, each node of the graph can be associated with a particular task to be performed, and upon completion of the particular task, the system can traverse to a subsequent task via an edge. Each task can optionally be completed based on particular actions performed by one or more users, for instance a task to negotiate documents can include actions of (1) uploading a particular document and providing it to a negotiating user, (2) indicating approval, by all negotiating users, to the particular document, and optionally uploading other documents for discussion, messaging users, and so on. As described above, the graph can be associated with completing an electronic goal, and the nodes can be arranged such that one or more paths (e.g., a path can represent a traversal of edges along a same direction towards completion of the goal) can cause completion of the goal. Linkages between nodes in the graph may represent possible (e.g., logically valid) transitions between goals, or various tasks within a goal. Advantageously, this may allow the user to interact with the system sequentially, in a way that may be considered an implementation of a wizard, assistant or expert system.

[0049] The system can monitor progression through the graph (e.g., completion of tasks), and can determine a present state associated with the progression. In this specification, a state describes one or more of, a present task that is to be completed (e.g., by a user or user role), or optionally one or more tasks that are to be completed (e.g., by different users or user roles), an elapsed time since the goal was initiated, an estimated time remaining (e.g., as will be described, the system can monitor progression of multitudes of goals till completion, and determine estimates of remaining times along with other information, such as preferred paths through graphs, and so on), and other information indicative of a progress associated with completion of the electronic goal. Through monitoring progression and determining present states, the system can present useful information to users indicating (1) whether they have a particular task to complete, (2) a particular user role or user that is to complete a particular task, (3) a recommended path to traverse based on the state (e.g., the system can determine a particular task to subsequently complete based on a present), and so on. For example, the system can present information identifying “a current task,” “a task owner” (e.g., as described below tasks can be assigned to particular users or user roles), and so on, ensuring that users are aware of any actions they need to take.

[0050] User roles can be created and assigned to users of the system (e.g., users can create user accounts and indicate their role with respect to completion of the goal), for instance a first user role may be associated with an attorney, while a second user role may be associated with an executive; other example user roles are described in detail herein, and in general a user role can be any definable role. Each task may optionally be assigned to a particular user role, a particular user assigned the particular user role, and so on. In this way, each task may have one or more owners, and these owners can ultimately trigger the completion of the task. As an example, a task can include executing a term sheet, document, or group of documents. For this example task, a user role associated with an executive can be assigned the example task, such that only a user assigned as an executive can cause the completion of the task (e.g., the user can upload an executed term sheet or document). As will be further described, particular tasks can be delegated to other users of other user roles, while the system may disallow delegation of other tasks (e.g., with respect to the example of an executed term sheet or document, the system can disallow delegation to a user role that wouldn’t normally bind a company, such as an outside counsel, employee, manager, information technology employee, and so on).

[0051] In an embodiment, users may be assigned the roles of primary and secondary owners of a goal, wherein the primary owners can either take an action related to the goal themselves, or delegate such action to a secondary owner. The secondary owners may then take actions that were delegated to them by a primary owner. Additionally, the secondary owners can affirmatively request the primary owners to have an action delegated to them. Advantageously, this allows the primary owners to efficiently delegate aspects of a goal as desired, while still remaining in control of the entire process. The system may comprise various default configurations comprising pre-assigned roles of primary and secondary owners for certain types of engagement, which may then be customized by the primary owners to reflect their preferences.

[0052] Optionally, the graph can indicate a particular user role that is to be assigned each task, for instance the system can store information describing assignments. With respect to the above example of venture capital funding and/or completing a contract, the system can store information indicating tasks to be completed by attorneys, executives, members of a board, shareholders, and so on. In this way, when a new task is traversed to via an edge from a completed task, the system can determine users that are to complete the new task. As is be described, the system can present information to the determined users indicating the assignment (e.g., ownership of the task), and the system, or other users, can provide notifications to the determined users regarding completion of respective tasks. Additionally, and as described above, to limit confusion with respect to complex goals, the system can present (e.g., in one or more user interfaces, such as in a web page being rendered on user devices of users) information identifying a current task that is to be completed along with one or more users assigned the current task. In this way, each user can rapidly determine (1) a present task to be completed (e.g., a task, according to the graph, that causes progression towards the goal), (2) one or more users assigned the present task, and (3) the ability to provide notifications to the assigned users.

[0053] As is described in detail below, the system of the present disclosure provides for customizable engagements through the use of modular, interoperable, and independent or semi-independent sets of functionality referred to as“engagement modules”. Engagement modules include respective sets of various goals, steps, and/or tasks, including various users and associated roles for completing those goals, steps, and/or tasks, all of which are managed by the system via the graph-based workflow described herein.

[0054] Thus, the system can traverse through the graph towards completion of goals according to completion of tasks assigned to users, and upon completion of a task, the system can assign subsequent tasks to users. Optionally, upon completion of a task, the system can traverse to a subsequent task according to user actions implemented during completion of the task, or subsequent to completion, and based on engagement module associated with an engagement. With respect to the example of venture financing and/or completing a contract described above, one or more tasks can be associated with executing a negotiated term sheet/contract between two entities (an example of an engagement module). Subsequent to completion of the one or more tasks, a user of the system can select the subsequent task to be completed. For instance, the user can interact with a user interface and indicate that one or more subsequent tasks are to be associated with performing a due diligence process (an example of another engagement module). Alternatively, the user can interact with the user interface and indicate that one or more subsequent tasks are to be associated with executing core financing documents (an example of yet another engagement module). In this way, users can have a level of autonomy with respect to traversing the graph and completing the goal. For instance, the users may prefer to execute the core financing documents first, while the due diligence process is temporarily put on hold, or while the due diligence process is ongoing. However, the system can ensure that tasks not appropriate for assignment at particular states cannot be inappropriately traversed to (e.g., the users may not be allowed to execute final contracts for the venture funding or other deal absent determination of core financing documents or other types of documents). Further description related to users selecting subsequent tasks is included below.

[0055] As described above, the system can constrain user actions available to be performed according to a state associated with completion of goals associated with various engagement modules. For example, while users are negotiating a document, users (1) that are not associated with the negotiation may be constrained in one or more actions until the document is negotiated (e.g., the users may not be able to provide revisions to the document, comment on the document, and so on), or (2) that are associated with the negotiation may be allowed to perform actions associated with completion of the negotiation (e.g., sign the document, generate revisions, and so on). As described below, e.g., with respect to Figure 3B, the system can enforce constraints on user actions based on limiting user interface interactivity with respect to user interfaces presented on user devices of particular users, or the system can receive user actions and reject the received user actions according to the constraints. As an example, the system can modify user interfaces, such as hiding,‘greying’ out, or otherwise limiting interactivity with particular portions of user interfaces and engagement modules, such that constraints on user actions can be enforced. Optionally, a user interface presented to a first user can be simplified according to enforced constraints (e.g., the system can modify or update a particular user interface, such as a template, according to the constraints), while a user interface presented to a second user may have expanded functionality (e.g., the second user may be assigned a current task, or be otherwise able to perform particular actions). In this way, the system can enforce a role-based security/permissioning model with respect to user actions of users, thus ensuring that actions for completing complex goals remain sharply in focus to users. For example, a particular user can determine that he/she is assigned a task (e.g., as described above, the system can present information identifying assignments of tasks), and similarly constraints on the user actions he/she can perform can be enforced, thus increasing a likelihood that the task is quickly completed (e.g., the particular user can determine that he/she is to obtain signatures on a document, and his/her user actions can be limited to contacting users, providing the document to them, uploading the executed document to the system, and so on). [0056] While the description above generally described a single graph of the graph- based workflow platform being associated with completion of a goal, additionally the system can maintain, access, and so on, graphs associated with disparate user roles and disparate engagement modules of disparate engagements. For instance, a graph for a user role associated with an attorney may indicate tasks that attorneys are to complete, with the tasks being connected via one or more edges to other tasks. Similarly, a graph for a user role associated with an executive may indicate tasks that the executives are to complete. In this way, each user role can traverse through respective graphs, and upon completion of the tasks, the overall goal or goals can be completed. Optionally, completion of a task in a graph for a first user role may affect a different task in a graph for a second user role, and the system can update the different task according to the affectation. For instance, the system can constrain, or enable additional, user actions for the different task based on the completion of the task associated with the first user role. As an example, a task associated with the first user role can include negotiation of particular terms and/or clauses to include in one or more contracts. Upon completion of the negotiation, the negotiated terms and/or clauses can affect one or more different tasks associated with the second user rule. For instance, based on the selected terms and/or clauses, particular documents may need to be executed, drafted, and so on, by users assigned the second user role.

[0057] Since multiple graphs can be utilized by graph-based workflow platform of the system according to respective user roles, optionally each node can indicate tasks, actions, and so on, which are required to be completed for the system to traverse to the node. For instance, users assigned a first user role can complete a particular task, and the subsequent task may indicate that users assigned a second user role complete a different task before the subsequent task can be assigned to the first user role. In this way, the system can ensure that tasks are assigned when it is logically appropriate, and each node can be associated with information describing necessary tasks, actions, and so on (e.g., the system can store information with each node, such as logical condition information maintained with a graphical structure, or the system can store information with each edge connecting nodes, and the system can ensure that the logical conditions are satisfied prior to traversing the edge to a node). [0058] Based on stored information associated with a graph (e.g., information indicating, nodes, edges, and so on), for instance a graph associated with completion of a goal or a graph associated with a particular user role, the system can monitor progress associated with completion of the goal via the graph-based workflow platform. At any state within the graph, a user of the system can request that the system provide a current task to be completed and optionally a subsequent task to complete. That is, the system can determine an optimal path that will move progress towards the goal, for instance a path with the least action (e.g., least complexity, least number of tasks, a path determined to result in a least amount of time based on the system monitoring historical completions of similar goals, and so on). The optimal path can be based on progress information associated with the goal, optionally in combination with historical information. For example, the system can determine that tasks involving particular actions (e.g., negotiation of terms or specific terms; gathering of complex information, for instance while performing due diligence tasks; and so on) have taken longer than a threshold (e.g., longer than a median time with respect to completion of other tasks, longer than a median time for historical completions of the determined tasks, and so on), and can prefer a path that limits the extent to which tasks involving the particular actions are to be assigned. The system can utilize historical information (e.g., monitored progress information associated with other users that previously completed goals) to determine paths that resulted in a fastest completion time, least number of actions, and so on, and can compare the historical information with a presently occurring goal. Optionally, the system can utilize machine learning models (e.g., trained using historical information associated with previously completed goals) to determine an optimal path through the graph, for instance based on features of the presently occurring goal (e.g., information describing the goal, types of user roles required, statistical information such as completion times for particular tasks, and so on). In this way, the system can ensure that goals are completed efficiently, and can further update and refine paths over time through monitoring multitudes of goals. In all situations in which historical information, private information, and so on, is utilized by the system, the system can enforce privacy restrictions specified by users, or can anonymize data, or require that users‘opt-in’ to use of their data.

[0059] In addition to efficiently guiding users towards completion of complex electronic goals, for instance through (1) constraining user actions, (2) traversing to specific tasks towards the electronic goal, and so on, the system can perform complex analyses on documents, information, and so on, provided by users to democratize complex electronic goals through simplifying the routing and sharing of documents and information. Thus, the present disclosure further includes, according to various embodiments, email integration and workflow customization of the system.

[0060] As further mentioned below, the’781 Publication incorporated by reference above also describes various user interfaces and functionality of the system for interacting with users in various engagements/transactions, which user interfaces and functionality, in various embodiments, may be integrated into the system of the present disclosure.

[0061] According to various embodiments, the term“user” is used herein to refer to any individual, group of individuals, organization, legal entity, or the like that may interact with the system.

[0062] Figure 1 illustrates an example engagement optimization system 100 in communication with user devices (e.g., user devices 110A-110N). As described above, the engagement optimization system 100 can enable users of user devices 110A-110N to complete a plurality of electronic goals, for instance through constraining user actions 112 of the users and traversing one or more graphs of the graph-based workflow platform of the system. The one or more graphs may be associated with various engagement modules of various engagements with which the users are associated, as further described below. The engagement optimization system 100 can be a system of one or more computers, or a system of one or more virtual machines executing on a system of one or more computers, and can be in communication with user devices 110A-110N via one or more networks (e.g., the Internet). The user devices 110A-110N can include laptops, mobile devices, wearable devices, tablets, computers, and so on, and can present user interfaces 102 to users of the user devices 110A-110N. Additionally, the engagement optimization system can access, store, maintain, and so on, one or more databases storing graph information 120 associated with one or more electronic goals. In various implementations, the engagement optimization system 100 may be implemented via one or more computer system, including computer executable instructions (e.g., modules, engines, etc.), as described herein and below in reference to Figure 8. As used herein, the term“system” and/or“engagement optimization system” may refer to the engagement optimization system 100 alone or in combination with one or more other aspects, devices, systems, and/or functionalities of the present disclosure. In some implementations,“system” and/or“engagement optimization system” may include a subset of the aspects, devices, systems, and/or functionalities of the engagement optimization system 100, alone or in combination with one or more other aspects, devices, systems, and/or functionalities of the present disclosure.

[0063] The system 100 can store and maintain user account information associated with users of the user devices 110A-110N, for instance the users can access the system 100 and create user accounts. As is described below, for instance with respect to Figures 7 A, users can be invited to participate in completion of one or more electronic goals associated with engagements/transactions, and users can cause the initiation of electronic goals. Each user can indicate a user role he/she is to be assigned during an engagement, or the user may be assigned the user role from one or more other users, and the system 100 can store the assignment. As described above, each user role can be assigned one or more tasks associated with various engagement modules, and user assigned the user role can be constrained in user actions they can perform.

[0064] The system 100 maintains graph information 120, for instance in one or more databases 120 or one or more storage subsystems, and can utilize the graph information 120 to traverse one or more graphs associated with completion of one or more electronic goals. Accordingly, the system may provide a“graph-based workflow platform”. The graph information can be maintained as relational information stored in the graph information database 120 (e.g., relational databases or other types of databases), for instance one or more tables describing nodes along with tables indicating relationships between the nodes. Additionally, tables can be utilized to describe, or reference stored locations that indicate, conditions (e.g., logical conditions) that when satisfied, cause the system 100 to traverse to a subsequent node via an edge. For instance, the system 100 can determine that conditions associated with a particular node are satisfied (e.g., completion of a task indicated by the particular node, such as a user uploading an executed document for storage by the system 100), and the system 100 can access one or more tables describing relationships between nodes, and identify a subsequent node. However, since the particular node may have edges to two or more nodes, the system 100 can determine a particular one of the two or more nodes to traverse to, for instance based on user actions performed during the particular node. Determining a particular node from two or more nodes to be traversed is described in more detail below, with respect to Figure 3A-3B. Thus, in the relational information case, the system can be required to (1) access tables indicating nodes, and utilize the accessed tables to identify a present task to be performed, (2) monitor progress associated with the present task, and determine completion of the present task, (3) access tables indicating relationships between nodes, and identify one or more nodes connected via edges to a node associated with the present task, and optionally (4) determine which of the identified nodes is to be traversed.

[0065] Since maintaining a graph as relational information can be complex, involve complex memory operations (e.g., complex joins, and so on), require greater processing power, and so on, the system 100 can optionally utilize a NoSQL database, such as a database that implements a graph data structure. The graph data structure may be represented in the database in various ways, including using adjacency lists (e.g., each node being assigned an identifier, such as an integer, and each edge being represented by a tuple of two node identifiers). The graph data structure can store, and directly access, nodes that represent tasks, with each node indicating one or more of, (1) actions associated with completion of the task, (2) actions that can be performed based on user role (e.g., a particular user role can be constrained in the actions users assigned the particular user can role can perform), and (3) an assignment of the node to a particular user or users assigned a particular user role. Additionally, the graph data structure can store information indicating edges between nodes, with the edges optionally indicating one or more of: (1) a directionality between the nodes, or (2) logical conditions indicating relationships between the nodes. For instance, and as will be described below with respect to at least Figure 2B, upon completion of a particular node (e.g., completion of a task indicated by the particular node), the system 100 can identify a subsequent node according to edges from the particular node and optionally user actions with respect to the particular node or subsequent to completion of the particular node. As an example, subsequent to completion of the particular node, the system 100 can present a particular user with two or more options to proceed, and based on the particular user’s selection, the system 100 can traverse to a node associated with the selection. In this way, the graph data structure can simplify representation and access of a graph associated with an electronic goal. [0066] The graph information database 120 can therefore maintain one or more graphs as graph information, such as a graph data structure, relational database information, adjacency, incidence, matrices or lists, and so on. An example of such graph information, and further description regarding the same, is included in the’781 Publication. As described above, a particular user, or a particular user role, can be assigned Task A, and the system 100 can monitor user actions of, for instance, the particular user. Upon completion of Task A, the system 100 can traverse from node to node, and the system 100 can assign another user, or user role, to Task B. In this way, the system 100 can determine a state associated with progress towards an electronic goal.

[0067] Furthermore, particular user actions of users may not cause completion of a task, and instead may cause the system 100 to remain on a particular task. For instance, a node (e.g., associated with‘Task C’), may include edges connecting to subsequent nodes (e.g., associated with‘Task D,’ and‘Task E’). As is described below, for instance with reference to Figure 3A-3B, upon completion of node’’Task C”, the system 100 can determine which edge to traverse. In contrast, another edge may connect node“Task C” to itself (a graph with loops in it may be referred to as a pseudograph), and yet a further edge can indicate user actions that when performed, do not cause progression towards an electronic goal. For example, a particular user may be assigned Task C, and the task may indicate that the particular user is to provide an executed document to the system 100. The particular user can perform other user actions in addition to provide an executed document, for instance the particular user can provide a comment for viewing by other users (e.g., a comment with respect to the document), the particular user can provide a different document (e.g., a supporting document), and so on. These user actions, optionally known as supportive actions, may result in a loop, and only upon completion of Task C will the system 100 traverse to a subsequent node.

[0068] As described herein, users of the user devices 110A-110N can interact with the system 100 via user actions 112 with respect to user interfaces 102 received from the system 100, and further via electronic messages 113 and notification information 102 sent to and by the system 100. As used herein, the terms “electronic messages”, “notification information”,“email”, and the like are used interchangeably to include any and all suitable types of electronic communications including, but not limited to, SMS, MMS, email, and other open or proprietary messaging formats or protocols. For example, the system 100 can generate interactive documents (e.g., web pages) for presentation on the user devices (e.g., rendered by the user devices), with the interactive documents enabling the users to provide user actions 112, view progress information associated with an electronic goal, generate notifications to be provided to other users, and so on. Additionally, each user device can execute an electronic application (e.g., an‘app’ downloaded from an electronic application store), and the executed electronic application can generate user interfaces 102 for presentation. The system 100 can receive information from, and provide information to, the electronic applications, and the electronic applications can present information received from the system 100. Example user interfaces 102 are described herein, with respect to various figures, including user actions with respect to the user interfaces 102. Further example user interfaces 102 are described in the’781 Publication mentioned below. For instance, users can upload documents for storage by the system 100, access documents uploaded by other users, engage in discussions with other users, electronically sign documents. As described above, based on a present state associated with progress towards an electronic goal, the system 100 can enforce constrains on user actions. As an example enforcing constraints, the system 100 can modify user interfaces 102 to limit available functionality that can be performed (e.g., the system can limit particular users from uploading or viewing documents, while enabling other users to upload, discuss, and otherwise negotiate documents).

[0069] The system 100, as described above, can be in communication with one or more user devices (e.g., user device 110), and a user of a user device 110 can view, interact, with user interfaces 116 presented on the user device (e.g., via a display of the user device, such as a touch screen display).

[0070] The system 100 is in communication with, and optionally maintains, a user information 128 database that stores information associated with users of the system 100. Users can utilize user interfaces 116 to create user accounts with the system 100, such as creating a user name / password, and optionally user profile information such as a name, address, phone number, and so on. As is described below, e.g., with respect to FigureS 6 and 7A, users can indicate respective user roles, such as whether they are attorneys, executives, employees, or an arbitrary role, with respect to particular electronic goals. The system 100 can store information identifying available user roles for selection according to a particular electronic goal for which users are trying to complete, and the system 100 can enable selection of one of the available user roles. Optionally, the system 100 can require verification of a user role, such as requiring one or more already registered users to indicate acceptance of a new user and user role, requiring documentation be provided verifying a new user’s role, and so on.

[0071] Additionally, users of the system 100 can cause the system 100 to cause one or more notifications 102 to be provided to potential users, requesting that the potential users create user accounts with the system 100 to fulfill particular user roles. As an example, the system 100 can present information indicating all present users and associated roles, along with user roles that do not have assigned users, and a user of the system 100 can request that the system 100 generate notifications to a particular email address, phone number, application executing on a particular user device, and so on, requesting that a potential user fulfill an unassigned user role.

[0072] The system 100 is further in communication with, or optionally maintains, a data storage database 129 that can store documents, images, video, or any arbitrary information that is received from, or is made accessible to, users of the user devices (e.g., user device 110). With respect to an example electronic goal associated with venture capital funding engagement, the system 100 can store revisions of documents, such as contracts, and users of the system 100 can access the documents, electronically execute the documents, and so on.

[0073] Data, for example the data included in databases 120, 128, andl29, can be encrypted and/or permissions can be associated with portions of the data. For example, all access to data included in databases 120, 128, andl29can be mediated through a database layer wherein software layers (e.g., user interfaces) invoke the database layer (e.g., through an API) for all database accesses. Data permissioning can be enforced through channels implemented on the database layer. Data related to each user, engagement, and/or each engagement module (e.g., related to individual goals or tasks of the engagement) can be partitioned, e.g., into section or documents, and each partition (e.g., each document) can be associated with a set of channels or access permissions. Each channel or access permission may associate one or more partitions with one or more users authorized to access the respective partitions. For example, a user may be granted access to a set of channels based on their user roles in the transaction (e.g., goal). Each user can be granted access to a partition if the access permissions associated with the user comprise at least one access permissions granting access to the partition contain at least one channel associated with that partition. The enforcement of access permission can be implemented at the database layer by matching the list of document channels and user granted channels; advantageously, this may allow conforming layers on top of the database layer to the permissions model implemented by a database layer.

[0074] As described below, for instance with respect to Figures 7A-7C, the system 100 can enable an initial selection of engagements, engagement modules, and thereby electronic goals (e.g., a user interface 116 presented to a user can present options for initiating an engagement and selecting associated engagement modules and the associated one or more electronic goals, and the user can further select information such as, names of entities involved in the engagement, and so on). Based on the initial selection of the engagement, the system 100 can access graph information 120 associated with the engagement and/or engagement modules. As described above, graph information 120 can indicate tasks that are to be completed for completion of the engagement, and can indicate particular user roles that are to be assigned each engagement module and/or task. Based on the selection of the engagement and engagement modules, the system 100 can indicate user roles that are required for completion of the engagement (e.g., an executive level officer of a company may be required for a venture funding round to be completed).

[0075] The system 100 includes a user role action engine 108 that can (1) cause assignment of users to particular user roles (e.g., a user role with respect to a particular entity involved in the electronic goal, for instance a venture capital funding firm or a company interested in receiving venture funding, and so on), (2) determine constraints on user actions for enforcement based on a present task, and (3) determine assignments of tasks to particular users or particular user roles. As described above, users of the system 100 can create user accounts (e.g., provide a user name, password), and indicate their user role with respect to the selected electronic goal. The user role action engine 108 can maintain assignment information (e.g., in the user information database 128), and can further cause notifications 102 to be provided to potential users requesting that the potential users create user accounts for the selected electronic goal. As described in detail below, e.g., with respect to Figure 3B, the user role action engine 108 can monitor a present task assigned to a particular user or user role, and can enforce constraints on user actions that can be performed. For instance, a present task may include negotiating a term sheet or contract, and the user role action engine 108 can constrain user actions with respect to executing a final version prior to particular users indicating consent to the negotiated term sheet or contract.

[0076] The system 100 also includes an electronic message engine 131 that provides electronic notification functionality. For example, the electronic message engine 131 can generate emails/notifications 102 to be provided to users of the system 100, for example notifications can be automatically generated by the system 100 periodically (e.g., after a threshold amount of time), in response to completion of tasks or particular actions that were performed, and optionally users can subscribe to notifications being received from the system 100 based on specified conditions. As in more detail below, notifications can provide summary information describing progression of the selected goal, and can include particular tasks that have been completed (e.g., within a threshold period of time), particular tasks that are to be completed, tasks that are to be completed by a particular user or particular user role, and so on. As an example of subscribing to notifications, specified conditions can include updates of particular users, particular user roles, updates associated with a particular entity (e.g., with respect to a venture financing goal, a user can subscribe to updates from an investing company and/or a company receiving venture financing). For instance, a user (e.g., an executive) can subscribe to updates, such as completions of tasks or specific actions (e.g., the user can specify that he/she is interested in receiving updates regarding executions of documents, negotiations, new versions of documents, and so on), and the system 100 can generate and provide notifications (e.g., in substantially real-time, or the system can obtain a threshold number of updates, or wait a threshold amount of time, to provide notifications). The system 100 can maintain subscription information, for instance in one or more databases (e.g., the user information database 128), and can associate the subscription information with particular user accounts. Additionally, the system 100 can store, or receive information indicating (e.g., from a particular user or user role), subscription information for all users, a portion of users (e.g., users associated with a same entity as the particular user), a portion of user roles, such that a base-line can established, ensuring that all or particular users associated with a same entity receive update information. Further functionality of the electronic message engine 131 as related to email integration is described below.

[0077] The system 100 also includes a workspace engine 133 that provides workspace functionality. In general, and according to various embodiments, the system includes a“workspaces”, which comprise conceptual, virtual, or actual segmentations or arrangements of information or data. These workspaces may include user-level workspaces (“user workspaces”) and engagement- level workspaces (“engagement workspaces”). The workspace engine 133 manages and implements the various workspaces of the system, including permissioning and storage of related data (e.g., in the databases 120, 128, and 129, as described above). Various user interfaces of the system may be associated with user workspaces and/or engagement workspaces. For example, the system may provide a user interface associated with a user workspace that may provide a user with a view, and interaction with, their roles and various engagements with which they are associated (see, e.g., Figure 17 providing an example user interface including a listing of all engagements associated with a user representing Organization A). As another example, the system may provide a user interface associated with an engagement workspace that may provide various users (individually or simultaneously) views, and interactions with, various aspects of an engagement and engagement modules of the engagement (see, e.g., Figures 16A-16B, 19G- 19H, and various example user interfaces described in the’78l Publication; see also example reports illustrated in Figures 9, 10A-10B, and 11). Advantageously, according to various embodiments, the system provides engagement workspaces as collaborative spaces that are accessible by many users (e.g., users associated with the engagement) to facilitate efficient execution of an engagement. Further description of the functionality of the workspace engine 133 is provided below.

Example Graph-Based Workflow Platform Functionality

[0078] Notifications 102 can include emails generated by the system 100 which are provided to email addresses associated with users, with the emails optionally graphically depicting updates. For example, an email generated in response to a particular document being uploaded to the system (e.g., for storage in the data storage database 129) can specify the action (e.g., document uploaded) along with information describing the document, and can graphically depict a state associated with progression of an electronic goal (e.g., a particular task, a particular step, and so on). Additionally, the email can include selectable elements that can be associated with references (e.g., links) to the system 100. For instance, a selectable option can be associated with causing a user device presenting the email to navigate to a particular content item (e.g., web page) that presents information related to the notification, or enables user actions related to the notification (e.g., signing a document, uploading and document, making one or more comments visible to other users, and so on).

[0079] The system may generate certain emails based on substituting information into a template, which may be similar in many aspects as discussed herein with reference to contract templates. The user may also be able to respond directly to the notification (e.g., clicking on a link inside an electronic message, responding to an email message, etc.), thus triggering a corresponding action in the system. To securely determine a connection between a response (e.g., a response email from a user, or a request from a user’s web browser following a link in an email) and the corresponding user, each email may comprise an identification token, such as a user identifier, which may then be used by the system to find the user associated with the response. For example, a user may be able to perform a variety of actions or tasks by responding to an email from the system, such as sending requests to other users to perform a task, granting permissions to other users to perform a task, sending reminders or follow-ups to other users related to a task, inviting new people to a transactions (e.g., allowing new user accounts to be created), completing a task (e.g., uploading a document or confirming that a certain action, such as a review, has been performed).

[0080] An example notification 202 (e.g., email) is illustrated in Figure 2A, with the notification 202 providing summary information associated with actions, completions of tasks, and so on. In this example of Figure 2A, completion of a particular task is indicated 204 (e.g., the notification 202 indicates that a particular user role, investor counsel, is ready to sign term sheet documents) along with the particular task’s location within a step (e.g., as described in the’781 Publication with respect to Figures 8 and 9A-9H, executing an initial term sheet can be a step that includes multiple tasks, such as negotiating the term sheet or contract, signing the term sheet or contract, and so on). As described above, the system 100 can access graph information associated with an engagement module, and utilizing the graph information the system can determine tasks associated with particular goals. As illustrated, an initial task (e.g., negotiating a term sheet) has been completed (e.g., the email graphically depicts the completion, which in the example includes a solid circle next to a textual descriptor of the initial task), and a next task/goal is to begin (e.g., signing the negotiated term sheets). The next task or goal may be associated with the same or a different engagement module. As described above, this next task/goal (e.g., signing the term sheets) can be assigned to one or more users or user roles, which in the example of Figure 2A has been assigned to counsels (e.g.,‘Investor Counsel,’ representing a counsel for an entity that is investing money into a company). The notification 202 further includes a selectable option 208, which upon selection or interaction, can cause a user device presenting the notification 202 to navigate to a content item (e.g., web page) presenting‘more details’ as illustrated.

[0081] While Figure 2A describes a notification 202 being an email, it should be understood that notifications 102 can encompass one or more other types of electronic information being provided to users. For example, a notification 102 can include a message (e.g., an SMS, MMS, message) being provided to a user, or a notification 102 can include activation of an application executing on particular user devices and presenting, via the application, information. For instance, the user device 110 can include an application engine 114, with the application engine 114 optionally being an electronic application (e.g., the electronic application can be downloaded from an application store) in communication with the system 100. As an example, the application engine 114 can periodically poll the system 100 for updates (e.g., notifications 102), or the system 100 can provide notifications 102 to the application engine 114 (e.g., as a push). For example, in some implementations the application engine 114 may be a general purpose web browser that is communicating with the system 100 (and/or other computers/systems) to receive and send data, and provide interactive user interfaces. In another example, in some implementations the application engine 114 may be an email application, a plug-in to an email program, and/or a combination of the two. In some implementations multiple application engines, of similar or different types, may be used simultaneously by a user and/or by multiple users via one or more user devices.

[0082] As described above, the system 100 can interact with users of user devices (e.g., user device 110) via user interfaces 116 presented to the users. Optionally, the system 100 can further interact with users through emails, with the emails specifying identifiers associated with particular tasks, and with the emails enabling users to provide information to the system 100 which may cause the system 100 to (1) update user interfaces 116, for instance update user interfaces for particular users to specify information received in an email, (2) update particular tasks, (3) cause completion of particular tasks, and so on. As an example, the system 100 may assign a particular task to a user, for instance uploading a particular document, and the user can access user interfaces 116 to upload the particular document. Optionally, the user may utilize his/her email program, app, web interface, and so on, and draft an email that specifies a particular email address (e.g., an engagement- specific email address and/or a universal platform email address, as described below) associated with the system 100, and which includes the particular document attached. The system 100 can receive the email, identify the user, and based on the assignment of the user to a task associated with uploading a document, may determine that the task has been completed. Optionally, the email may include a reference to the task, such as a unique identifier (e.g., a string of characters, numbers, that uniquely identify the task), a textual description of the task (e.g.,‘attached is the [name] document - please execute’) and the system 100 can parse the textual description to identify the task.

[0083] To facilitate collaboration across users and tasks, system 100 may also provide a platform for communication amongst users or groups of users, such as a messaging system or chat. Advantageously, tasks, goals, documents, etc. may be mentioned or embedded in messages sent by a user, and can thus be immediately accessed by a recipient or recipients of the message. For example, where a user mentions an action or goal in a message (e.g.,“sign form 14”, review document X”), the system may create links or references to those actions, goals, documents, etc. so that they can be quickly accessed or performed. A user may be also able to use the communication platform to contact support; this may include either a human representative, or a chatbot, artificial intelligence, or expert system that interacts with the user in a way similar to human interaction.

[0084] In response to receiving an email associated with a particular task from a particular user, the system 100 can update user interfaces 116 presented to the particular user and/or other users. With reference to the example above, the particular user can attach a document to the email, thus completing the user’s assigned task, and the system 100 can update user interfaces presented to other users indicating a subsequent task to be performed (e.g., signing the document). In this way, interactions with the system 100 are not constrained solely via interactions with user interfaces 116, and can be expanded. Optionally, users can text (e.g., through SMS, MMS) a particular number associated with the system 100, and the system 100 can similarly parse the text, obtain attachments to the text (e.g., an MMS message may contain an attachment, or the text can include a link to a cloud storage location and download an attachment, and so on).

[0085] Optionally, the goal optimizations system 100 can enable persons who have not created user accounts with the system 100 to be assigned user roles, and perform user actions 112. For example, while a user is interacting with the system 100, a particular action, or task, may be required to be performed by a different user (e.g., as described above, constraints on user actions can be enforced by the system 100, such that to perform an action or complete a task, a particular or particular user role can be required), and the user can request that the system 100 generate a notification 102 to be provided to a person who can act as the different user. As an example, the system 100 can indicate to the user that a particular user role (e.g., counsel) is required to perform an action, or to complete a task, and the user can interact with the system 100 to specify one or more of (1) a name of a person who can function as the particular user role (e.g., an attorney), (2) contact information (e.g., email address, and so on. The system 100 can generate a notification 102, and provide the notification 102 to the person. The person can receive the notification 102, and optionally create a user account (e.g., as described above), or optionally perform actions in response to the received notification 102 (e.g., as described above, the person may respond to an email with instructions the system 100 can parse, including attaching a document). With reference to a task associated with providing a document, the system 100 can provide a notification 102 to the person (e.g., an email describing that the person is to provide a document, and further describing an electronic goal, identifications of the entities, and so on), and the person can respond to the notification with an attached document. In this way, the person may not be required to create a user account, and can instead perform a limited function which can reduce a burden on people interacting with the system.

[0086] Similar to the above description regarding interactions via emails, in contrast to a person responding to an email requesting the person perform one or more actions, the email can include a selectable object, which upon interaction, can cause a user device utilized by the person to navigate a secure content item (e.g., web page) associated with the system 100. The person can then utilize the secure content item to perform actions, for instance upload a document. That is, the system 100 can create secure sessions, for instance secure web based tokens which can optionally expire after the person performs specified actions, after a threshold amount of time, or any user definable conditions.

[0087] Optionally, each task or user action associated with a graph can correspond with a type of event. Each type of event can be associated with a set of email templates, and each email template can be designed for one or more user roles associated with the graph. When a user action is performed, the system can query the email template associated with the user action. Based on the user role associated with each email template, the system can query a list of users being in that role. Those users are the receivers of the emails. The system can then compose email content for each of the users by querying the state of the transaction and the user’s information (e.g., the state associated with a graph is described above). The queried data can be applied to the template to compose a specific email content. Once the email content is ready, the system can provide a request to an email server to send out that email.

[0088] Furthermore, each email sent out by the system can indicate an identification token that allows the system to determine the context of the email. When a user replies to a system-sent email, the token can be sent back together with the reply content. Once the system receives an email, the system can identify the token to determine the context of the email (e.g., the intended discussion channels, the corresponding action in the workflow, particular task or step, and so on). Depending on the context of the email, certain actions can be automatically performed by the system, e.g., import the email content to a discussion channel, or upload an attachment to a document sharing channel. In this way, users can interact with the system via emails.

[0089] The system 100 can optionally analyze and/or parse documents received from users, and can present summary information describing the documents. For instance, as described in the’78l Publication in reference to Figures 16A-G, 17A-170, and 18, the system 100 can utilize ontologies to indicate particular terms (e.g., negotiated terms) and associated values of the particular terms. The system 100 can present information summarizing large complex documents (e.g., contracts), such that important features of the documents can be quickly presented in user interfaces 116 to users. As an example, the system 100 can analyze multitudes of contracts, and based on machine learning techniques (e.g., the system 100 can process a training set of contracts and terms identified in the set of contracts, and can generate rules associated with identifying portions of contracts that include terms) can parse received contracts and rapidly obtain terms. Optionally, the system 100 can store ontology information indicating synonyms for terms, textual language that is associated with each term (e.g., a relevant portion of a contract that identifies a particular term may be a full paragraph long, a portion of a paragraph, and so on), and so on. In this way, the system 100 can identify terms in a contract (e.g., negotiated terms, for instance as described in the’78l Publication in reference to Figures 8 and 9A-9H), and present summary information to the user indicating values of the terms, and/or present portions of the contract that include the identified terms.

[0090] Figure 2B illustrates example tasks (e.g., Task A 210 and Task B 212) identified in an example graph (e.g., directed graph) associated with one or more engagement modules and associated electronic goals. As described above, the system 100 can monitor progression through a graph associated with engagements and associated one or more engagement modules. The graph can include nodes associated with tasks, with the nodes connected via edges to one or more other nodes. Each node can assigned to a particular user, or particular user role, and the assigned user, or any user of the assigned user role, can cause completion of an associated task. For instance, a task can be associated obtaining a fully executed version of a document (e.g., contract), and a particular user role (e.g., attorney) can be assigned the task. The attorney can cause completion of the task upon providing a fully executed document (e.g., the document can include signatures from executives, board members, and so on) for storage in the system 100.

[0091] As described above, the system 100 can assign a task, for instance Task A 210, to a particular user role (e.g., User Role A) based on information associated with an electronic graph that includes Task A 210. That is, the system 100 can access information indicating assignments of user roles to specific tasks includes an electronic graph, and upon completion of a prior task, the system 100 can assign a subsequent task (e.g., Task A 210) to a particular user role. The assignment information can be generated, or specified, by users of the system 100, for instance using the system 100 the users can select an engagement module or create an electronic goal, specify nodes to include in an associated electronic graph (e.g., the users can indicate particular tasks to be completed), and further specify assignments of tasks to particular user roles. As an example, the system 100 can optionally present user interfaces that include functionality for selecting engagement modules to associate with an engagement, and/or creating tasks (e.g., a user of the system 100 can manipulate user interface elements, such as ovals, circles, and so on, and connect them together to form an electronic graph), defining actions that cause completion of the created tasks (e.g., the user can indicate particular conditions that must be satisfied before a task is to be completed, such as uploading documents, confirming terms, sharing documents with other users or user roles, and so on), optionally defining constraints on user actions of user roles not assigned each created task (e.g., the user can indicate that for a task assigned to counsel, other users may not be able to upload documents, created revisions of documents, and so on). In this way, when traversing through an electronic graph, the system 100 can access information indicating assignments of each traversed node (e.g., assignment of associated tasks) to a particular user role.

[0092] As illustrated in Figure 2B, Task A 210 is assigned User Role A (e.g., User Role A is specified as an owner of Task A). That is, User Role A (e.g., any user assigned User Role A) can cause completion of Task A 210 based upon performance of particular user actions. A user assigned User Role A can request that the system 100 present information identifying one or more of, (1) a description of Task A 210, (2) a task owner (e.g., the system 100 can indicate that the user is the owner), (3) user actions that can cause completion of Task A, (4) a location of Task A 210 with respect to an electronic graph (e.g., a step in which Task A 210 is located, a graphical depiction of the electronic graph, such as a depiction hat can be zoomed into and from which the user can view detailed information describing each task), optionally other information including an amount of time the user has spent on the task. In this way, a user assigned User Role A can easily ascertain that they have been assigned Task A, and what particular user actions are required of them to cause completion of Task A.

[0093] Upon completion of Task A, the system 100 can identify an edge connecting Task A 210 (e.g., a node associated with Task A) and Task B 212 (e.g., a node associated with Task B). Optionally, there may be more than one edge such that a task different from Task B 212 may also be a potential next task to be completed. As described above, optionally the system 100 can determine which edge to follow based on particular user actions performed during Task A 210. For example, to complete Task A 210, a user assigned User Role A may have to ultimately upload a particular document, however prior to uploading the particular document, the user may have one or more optional user actions. For instance, the user may select a format associated with the particular document, may include particular terms in the particular document, may perform a user action that requires an intermediary task to be performed prior to Task B 212 being assigned (e.g., a particular user role may have to approve inclusion of certain terms, and so on). In this way, the system 100 can traverse from Task A 210 via a particular edge based on the user actions performed. Optionally, information associated with each edge (e.g., maintained in a graph database structure as described above) can indicate conditions for the system 100 to traverse the edge to a subsequent node (e.g., Task B 212).

[0094] As illustrated in Figure 2B, Task B 212 is assigned to a user of User Role B, and upon the assignment, optionally the user can receive a notification indicating the assignment, view user interfaces generated, at least in part, by the system 100 that indicate the assignment along with a description of Task B 212, any required user actions associated with its completion, and so on. The assignment of Task B 212 to User Role B can be determined, as described above, based on maintained information associated with the electronic graph.

[0095] Additionally, the assignment of Task B 212 to User Role B can be based, at least in part, on user actions that were previously performed. For example, Task A 210 may have been a task associated with determining terms associated with contract. Depending on the precise terms determined, a different user role may be assigned Task B 212. For instance, the terms may generally be associated with intellectual property concerns, and the system 100 can determine that Task B 212 is to be assigned to an intellectual property counsel role. In contrast, the terms may generally be associated with corporate issues, and the system 100 can determine that Task B 212 is to be assigned to a corporate counsel role. The system 100 can analyze, or obtain information indicating, the determined terms, and assign Task B 212 to a user role that is most (e.g., commonly) associated with the terms.

[0096] Optionally, certain tasks may be assignable to more than one user role, and the system 100 can cause the assignment of Task B 212 to a single user role (e.g., the system 100 can select the user role from a multitude of user roles) or assignment of Task B 212 to two or more user roles (e.g., users of either user role can cause completion of the Task B 212). For example, certain tasks, such as obtaining signatures from a multitude of other users, can be assignable to multiple user roles (e.g., counsel, secretary, and so on). The system 100 can access information indicating the multiple assignment, and can select either a counsel (e.g., attorney) or secretary to be assigned Task B 212, or can allow users of either user role to be assigned. Additionally, when selecting a single user role to be assigned Task B 212, the system 100 can obtain information indicating response times, completion times, and other information relevant to a rapidity with which users of a particular user role complete tasks. The system 100 can prefer assignment of Task B 212 to a user role that completes tasks faster. Optionally, the system 100 can access information indicating a frequency with which users of each user role confer with other users, how close in proximity they are, and so on, such that users of a particular user role might be more apt to perform the task (e.g., obtain signatures from other users).

[0097] As described below, for instance with respect to Figure 6, the system 100 can, in general, monitor statistical information associated with electronic goals, such as timeliness of particular users (e.g., how quickly each user completes tasks, completes actions assigned to them, and so on). Utilizing the statistical information, the system 100 can indicate users that are moving electronic goals forward, and if there is an option to select multiple users to be assigned a task, the system can prefer 100 assignment of a timely user. For example, as illustrated in Figure 2B, Task B 212 has been assigned to User Role B. The system 100 can access information identifying users assigned User Role B (e.g., as described above, with respect to Figure 1 users can be assigned a user role upon creation of their user accounts) and can select a particular user assigned User Role B based on the statistical information. That is, the system can designate a particular user (e.g.,‘Jane Doe’) be assigned completion of Task B 212, and only the particular user can complete Task B (e.g., other users assigned User Role B may be able to perform user actions for which other user roles are constrained, however only Jane Doe may be able to cause completion of Task B 212).

[0098] Figure 2C illustrates tasks separated into example steps (e.g., Step A-Step D 220-250), which can result in completion 224 of an electronic goal or one or more engagement modules. As described above, a graph (e.g., a directed graph) can be associated with completion of an electronic goal or one or more engagement modules, and optionally the graph can include nodes (e.g., associated with tasks) that are grouped into particular steps. That is, a step can represent a group of nodes, such that discrete steps associated with the engagement module(s) can be maintained. The system 100 can present information indicating a particular step users are on. Since a particular task may not be readily identifiable to all users, the system 100 can present a description of a step for better ease of understanding, and optionally a graphical depiction of the electronic graph for example as illustrated in Figure 2C (e.g., tasks grouped in steps, optionally a present step can be highlighted or otherwise identified).

[0099] As illustrated, Step A 220 of the graph can be an initial step, and the initial step can include a multitude of tasks 222. Upon completion of Step A, either Step B 230 or Step C 240 can be traversed to, and a particular user can indicate which step is to be next completed. That is, upon completion of a final node grouped into Step A 220, the system can 100 can identify two edges connecting the final node to initial nodes of Step B 230 and Step C 240. The system 100 can then traverse one of the edges based on, as described above, a user selection of a next step.

[0100] Optionally, the system 100 can enable a subset of users to be assigned tasks within Step B 230, and a different subset to be assigned tasks within Step C 240. That is, if the tasks in Step B 230 are independent from the tasks in Step C 240, then the system 100 can optionally allow the tasks to be performed at a same time. The system can optionally ensure that a same user isn’t assigned a task from both Step B 230 and Step C 240 (e.g., such that the same user can focus on one step), or optionally the system 100 can allow assignments from each step (e.g., a particular user, such as a supervisory user, can specify whether this is to be allowed).

[0101] Based on a selection of a particular step, for instance Step B 230, the system 100 can optionally constrain user actions associated with Step C 240. That is, the system 100 can grey out user interface elements (e.g., as will be described below with respect to Figure 3B) associated with Step C 240. For instance, Step B 230 can be associated with performing a due diligence process (an example of an engagement module that may be part of an engagement), and Step C 240 can be associated with performing a core financing process (an example of another engagement module that may be part of an engagement), and upon selection of Step B 230, the system can limit user actions associated with core financing, such as access to user interfaces describing the core financing processing, reviewing core financing documents, and so on. Examples of user interfaces and functionality associated with such steps are described in the’781 Publication.

[0102] As illustrated, Step D 250 requires completion of both Step B 230 and Step C 240, for instance an edge associated with an initial task grouped in Step D 250 can specify conditions, and the conditions can indicate that both (1) Step B 230, and (2) Step C 240, has been completed. In this way, steps can be logically separated, and accessed based on conditions, ensuring that users begin particular steps at appropriate times.

[0103] In various implementations, by utilizing one or more electronic graph (as described herein), the system may advantageously represent and enforce workflows and dependencies. For example, a typical process cycle of a task involving a legal document may include iterative creation by legal drafters, a review process by executives, the distribution to various parties for signing, and the collection of signatures. It may be undesirable to skip steps during this process; for example, it might be desirable to prevent non-reviewed documents from being distributed for signing. Advantageously, by using an electronic graph (e.g., as described herein in reference to various figures), the various permissible transitions may be represented as links, and the non-permissible as an absence of links. Thus, the system may be able to easily represent complex workflows involving multiple tasks, parties, and participants. Various tasks may be aggregated or combined, for example by providing means for batch signing, batch sharing or batch downloading related to tasks.

[0104] In various implementations, certain aspects, e.g., engagement modules, may be associated with their own flows or graphs. As mentioned above, such flows or graphs, e.g., may enable an efficient negotiation that moves the aspect from drafting internally and sharing, to counterparties in iterative cycles. Advantageously, once an iteration finalizes (e.g., through ready-to-sign, sign, and exchange states), in some implementations the flow can be reversed, providing optimal flexibility around negotiation.

[0105] Further, in some implementations the system also includes flows or graphs including batch processing of documents for download/upload/sharing/etc. In some implementations, these flows or graphs may be further integrated with editing/redlining and parsing of legal terms (e.g., as described herein). [0106] Figure 2D illustrates various graphs or graph-like relationships (which may comprise data structures or databases), and various structures that may be used to represent them. Graph 262 is an example of an undirected graph, wherein the numbered fields 0-9 comprise nodes and the lines connecting the nodes represent relationships. Clusters 268 shows example clusters, which may be considered as a set of graphs which may be disjoint. Data structure 266 represents an adjacency list which may be used to represent a graph or cluster, such as graph 262 or cluster 268. Advantageously, adjacency lists, such as data structure 266, allow storing of graphs in memory efficiently, particularly where the graphs are lightly-connected graphs or clusters (e.g., graphs or clusters wherein the number of nodes is high compared to the number of linkages per node). Adjacency lists 266 may also allow for efficient adding and removal of nodes, e.g., as an operation in constant time, as entries related to nodes that are not connected to the added or removed nodes may not need to be accessed. Data structure 264 is an adjacency matrix, which may also be used to represent a graph or cluster, such as graph 262 or cluster 268. Advantageously, adjacency matrices such as data structure 264 may allow for more efficient storage and processing of highly- connected graphs or clusters, e.g., where the number of connections per node is comparable to the number of nodes. Adjacency matrices such as data structure 264 may also allow for more efficient access and processing, particularly vectorized access and processing (e.g., using specialized hardware or processor instructions for matrix math), to the graph or cluster data because each matrix row corresponding to a node may have the same size irrespective of the number of linkages by node. As described here, various data items may be stored, processed, analyzed, etc. via graph-related data structures, which may provide various storage and processing efficiency advantages described. For example, as shown in Figure 2D, advantages of graph-related data structures may include: built to handle high volume, highly connected data; efficient in computing relationship queries than traditional databases, either using adjacency matrices, or adjacency lists; can easily add to the existing structure without endangering current functionality; structure and schema of a graph model can easily flex; new data types and its relationship; evolves in step with the rest of the application and any changing business data requirements; can easily add weights to edges; can use Optimal amount of computer memory, etc. [0107] Figure 3A is a flowchart of an example process 300 of traversing an electronic graph associated with a goal (e.g., an engagement module or an aspect of an engagement module or engagement). For convenience, the process 300 will be described as being performed by a system of one or more computers (e.g., the system 100).

[0108] The system identifies a task to be completed by a particular user role (block 302). As described above, the system can access a graph associated with completion of an electronic goal. Users involved in the electronic goal and create user accounts with the system, or optionally as described above can perform actions, complete tasks (e.g., as described above, a task can require performance of one or more actions), and so on, without creating user accounts, and the users can be assigned tasks for completion. In this way, daylight into complex electronic goals can be established, and users can always be aware of who is assigned a present task and what actions the present task entails. Therefore, the system can identify a present task and a particular user role that is assigned completion of the task.

[0109] The system presents information to users associated with the particular user role (block 304). Upon identification of a present task (e.g., as described above, the system can access a graph, and based on traversing edges, can arrive at the present task), the system can present information to users assigned the particular user role the assignment of the identified task.

[0110] The system accesses graph information 306, and in response to completion of the present task, identifies one or more subsequent tasks based on the graph information (block 308). The system determines completion of the present task based on actions associated with the present task being performed. As described above, the system traverses the graph and identifies subsequent tasks connected via edges to the present task. The system can determine a particular subsequent task to be assigned based on, for example, user actions performed during the present task. That is, the system can access the graph information (e.g., database 306), and determines whether conditions associated with edges to the subsequent task are satisfied (e.g., a first edge may indicate a condition associated with uploading a particular document, while a second edge may indication a condition associated with uploading a different document). [0111] Figure 3B is a flowchart of an example process 310 for constraining user actions according to user role. For convenience, the process 310 will be described as being performed by a system of one or more computers (e.g., the system 100).

[0112] As described above, users of the system can interact with the system via user interfaces presented on user devices (e.g., laptops, computers, tablets, mobile devices, wearable devices), with the user devices enabling the users to perform user actions, such as communicating with other users, uploading documents, reviewing documents or other information, generating revisions of documents or other information, electronically executing documents, or the like.

[0113] The system can enforce constraints on user actions that can be performed based on a state associated with progression of the goal, with the state indicating at least a present task that is assigned and optionally a particular user role associated with the present task. Similar to a role-based security model, in which permissions (e.g., access rights to files, network devices, and so on) can be defined on a role basis, and users assigned particular users, the system can enforce constraints on user actions available for to users based on (1) a present state, and (2) a type of user role of each user. In this way, users can be guided towards completion of a present task, for instance the system can constrain user assigned user roles not relevant to the present task while limiting user actions of users assigned to the present task to user actions relevant to completing the present task. This gentle nudging of users, via constraints on user actions, can enable users to have clear insights into the sorts of actions that are appropriate based on a present state associated with completion of the goal. Furthermore, through a role-based security model, the system can limit an extent to which user roles not relevant to a present task can interfere with progression of the goal. For example, if a present task is associated with determining and uploading (e.g., for negotiation) a term sheet, the system can allow counsel (e.g., attorneys) to upload term sheets (e.g., revisions of term sheets), while constraining other user roles to upload term sheets. In this way, the other user roles can review and approve (e.g., sign) the uploaded term sheet, and/or can provide feedback to counsel regarding specifics of the term sheets which the counsel can implement (e.g., upload a new revision of the term sheet).

[0114] The system determines a state associated with progression of electronic goal (block 302). As described above, the system can access graph information, and identify a present task assigned for completion. The determined state can indicate the present task, a particular user or user role assigned the present task, and so on.

[0115] The system determines constraints on user actions capable of being performed by users of disparate user roles (block 314). The system can store information indicating user actions that can be performed by (1) users of a user role assigned the present task, and (2) users of user roles not assigned the present task. As an example, the graph information (e.g., as described above, with respect to Figures 1 and 2A-2D) can indicate constraints on user actions (e.g., a subset of a total amount of user actions), or specific user actions that are capable of being performed by each user role. Since certain user roles, while not assigned a present task, may have relevance to completion of the present task, these certain user roles can be allowed to perform specific user actions. For example, a present task can be the preparation and uploading of documents, and can be assigned to counsel (e.g., in- house attorneys), with the documents requiring signatures of executives or board members. Therefore, the executives or board members may be capable of viewing the uploaded documents, commenting on the uploaded documents, optionally redlining the uploaded documents, but not be allowed to themselves upload a new version of the documents. Additionally, for a task associated with obtaining signatures of executives or board members, the task may similarly be assigned to counsel, while the executives or board members may be constrained to (1) review the documents, (2) electronically execute the documents, and/or (3) make comments (e.g., a chatroom may be provided).

[0116] The system enforces constraints (block 316), which can optionally include updating user interfaces for each user role according to allowable constraints for the user role (block 318). The system can cause user interfaces presented on user devices to be updated in accordance with user actions a user of the user interface is capable of performing. For example, the system can generate content items (e.g., web pages) for presentation on user devices, and the content item can be tailored (e.g., modified from a base) depending on the determined state and determined constraints (e.g., as described above). Similarly, for an application (e.g., electronic application downloaded from an application store) executing on each user’s user device, the system can provide information to the application indicating the constraints, and the application can enforce the constraints (e.g., cause portions of a user interface to be hidden, greyed out, and soon). [0117] Similarly, the system can enforce constraints via rejecting or enabling user actions based on the determined constraints (block 320). For instance, the system can receive user actions via user interfaces presented don user devices, for instance a web application executing on the user devices, and can reject (e.g., in substantially real-time) received user actions based on determined constraints. As described above, users can optionally interact with the system via email, or other notifications, for instance users can provide an email that indicates or specifies (e.g., via a unique identifier) a particular task, along with user actions to be performed. Example user interactions can include the user specifying that a particular action has been performed (e.g.,‘I spoke with Jane Doe,’‘Jane Doe signed the document’, and so on), the user attaching a document to the email, the user making a comment that is to be available for viewing by other users (e.g., in a chatroom, in a workspace associated with an entity or same user role as the user). The system can enable or reject user actions indicated in notifications to be performed based on constraints associated with a person sending the notification. For instance, if the person has an associated user account, the system can access information identifying a user role assignment, and based on the determined constraints, reject or enable user actions. However, if the person does not have a user account (e.g., the person was contacted via a user to perform a particular action, as described above), the system can determine a user role that would be assigned to the person. For example, if the person was contacted by a user to perform a particular action, the system can determine a user role associated with person based on the particular action and optionally the determined state. Further functionality associated with added users is described below.

[0118] Figure 4 is a flowchart of an example process 400 for determining a path through an electronic graph associated with a goal. For convenience, the process 400 will be described as being performed by a system of one or more computers (e.g., the system 100).

[0119] As described above, the system can utilize graph information to inform a recommendation of a path through the graph, with the path indicating particular nodes connected via edges to subsequent nodes. Optionally, the graph can include unique paths from one or more initial nodes (e.g., a starting task associated with completion of the electronic goal) to one or more nodes associated with completion of the electronic goal. For instance, the graph can allow users to traverse the graph in a preferred way (e.g., a preferred way, limited according to edges connecting nodes), and arrive at completion of the electronic goal.

[0120] The system can determine a path (e.g., for recommendation to users, such as through a graphical depiction of the determined path, remaining tasks associated with nodes in the determined path, and so on) through the graph, with the path indicated as being a least active route. A least active route can represent a least complex route, such as a route that includes a least quantity of remaining nodes, a route that includes a least measure of central tendency of remaining nodes for each user role (e.g., this route may include a greater quantity of remaining nodes than the least quantity, but may be more easily spread across users lessening an overall burden on the users).

[0121] The system accesses graph information, and identifies a present task (block 402). As described above, for instance with respect to Figures 1, 2A-2D, and 3 A, the system can maintain and access graph information indicating tasks associated with completion of an electronic goal. The system can identify a present task, for instance a present task assigned to a user role, or optionally one or more present tasks assigned to different user roles (e.g., the system can access a graph associated with each user role).

[0122] The system determines tasks associated with a least active route to completion of the electronic goal (block 404). The system can determine a path of remaining nodes (e.g., nodes subsequent to a node associated with a present task) that results in a least active route to completion of the electronic goal. The system can optionally receive a request for a least active route from users (e.g., a user associated with a particular user role can request an identification of the path, or an identification of a subsequent task to perform, which can optionally be a path associated with all user roles, or a path associated with tasks assigned to the particular user role), and can determine the least active route in response. As an example, a user interface (e.g., the user interfaces described herein) can include a selectable object associated with the request, and a user can interact with the selectable object to provide the request to the system.

[0123] To determine the path, the system can, as described above, identify a path that includes a least quantity of remaining nodes or a least average (e.g., mean, median) quantity for each, or particular (e.g., user selectable, identifiable), user role. Additionally, the system can analyze the actions associated with tasks, and determine a path associated with a least average complexity of tasks, tasks that are expected to take a least amount of time, and so on. Optionally, the system can access information indicating an amount of time tasks are expected to take (e.g., negotiating a document may take longer than uploading a document for signature). The information can optionally be based on historical information for the present electronic goal, for instance the system can monitor times that each action have taken (e.g., average times), and can utilize the monitored times to inform a determination of the path.

[0124] The system optionally generates notifications and/or user interfaces to particular users associated with remaining tasks (block 406). Upon determination of the path, the system can present information to particular users, such as a requesting user, to all users that are to be assigned tasks in the path, all users that are to be assigned tasks within a threshold number of nodes (e.g., the system can provide information to users that are to be assigned tasks within the next threshold number of tasks) or within a number of nodes expected to be completed in a threshold time period, and so on.

[0125] The system can monitor progress along the graph, and upon any deviation from the graph (e.g., users can perform additional tasks not identified in the graph), the system can determine an updated least active path through the graph. Additionally, while Figure 4 generally describes determining a least active path through a graph, with the path indicating tasks, optionally the system can determine a path indicating steps (e.g., as described above, with respect to Figure 2C, tasks can be grouped into steps). For instance, with respect to Figure 2C described above, upon completing Step A 220, the system can determine a path that indicates the next step should either be Step B 230 or Step C 240. The system can utilize information described above, and further utilize historical information including whether prior users of prior electronic goals that utilized the same, or similar, graph, completed first when they followed Step A with Step B or Step C.

[0126] Figure 5 is a flowchart of an example process for analyzing information associated with completions of goals. For convenience, the process 500 will be described as being performed by a system of one or more computers (e.g., the system 100).

[0127] The system progression information associated with multitudes of electronic goals (block 502). As described above, the system can monitor progression through various engagements and associated engagement modules (e.g., based on determined states through associated graphs), such as an amount of time each electronic goal took to complete, statistical information associated with users and user roles (e.g., times each user took to complete tasks), and so on. Additionally, the system can determine orderings of tasks that each electronic goal took, which as described above, can include a specific series of tasks through graphs associated with the electronic goal.

[0128] The system can maintain this information for the multitudes of electronic goals (e.g., for analysis), and as described, can utilize the information to determine paths (e.g., recommended paths) through graphs associated with electronic goals. For all cases in which private or sensitive information is utilized, the information can be anonymized and/or privacy restrictions can be put in place. For instance, users can be required to‘opt-in,’ and private details with respect to progression of electronic goals can be removed. In this way, the system can maintain particular progression information, such as tasks that users completed, orderings of tasks, times each user took to complete tasks, and so on.

[0129] The system determines paths through graphs associated with electronic goals (block 504). As described above, with respect to Figure 4, the system can determine least active paths (e.g., for recommendation) such that users can receive an indication of a subsequent task to perform, or additional tasks included in a least active path. As users utilize the system, the system can determine (e.g., learn) optimal (e.g., least active) paths through electronic graphs (block 506). That is, the system can monitor quantities of time that each task takes (e.g., average times), and can determine an ordering of tasks that results in an electronic goal being completed in a least amount of time (e.g., least amount of time, lowest variance from a mean, and so on).

[0130] Additionally, through monitoring progression information, the system can utilize the monitored information to inform least active paths for newly created electronic graphs. For example, as described above users can create electronic graphs that include nodes associated with tasks (e.g., the users can further indicate a direction associated with edges connected nodes). Based on similarities of tasks with prior completed electronic goals, or similarities of actions included in tasks, the system can determine a least active path through a newly created graph, and can update the least active path as users complete the associated electronic goal. [0131] The system determines statistics associated with electronic goals (block 508). As described above, the system can monitor progression information across multitudes of electronic goals, and can determine statistics associated with electronic goals. For example, the system can determine an average time to completion of each electronic goal, an indication of a task or step (e.g., group of tasks) that takes a greatest amount of time (e.g., the system can indicate that users prepare for this task in advance), and so on. Additionally, the system can determine statistical information associated with each user, such as one or more of, (1) responsiveness of the user (e.g., how quickly the user completes tasks; how quickly the user responds to emails associated with an electronic goal, for instance as described above users can receive emails or other notifications from the system and can respond, which can cause completion of tasks, update user interfaces, and so on; how often the user accesses the system to determine a present state, for instance the system can present information identifying a current task, assignment of the current task to a user, and so on; how often the user causes notifications to be provided to owners of a current task, for instance as reminders; and so on), (2) quantities of electronic goals in which the user is included (e.g., the system can determine that particular users are utilized more often in electronic goals, indicating that the user is in high-demand, knowledgeable, and so on), (3) deviations from a least active path (e.g., the system can determine that the user deviates from the least active path, for instance through following edges that are not indicated in the least active path; the system can further determine that the user’s deviations cause refinements to the determination of the least active path, indicating that the user’s deviations result in lesser time to completion of an electronic goal).

[0132] Additionally statistics and analytics may include monitoring user actions, paths through graphs, time users spend moving from task to task or step to step, time users are waiting for actions from other users or parties, terms extracted from documents associated ontologies, and so on. Analytics can include detecting time associated with back and forth tasks in the graph, for example jumping between revising term sheets. Analytics can further include correlations between user roles in a graph and their time spent working on tasks, and/or correlations between terms and paths users follow in the graph. To determine one or more of the features described herein, frequent pattern analysis and/or anomaly detection methods can be utilized. Bad actors, for example users that consume too much time otherwise negatively affect progression towards a goal, can be identified by applying noise detection and canceling in the above described analysis and detection methods.

[0133] Additional examples and description associated with utilizing statistical information in a current electronic goal is described in the’781 Publication, e.g., in reference to Figure 6 of the’781 Publication.

[0134] Figure 6 is a flowchart of an example process 700 for assigning users to user roles. For convenience, the process 700 will be described as being performed by a system of one or more computers (e.g., the system 100).

[0135] The system generates notifications to be provided to users for registering as particular user roles (block 702). As described above, for instance with respect to Figure 1, users can create user accounts with the system, with the user accounts indicating a user role of an associated user. Furthermore, and as described above, the system can indicate required user roles for completion of electronic goals, and a user of the system can interact with one or more user interface elements to cause the system to generate a notification to be provided to a person associated with a required user role. For example, an electronic goal may require counsel (e.g., attorneys) for each entity (e.g., an attorney for a venture capital funding firm, an attorney for a company being invested in), and a user (e.g., a user associated with a same entity) can request that the system contact (e.g., email, text, activate an application executing on the contact’s user device) a person requesting the person function as counsel.

[0136] The system enables notified users to register, and create user accounts, with the system (block 704). As further described below, users that received notifications can register with the system, create a user account, and so on. Additionally, and as described above, the system can enable people to perform actions, complete tasks, and so on without creating user accounts (e.g., a person can receive an email requesting a particular action, such as providing a signed copy of a document provided in the email, and the person can respond to the email with the signed copy; follow a link in the email to a secure content item, and upload the signed document via the content item).

[0137] The system associates users with tasks to be completed (block 706). As described above, the system can identify nodes associated with tasks that are to be assigned to particular user roles. The system can optionally associate each user with tasks they are to complete, and can optionally present (e.g., via user devices of the users, such as through providing information to applications executing on the user devices, updating a presented web application, content item, and so on) describing the assigned tasks. Optionally the system can assign tasks to users as the system traversed an electronic graph and reaches nodes associated with tasks.

[0138] The system enrolls users associated with same user roles in one or more channels, such that activity within channel triggers notifications to enrolled users (block 708). As will be described below, users of a same user role, and optionally associated with a same entity, can communicate utilizing a chat room, forum, and so on, with the communications being private from other users. Additionally, a same communication channel can include users of multiple roles (e.g., executives and board members may have a channel specific to them).

Example User Interfaces

[0139] Various figures of the present disclosure illustrate methods, functionality, and example interactive user interfaces of the system. The example interactive user interfaces of the present disclosure may illustrate steps related to certain electronic goals. Each user interface is an example of an interactive user interface, which can be generated on a user device of a user, and can be presented based on hardware, software, features of the user device. For example, the user interfaces can update, or be modified, depending on whether the user device is a wearable device, laptop, computer, tablet, mobile device, and so on. The user devices can be modified in interactivity according to features of hardware of the user device, for instance while the user interfaces are presented on laptops, users can interact with the user interface via a first input method (e.g., mouse, keyboard), while the user interfaces are presented on tablets, mobile devices, touch screen laptops, users can interact with the user interfaces via a second input method (e.g., touch, speech, and so on). The input methods can cause updates to each user interface, such that user interface elements may be modified accordingly (e.g., a selectable object to perform an action on the first input method may be modified to be a slider on the second input method, and so on). Additional example user interfaces of the system are shown and described in the’781 Publication.

[0140] The user interfaces can, as described above, be generated by user devices presenting the user interfaces, and can optionally be generated, at least in part, by the system 100 (e.g., or a presentation system in communication with the system 100). That is, the user devices can execute applications associated with the system 100, and can present the user interfaces as generated by the applications. The user devices can then receive information from the system 100 (e.g., information associated with a current electronic goal) and can update the user interfaces with the information. Additionally, the user devices can present content items received from the system 100, which upon rendering, can depict the user interfaces. Optionally, the system 100 can, in part, control rendering or execution of the content item, for instance the user devices may receive dynamic content items (e.g., dynamic web pages), and/or the user devices may load web applications associated with the system 100.

[0141] Additionally, the particular engagement and user interface functionality described below are illustrative examples of use of the system 100, and other engagements can be similarly presented. For example, an engagement associated with creating a complex cloud-based network can be performed, an electronic goal associated with company merger, acquisition, an electronic goal associated with other contracts, deals, network security, and so on, can be performed.

[0142] The user interfaces can respond to user actions, or events, via one or more libraries. For example, a particular library can create a component and an observer pattern, such that the user interface can react to events. Optionally, any user action that modifies data or a state of the graph (e.g., traversal through the graph) can be performed server side (e.g., by the system, to ensure security compliance). Optionally, the client can be classified as a ‘thick web client,’ and it may take care of relaying events created by users to the system. In this way, the client can be quite fast as the system performs a lot of the heavy lifting, and the client can instead focus on constructing events that capture user’s intentions (e.g., actions) and then relaying them back to the system. A real time updating mechanism can safely and efficiently provide updates from the system to the client, and these updates may be calculated automatically by the system to only contain pieces that have changed (e.g., a diff on old data). In this way the system can avoid re-sending data that is already at the client, and can thus save bandwidth and processing power associated with the client.

[0143] In various embodiments of the example interactive user interfaces described below in reference to the various figures, various aspects of the user interfaces may or may not be included, may appear visually different, and/or may be arranged differently. [0144] Figure 7 A illustrates an example interactive user interface 710 for creating an engagement. The user interface 710 includes user interface elements for assigning a name 712 to each entity included in the engagement, which in the example is a venture capital firm and a company 714 being invested in. The user interface 710 further includes a type of funding 712 (e.g., as illustrated in Figure 7B, type of funding can include options such as Seed, Pre-Series A, Series A, Series B, Series C, or other options), an indication of a role of a user creating the engagement (e.g., as illustrated in Figure 7C, user role can include counsel, chief financial officer, general partner, and so on). Upon interaction with user interface element 720, the engagement can be created, and the system 100 can maintain information indicating the engagement. Optionally, user interface 710 can include options to select a particular one or more, or set of, engagement modules, for instance a user of the user interface 710 can select from a list of options, provide a description of engagement modules (e.g., type in a name, and the system 100 can match the name to a closest engagement module, verbally describe the engagement module, and so on).

[0145] The’781 Publication includes additional example user interfaces of the system. For example, Figures 8, 9A-9G, 10, 11A-11B, 12A-12D, 13, 14A-14D, 14F-140, 14Q1-14Q2, 14R, 15, 16D, 16F-16G, 17A-170, 22A-22D, and 23A-23H (and the associated descriptions) of the’781 Publication illustrate and describe interactive user interfaces and steps in various engagements / electronic goals, including user interactions to complete steps (e.g., create and negotiate a term sheet, perform due diligence, accomplish core financing, negotiating and executing ancillary documents, review documents/data room, obtain signatures, etc.) and move from one step /engagement module to another, inviting other users and assigning roles to users, interacting with“smart” or dynamic forms, taking administrative actions, interacting with ontology information associated with parsing of documents, interacting with statistical and summary information, interacting with comparisons of document versions, and the like.

[0146] The’781 Publication also describes further functionality of the system, including, e.g., example workflows of the system (e.g., in reference to Figure 14E of the’781 Publication),“smart” or dynamic forms of the system (e.g. in reference to Figure 14E-140 and 24A-24B of the’781 Publication), executing/signing documents (e.g. in reference to Figures 20, 21, 22A-22D, 23A-23H, 14C, and 14J-14P of the’781 Publication), automatic parsing of documents (e.g. in reference to Figures 16A-16G and 18 of the’781 Publication), and further user interactions to move from one step to another, etc.

Example Email Integration

[0147] Presently, email is the primary means of communication for many types of transactions. Recognizing this, according to various embodiments, in addition to the notification functionality described above, the system of the present disclosure advantageously further integrates email communications into the graph-based workflow platform to provide more efficient management of, accessing of, and interactions with, engagement-related information. Advantageously, according to various embodiments, the system provides for automatic parsing and analysis of emails sent to the system, and association of those emails (and related information and attachments) with particular engagement workspaces. Advantageously, according to various embodiments, the system provides for interaction with engagement-related information, including via email, with or without logging in to the graph-based workflow platform. Such functionality enables, for example, interactions with so called“engagement observers” with fewer obstacles and via a familiar communications channel (e.g., email). As described above, the system 100 includes an electronic message engine 131 that manages and implements the various email integration functionality of the system described herein.

Engagement-Specific Email Addresses

[0148] Email integration provided by the system may include engagement- specific email addresses. An engagement-specific email address may be a unique, dedicated email address that is associated with a particular engagement, and that is used by the system to route emails addressed to the unique email address to a workspace specific to the particular engagement. As an example, engagement- specific email addresses may have a format such as company.round.investor.id@example.com, engagement_ID@example.com, or the like.

[0149] For example, when sending an email with information or attachments related to a particular engagement to various recipients, the user may additionally send the email, or copy the email, to an engagement-specific email address associated with that particular engagement. Upon receipt of the email, the system may then route the email, based on the association between the unique engagement- specific email address and the engagement, to a workspace dedicated to that engagement. Such routing may include routing of any email attachments, and may further including parsing of information included in the email, and associated updates to a status (e.g., a task or goal) of the engagement. Such routing may further include extraction of the list of recipients included on the email, and association of those recipients with the engagement, as further described below. In some instances, as further described below, the system may address outgoing emails associated with the engagement to users/email addresses that have sent emails to the unique engagement-specific email address, or that have been other recipients of emails sent to the unique engagement- specific email address.

[0150] Advantageously, use of engagement- specific email addresses may enable users to synchronize their engagement-related communications happening outside the system with the system. Further, advantageously, use of engagement-specific email addresses may enable the system to easily gather all emails related to engagements into centralized locations/workspaces, thereby enabling the user to more easily keep the emails in the centralized location and more easily access past communications.

Universal Platform Email Address

[0151] Email integration provided by the system may also, or alternatively, include a universal platform email address. In this implementation, rather than, or in addition to engagement-specific email addresses, the system may have a single universal platform email address that emails associated with any engagement could be sent to. As an example, a universal platform email address may have a format such as assistant@example.com, or the like. Many of the advantages noted above with reference to engagement- specific email addresses may be available via the universal platform email address.

[0152] Upon receipt of an email addressed to the universal platform email address, the system may analyze various aspects of the email to determine an engagement with which the email is associated. Once determined, the system routes the email (and associated information, attachments, etc.) to the appropriate workspace dedicated to that engagement, and/or particular portions of that workspace, as described below in reference to Figures 13A- 13C. Analysis of emails addressed to the universal platform email address is further described below in reference to Figures 13A-13C. In some cases, if the system is unable to determine with a high degree of confidence an associated engagement, the system may enter a flow by which the user is prompted to identify a particular engagement, or confirm a likely engagement, as further described below in reference to Figures 13A-13C.

[0153] Advantageously, use of a universal platform email address may enable users to synchronize their engagement-related communications happening outside the system with the system. Further, advantageously, use of a universal platform email address enables a user to easily gather all emails related to engagements into centralized locations/workspaces without having to manually identify particular engagements when sending emails, and more easily access past communications.

[0154] In an implementation, the system may provide“organization-level email address” that may function similarly to the universal platform email address, but only allow routing of emails to engagements associated with an organization in the system.

User Engagement Inbox

[0155] In various implementations, the system may provide “user engagement inboxes” which include, for each user of the system, user-specific“inboxes”. In various implementations, such user engagement inboxes may be specific to each user and each engagement, and/or specific to each user and all engagement with which the user is associated. The inboxes include interactive user interfaces by which the user may interact with information associated with engagements. The inboxes may be subject to various permissioning, as described herein, such that the user may only be able to view information associated with the engagement that they are permitted to access. In an implementation, a user engagement inbox is similar to an email inbox, and includes, for a particular user and a particular engagement (or, in various implementations, all engagements with which the particular user is associated), all emails and attachments sent to and from the platform that included both the user as a recipient, and the engagement- specific email address(es) or the universal platform email address (assuming the system determined that the particular email was determined to be associated with the particular engagement(s)) as a recipient. In an implementation, a user engagement inbox is similar to an email inbox and provides useful inbox functionality such as the ability to compose new email, select members of the engagement as recipients, or add new email addresses. Via the user engagement inbox the user may reply to emails that have been captured by the platform, and may further select files from the system that are associated with the engagement. [0156] User engagement inboxes are further described below in reference to Figures 12A-12C, and comprise a subset of the“user workspaces” described below.

Email- Only Contacts

[0157] As mentioned above, the system may provide for interaction with engagement-related information, including via email, with or without logging in to the graph- based workflow platform. Such functionality enables, for example, interactions with so called “engagement observers” with fewer obstacles and via a familiar communications channel (e.g., email). For example, a user may interact with the system via email, both incoming and outgoing, without logging in to the system. Rather, the user may simply send engagement- related emails to the system (e.g., via engagement- specific email addresses or a universal platform email address), where they are associated with the engagement, and receive information back from the system via email (as further described below). Such users, as described below, may be authorized to access a no-login report associated with the engagement, and may receive weekly digest emails associated with the engagement. In some instances, such engagement observers may not need to be registered with the system (e.g., have a login to the system/platform, or have been invited to the system/platform), but may simply be associated with one or more engagements via capture of their email address on engagement-related communications. In various implementations, an“engagement observer” is only allowed to access information that is available to both sides of a transaction/engagement, and/or information to which the engagement observer has been granted access (e.g., by other users).

[0158] In various implementations, the system may automatically determine a role or organizational association of a new contact by analysis of the contact’s email domain, or other user information associated with the contact provided in the email (such as a signature line). Accordingly, in the example where such an“engagement observer” is allowed to log in to the system, the system may automatically determine appropriate information access based on an organizational association and/or role of the new user.

Example User Roles

[0159] In various implementations, the system may define tiers of users associated with an engagement/transaction, independent of the side/party to which user may belong. In an implementation, there are three general tiers: engagement team, engagement observer, and signatory. Users in the engagement team may be the hands-on operators of an engagement, who will receive activity notifications, have full access for their party, and be subscribed to weekly digest notifications. Engagement observer (also described above) users may be those that are following the main progress of the engagement, and that only receive weekly digest notifications and signature request. Engagement observers may be allowed to access the engagement details if they want to, and they can also opt- in to receive activity notifications. Signatory users may be those not actively participating in the engagement, but that are contacted when documents need to be signed. Such users may not receive activity notifications and weekly digest notifications, and they may only have access to the Sign Docs engagement module/interface in the engagement. Other tiers and arrangements of users may be implemented in the system.

Automated Email Information Organization

[0160] As noted above, emails (including any associated data and attachments) received by the system (e.g., via engagement- specific email addresses or a universal platform email address) may be analyzed and/or parsed, and the email information (including email contents, attachments, etc.) may be associated with the appropriate engagement workspace. In the instance of emails sent to an engagement-specific email address, the appropriate workspace is identified via the unique, dedicated email address. In the instance of emails sent to the universal platform email address, the appropriate engagement workspace is identified via an analysis described below in reference to Figures 13A-13C. In either case, the information included with the email is then analyzed in further detail for placement in the appropriate portions of the engagement workspace. The description below references email attachments, but a similar process may be applied to the contents of the email itself.

[0161] In particular, in an implementation the system may determine whether an attachment is to be placed in a“shared” portion of the engagement workspace, or a“private” portion of the workspace. Placement in a private portion may make the attachment available only to the user who sent the email. Placement in a shared portion may make the attachment available to any users who were recipients of the email. Alternatively, placement in a shared portion may make the attachment available to any users associated with the engagement. [0162] Shared portions of the engagement workspace may include any of the various engagement modules, or other portions, associated with the engagement, as further described below. For example, placement of the attachment in the“data room”, or in another engagement module associated with multiple users (e.g., a term sheet engagement module), may comprise placement of the attachment in a shared portion of the engagement workspace.

[0163] In an implementation, determination of the portion of the workspace into which the attachment is to be placed may be determined automatically. Automatic determination may be based on any combination of information associated with the attachment or email, including for example: email and/or attachment subject, email and/or attachment content, email recipient(s), and/or attachment filename. Such information may be used by the system to determine, for example, a type of attachment/document (e.g., term sheet, right of first refusal, etc.) and a status of the attachment/document (e.g., draft, unsigned, signed, etc.). In an example, multiple recipients on an email may be an indication to the system that the email and/or attachment is to be placed in a shared portion of the engagement workspace. In another example, at least one recipient on an email that is on another side of the engagement/transaction from the sender may be an indication to the system that the email and/or attachment is to be placed in a shared portion of the engagement workspace that is accessible to both sides of the engagement/transaction. In an embodiment, the user may opt-in to automatic determinations of attachment placement.

[0164] In an implementation, determination of the portion of the workspace into which the attachment is to be placed may be based on user input. For example, in an implementation the user may manually map the email/attachment to a particular portion of the engagement workspace. Such mapping may be provided via a user interface of the system, via an email tag (or other indication provided on the email), via an email client addon (as described below), and/or via another suitable method. Manual mapping may be prompted (e.g., via a user interface of the system, or via an email provided by the system to user, to which the user may respond) in response to the system failing to automatically determine a particular portion of the engagement workspace for placement of the attachment, or the system failing to automatically determine a particular portion of the engagement workspace with a sufficiently high degree of confidence. Similarly, the user may manually map the attachment if they determine that the system incorrectly placed the attachment in a portion of the engagement workspace. In an embodiment, the system may employ manual mapping if the user does not opt-in to automatic determinations of attachment placement.

[0165] In an implementation, the determination of the portion of the workspace into which the attachment is to be placed may be based on a determination of a suggested mapping by the system, followed by a user input confirming the suggestion (or providing an alternative mapping). In an embodiment, the system may employ suggested mapping if the user does not opt-in to automatic determinations of attachment placement, or, as described herein, suggested mapping may be employed even if the user does opt-in to automatic determinations but a threshold of confidence is not met. For example, when automatically making a determination of the portion of the workspace into which the attachment is to be placed, the system may automatically place the attachment in the event a threshold of confidence is met (e.g., based on the information described above), or may revert to a suggestion of one or more most likely (which may be ranked based on likelihood) portions of the workspace in the event the threshold of confidence is not met. Suggestions may be provided to the user via a user interface of the system, via an email client addon (as described below), via an email provided by the system to user to which the user may respond, and/or via another suitable method. Once the user provides a confirmation of the mapping to the system, the system may then proceed with placement of the attachment in the confirmed portion of the engagement workspace.

[0166] Advantageously, according to various embodiments, because the system provides engagement workspaces as collaborative spaces that are accessible by many users (e.g., users associated with the engagement), all the recipients on a given email may provide a mapping of the email/attachments to portions of the engagement workspace. In the event of mapping of the email/attachments to a shared portion of the workspace, such mapping can apply for all other recipients of the email. In various implementations, the system enables individual users to re-map already mapped emails, but such mapping may only be reflected in the user’s workspace.

Engagement Reports

[0167] Advantageously, in various embodiments, users associated with engagements may access reports/updates/notifications (each of these terms may be user synonymously throughout this disclosure) related to the engagement without logging in to the platform. The reports/updates/notifications may be presented as emails, notifications via applications on user devices, or web pages presented on browsers, and/or the like. As described above, reports/updates/notifications can be provided to users informing the users of state or status information.

[0168] Such reports may be provided to the users via email. Emailed reports may be provided any combination of periodically (e.g., daily, weekly, or monthly emails), upon the occurrence of engagement events (e.g., a document is signed, etc.), and/or in response to user requests. In an implementation, in response to the user sending an email to the system (e.g., via engagement- specific email addresses or a universal platform email address) with a specific short sentence or tag, the system automatically responds by sending a report email associated with the engagement of interest back to the user.

[0169] Figure 9 illustrates an example of a report email 902, viewable by the user via their email client of choice. As an example, the report email may include various information regarding the current status of the engagement. This information may include, e.g., an identification of the engagement 906, a status of the engagement 908, a list of engagement milestones and their respective statuses 910, an indication of the next actions to be taken and by whom 912, an indication of recent activity 914, and an indication of participants/users in the engagement 916. Different portions of the list of engagement milestones and their respective statuses 910 may correspond to various engagement modules of the engagement, as further described below. The indications of the next actions to be taken and by whom 912 may be determined based on the engagement modules associated with the engagement, and their respective goals/tums/graphs, as described throughout this disclosure. Various portions of the report email 902 may comprise selectable links which the user may select to be taken to interactive user interfaces of the system (e.g., user interfaces associated with particular portions of the engagement workspace, as described throughout this disclosure), the access of which may require login by the user.

[0170] Figure 2A described above illustrates an example email 202 provided to a user which indicates a next task or action 204. Figure 10A illustrates another example notification email 1000 specifying an identification of a user whose turn it is to perform an action (e.g., User A 1002). The email 1000 may be provided to User A 1002, or provided to other users (e.g., users working on a same entity or negotiating side as User A 1002, all users involved in the goal, and so on). The email 1000 further indicates an amount of time 1004 that the action or task has been pending. Via the email 1000, User A 1002 can select a hyperlink 1006 to complete the action or task. For example, the hyperlink may cause presentation of a user interface to complete the task. Email 1008 similarly indicates completion of a task or action, and indicates that it is Company A’s turn to complete the next action or task.

[0171] Figure 10B illustrates another example email 1010 providing an alternative version of a weekly report 1012, aspects of which may be combined with other reports examples described herein. The email indicates an expected date 1014 at which the goal is to be completed. As described above, the system can monitor multitudes of progressions through different goals and can determine statistical information. The system can therefore determine a total amount of time that each goal takes (e.g., a measure of central tendency). As the current goal progresses, the system can augment this average time according to empirically measured times that the current goal has taken to complete particular tasks or actions. Thus, the time 1014 can be adjusted from the average time. The email 1010 further includes an identification 1016 of the major tasks or steps that are to be completed for each engagement module associated with the engagement, and indicates whether they are on task for completion and optionally an estimated end date. The estimated end date can be determined according to previously monitored goals. The email 1010 further includes an identification of a turn 1018. As illustrated, the email indicates that it is Company A’s turn to perform the next task or action for the Term Sheet engagement module of the engagement.

[0172] Such reports may also be accessed by the user without logging in by selecting a link provided in an email (e.g., in an onboarding email as described below, and/or in an email sent to the user by the system, such the an automatic response email as described above), which link causes display of a report user interface provided by the system in, e.g., a web browser. Figure 11 illustrates an example of such a report 1102, which includes features similar to those of the example email report 902 described above (and aspects of which may be combined with other reports examples described herein). As an example, the report 1102 may include various information regarding the current status of the engagement. This information may include, e.g., an identification of the engagement, a status of the engagement 1104, a list of engagement milestones and their respective statuses 1106, an indication of task statuses and next actions to be taken 1110 (which may be accessible via selection or rollover of the button 1108), an indication of terms associated with the engagement 1112, and an indication of participants/users in the engagement 1116. Different portions of the list of engagement milestones and their respective statuses 1106 may correspond to various engagement modules of the engagement, as further described below. The indication of task statuses and next actions to be taken 1110 may be determined based on the engagement modules associated with the engagement, and their respective goals/tums/graphs, as described throughout this disclosure. Various portions of the report email 1102 may comprise selectable links which the user may select to be taken to interactive user interfaces of the system (e.g., user interfaces associated with particular portions of the engagement workspace, as described throughout this disclosure), the access of which may require login by the user. For example, the user may select buttons 1114 to access user interfaces associated with a term sheet engagement module of the engagement. The user may also select the button 1118 to share the report with another recipient (which may cause adding of the recipient to the engagement), or the button 1120 to view a more detailed checklist of engagement module statuses, actions to be taken, etc., the access of which may require login by the user.

Email Client Integration

[0173] In various implementations the system may include or provide an addon that may be installed in the user’s email client (e.g., Outlook, Gmail, etc.). Such an addon may provide, for example, a sidebar, window, popup, or other interactive user interface by which the user may log in to the system and access information and/or user interfaces of the system. Such an addon may provide a sidebar such as workspace addon sidebar 904 illustrated in Figure 9.

[0174] In various embodiments, the addon advantageously provides a connection between the user’s existing inbox/email client with the system (e.g., engagement workspaces and associated information and/or user interfaces). In an implementation, the user logs in to the platform/system via the addon. Permissioning of data accessible via the addon follows the permissioning user throughout the system, and as described herein. Via the addon, the user may map an email/thread of their inbox to a specific engagement, and/or a specific portion or engagement module of a specific engagement (as mentioned above). For example, the user can map a specific thread to a Deal Docs stage of an engagement/transaction between Rocket VC and the company Cloud Inc. As another example, the user may also directly map attachments to a specific engagement module/area by browsing the products, deals, and stages directly from the addon. For example, the user may identify a document being a board consent, navigate to the specific engagement module, and map the attachment as the signed copy of a specific board consent request. Via the addon, the user may also take actions on the attachments, such as sharing the attachment with other engagement participants, signing the attachment themselves by opening the systems signature functionality, or requesting other individuals to sign one or several attachments.

[0175] As described above and below, in some embodiments the system provides suggestions related to mapping of emails to engagements, and portions/engagement modules of engagements. Such suggestions may also be integrated into the addon. For example, via the addon the system may identify the email addresses included in the email thread to recommend a specific engagement or engagement module. This can be done by recognizing an engagement- specific email address, or by identifying a list of recipients matching participants in a specific engagement. Links identified in the thread may also be used to refine the recommendation/suggestion. As noted above, suggestions may also be made on the mapping of files by reading the filename.

Workflow Customization

[0176] According to various embodiments, the system provides a modular structure that enables customization and adaptations of engagements. Further, the system may provide workspaces for users, and collaborative workspaces for engagements. Email integration may enable the generation of new engagements, which engagements may then be customized via the modular structure of the system.

Example Workspaces, Engagements, and Engagement Modules

[0177] Figures 12A-12C illustrate example block diagrams of the system, according to various embodiments. Figure 12A illustrates an example implementation of user workspaces, Figure 12B illustrates an example implementation of engagement workspaces, and, Figure 12C illustrates an example implementation of engagement modules. [0178] In general, and according to various embodiments, the system includes a “workspaces”, which comprise conceptual, virtual, or actual segmentations or arrangements of information or data. These workspaces may include user-level workspaces (“user workspaces”) and engagement-level workspaces (“engagement workspaces”). As described above, the system 100 includes a workspace engine 133 that manages and implements the various workspaces of the system, including permissioning and storage of related data (e.g., in the databases 120, 128, and 129). Various user interfaces of the system may be associated with user workspaces and/or engagement workspaces. For example, the system may provide a user interface associated with a user workspace that may provide a user with a view, and interaction with, their roles and various engagements with which they are associated (see, e.g., Figure 17 providing an example user interface including a listing of all engagements associated with a user representing Organization A). As another example, the system may provide a user interface associated with an engagement workspace that may provide various users (individually or simultaneously) views, and interactions with, various aspects of an engagement and engagement modules of the engagement (see, e.g., Figures 16A-16B, 19G- 19H, and various example user interfaces described in the’78l Publication; see also example reports illustrated in Figures 9, 10A-10B, and 11). Advantageously, according to various embodiments, the system provides engagement workspaces as collaborative spaces that are accessible by many users (e.g., users associated with the engagement) to facilitate efficient execution of an engagement.

[0179] As noted above, according to various implementations, the system includes user workspaces associated with individual users of the system. User workspaces include information associated with individual users, including roles and permissions associated with each user (as described herein), engagement associated with each user, and the like. Figure 12A illustrates examples of such user workspaces 1202, 1204, 1206, and 1208. As illustrated in Figure 12A, each user workspace may include one or more engagements that the user is associated with. For example, User A is associated with Engagement A 1210 and Engagement N 1212. According to various implementations, user workspaces typically provide user interfaces that are specific to the associated users, and may be understood by the respective users and personal/private spaces. Such user workspaces and associated user interfaces may comprise“user engagement inboxes” as described above, which may provide a user’s view of information related to a particular engagement, and/or may comprise user interfaces providing an overview of many engagement of a user, as also described above. The system may provide combined or alterative views/user interfaces of personal/private information of the user, and shared information. In the later implementation, the system may provide a clear delineation or indication of information that is private, and information that is shared and with whom. Examples of such user interfaces are described below.

[0180] As is apparent from the present disclosure, multiple users are typically associated with a given engagement. Thus, as illustrated in Figure 12A, User B is also associated with Engagement A 1214, and User C is also associated with Engagement N 1218. Accordingly, User B Workspace 1204 includes Engagement A 1214, and User C Workspace 1206 includes Engagement N 1218.

[0181] In a typical scenario of the system, users are associated with a same workspace by both being associated with an email (e.g., User A sends an email that includes User B as a recipient, and the email is associated with an engagement). Accordingly, Figure 12A illustrates that User A and User B are linked in Engagement A via Thread A 1220 (e.g., an email thread that is associated with both users). Similarly, Figure 12A illustrates that User A and User C are linked in Engagement N via Thread B 1222.

[0182] As noted above, according to various implementations, the system includes engagement workspaces associated with individual engagements of the system. Engagement workspaces include information associated with individual engagements, including documents and data associated with each engagement, contacts/users associated with each engagement, engagement modules associated with each engagement, and the like. Figure 12B illustrates an example of an engagement workspace 1232. As illustrated in Figure 12B, an engagement workspace may include, without limitation, one or more of the following: one or more threads 1234 (e.g., emails associated with the engagement), one or more contacts 1236 (e.g., users associated with the engagement), a data room 1238, one or more engagement modules 1240, and/or a checklist 1242.

[0183] Threads 1234 include various emails and associated data may be associated with an engagement (as described herein). In general, a thread includes one or more recipients and/or senders, and the system, as described above, associates such recipient and/or sender users with the engagement to which the thread is associated. Accordingly, contacts 1236 include such recipient and/or sender users, and any other users that may be added automatically and/or manual to the engagement.

[0184] Engagement workspaces optionally include a data room 1238, which may comprise a storage location for various emails, documents, attachments, and other data of the engagement. The data room may comprise shared and private portions, and different users may be permissioned to have access to different data in the data room. Alternatively, the data room may comprise a shared portion of the engagement workspace that may be access by any user/contact of the engagement.

[0185] Engagement workspaces also optionally include one or more engagement modules 1240. Figure 12C illustrates an example engagement modules 1260 and 1261. An engagement module may comprise a modular, interoperable, and/or independent or semi independent set of functionality that may be added to an engagement. As illustrated in Figure 12C, engagement modules may include, for example, one or more goals 1262 including one or more steps, one of more tasks 1264, and/or other functionality 1266, including various inputs and outputs, user interfaces, data to be collected, etc. The various goals, steps, and/or tasks of an engagement module, including various users and associated roles for completing those goals, steps, and/or tasks, are managed by the system via the graph-based workflow described herein. Examples of various types of engagement modules are described throughout the present disclosure and in the’781 Publication, and include, without limitation, Term Sheet, Deal Docs, Core Financing, Ancillary Documents, Signatures, Wiring, Board Consents, Closing Book, etc. In an embodiment, data room is considered an engagement module.

[0186] Advantageously, according to various embodiments, engagement modules may be modular, interoperable, and/or independent or semi-independent, such that they may operate alone, or in combination with other engagement modules included in an engagement. In various embodiments, engagement modules may be defined in terms of inputs (e.g., inputs/data that are received from another module or a user), outputs (e.g., outputs/data that may be sent to another module or a user, including notifications), and engagement module functionality (e.g., data to be collected, goals/tasks/etc., user interfaces, etc.). Advantageously, according to various embodiments, due to their modularity, engagement modules may be efficiently and rapidly prototyped, developed, added to the system, and updated. According to various implementations, engagement modules may interface with third-party data providers, systems, applications, and the like that may exist outsides of the system of the present disclosure. According to various implementations, engagement modules may interface one another, third-party systems, and/or other aspects of the system of the present disclosure via provisioning, protocols, application programming interfaces (APIs), and/or the like.

[0187] Advantageously, according to various embodiments, engagements may be customized and re-customized over time, depending on a type of the engagement, by adding, removing, or adjusting various engagement modules in the engagement. Thus, for example, a simple engagement (or, e.g., pre-engagement communications) may simply require a data room and optionally a signature engagement module for executing documents, while a more complex engagement may require a data room, a term sheet engagement module, a due diligence engagement module, a signature engagement module, and possibly even more engagement modules. Over time, the type of the engagement may change, and the engagement can accordingly be adjusted by the addition of new engagement modules (or the removal of existing engagement modules) to suit the type of the engagement. Advantageously, according to various embodiments, the modular structure of the system enables it to be adapted to various types of engagements/transactions.

[0188] In various implementations, users may set up default engagements (e.g., a default set of engagement modules for new engagements), and/or engagement templates (e.g., different sets of engagement modules for various types of typical engagements). For example, Organization A may decide to include the Term Sheet, Deal Docs, and Signatures engagement modules in a Convertible Note engagement/transaction, while Organization B may decide to include the Due Diligence, Deal Docs, Signatures, and Wiring in a Convertible Note engagement modules in their Convertible Note engagement/transaction. As noted above, in various implementations engagements may be customized by adding or removing engagement modules at any time. For example, a user can add a pre-deal engagement module to an engagement, making it a pre-deal engagement, and they can later re-configure the engagement by selecting their“convertible note” checklist/template which will automatically add a pre-defined set of engagement modules (enabling the initial undefined engagement to become a convertible note engagement). As another example, the user could also select engagement modules specific to real estate, making the engagement a real estate transaction.

[0189] Further, in various implementations, engagement modules themselves may be customized, and may be customized per-user, for example. For example, in an implementation a list of docs included by default in the Deal Docs engagement module can be customized for each transaction/engagement type for each user/organization.

[0190] Referring again to Figure 12B, engagement workspaces may also include the checklist 1242, which may provide a list of engagement modules, goals/tasks, users associated with the goals/tasks, current statuses, etc., that may be derived based on the engagement modules associated with the engagement workspace. Thus, the checklist 1242 may comprise an overview of the engagement, and the checklist 1242 may be viewable and/or interacted with via an interactive user interface of the system. Example checklists are illustrated in Figures 19G-19H, and further described below. In various implementations, the user may customize the engagement (e.g., adding or removing engagement modules) via the checklist 1242.

[0191] Figure 12B also illustrates examples of the various communications and user interfaces that may be provided by the system and accessed by users, various examples of which a described throughout the present disclosure. These include, but are not limited to, electronic messages 1244 (including, e.g., emails), reports/checklists 1246, user level user interfaces 1248, group/organization level user interfaces 1250, and configuration user interfaces 1252.

[0192] Advantageously, the system may enable creation of a new engagement (e.g., an engagement workspace and associated components/engagement modules) simply by sending an email that is received by the system, as is further described below.

Example Engagement Setup

[0193] Figures 18A-18D, and 19A-19F illustrate example user interfaces of the system by which a user may start/setup an engagement, according to various embodiments of the present disclosure.

[0194] For example, in Figure 18A the user may enter the name of a company/organization associated with the engagement. In Figure 18B, which may be displayed upon the user’s selection of “next” in Figure 18 A, the user may select a characteristic of the engagement, which may be used by the system to provide a correct role for the user/organization, and/or set up the proper type of engagement. In Figures 18C-18D, which may be displayed upon the user’s selection of “next” in Figure 18B, the user may select a type of the engagement, which the system may use in generating the engagement workspace, and adding the appropriate set of engagement modules (which may be automatically determined by the system, may be determined based on a default template of the system, and/or may be previously defined by the user/organization in e.g., a template).

[0195] Figures 19A-19H illustrate further example user interfaces of the system for setting up an engagement that may follow the user’s selection of“done” in Figure 18D. In Figures 19A-19C, the user may optionally upload existing documents that are to be added to the engagement. In Figure 19D-19F, the user may optionally send emails to various other user/parties that are to be associated with the engagement (which emails may be customized, e.g., as shown in Figure 19E).

[0196] Advantageously, as noted above, in various implementations the system may enable creation of a new engagement (e.g., an engagement workspace and associated components/engagement modules) simply by sending an email that is received by the system. Such an engagement may then optionally be further customized by the user in any of the various ways described herein (including, e.g., via a series of steps such as those described above in reference to Figures 18A-18D, and 19A-19F). Advantageously, as further noted above, the system may enable customization of the engagement after its creation.

Example Engagement User Interfaces and Progression Tracking

[0197] Figures 16A-16B, 17, and 19G-19F illustrate further example engagement user interfaces of the system, according to various embodiments of the present disclosure. Advantageously, various user interfaces of the system may provide overviews and tracking of the statuses of engagements. Underlying these user interfaces, and according to various implementations, the system advantageously manages the engagements, including goals, tasks, turns, statuses, roles, etc. via the graph-based workflow platform described herein. For example, as described above, the system (e.g., system 100) can monitor progression through a goal (e.g., represented by a graph as described above), and determine a present state. Based on the present state, the system can determine a user whose turn it is to take an action. For example, Figures 3A-3B describe the system monitoring state information and identifying users required to perform actions. The system can identify a user according to the progression through the goal or engagement.

[0198] Figure 19G illustrates an example checklist of the engagement, including a list of engagement modules included in the engagement (e.g., Deal Docs, Signatures, Wiring, and Closing Book). The user may optionally expand the checklist to view a more detailed status, including related documents and user turns, as illustrated in the example user interface of Figure 19H.

[0199] Figure 16A illustrates another example engagement user interface 1600, including a listing of engagement modules associated with the engagement (similar to the checklist user interface described above), and indications of status, user turns, etc. A particular user 1601 (e.g.,‘John Doe’) is illustrated as using user interface 1600. In the user interface 1600, actions required to be performed, or which may be performed, by the user 1601 are illustrated. For example, the user interface 1600 indicates that it’s the user’s 1601 turn to work on a ‘Term Sheet’ and ‘Due Diligence’. The user interface 1600 further indicates summary information associated with turns. For example, the user interface 1600 includes a column 1604 identifying a turn for each stage of the goal. As described above, the system can monitor progression towards the goal through traversal of nodes indicating steps or tasks required to complete stages of the goal. Thus, the system can ensure that users are aware of whose turn it is to next perform an action or task. Figure 16B illustrates the user 1601 having selecting‘Term Sheet’ engagement module from portion 1602. The user interface 1600 can then update to indicate the specific action or task 1604 requiring completion.

[0200] Figure 17 illustrates yet another example user interface of the system. Figure 17 illustrates an example user interface including a listing of multiple engagements associated with a user representing Organization A. Various details associated with the various engagements are listed in the table 1702. Table 1702 further includes a column with information indicating, for each engagement, which user’s turn it is to take an action with respect to engagement. The user may user buttons (such as button 1710) to go to a detailed/checklist view of particular engagements. The user may also observe that they have been invited to join an engagement, and may accept or decline the invitation using interface elements 1708. The user may also create a new engagement via button 1704, which may take the user to a using interface similar to that of Figure 18A described above.

Example Email to Engagement Mapping

[0201] Figures 13A-13C are flowcharts of example processes for email integration of the system, according to various embodiments of the present disclosure. As described above, emails (including any associated data and attachments) received by the system (e.g., via engagement- specific email addresses or a universal platform email address) may be analyzed and/or parsed, and the email information (including email contents, attachments, etc.) may be associated with the appropriate engagement workspace. In the instance of emails sent to an engagement- specific email address, the appropriate workspace is identified via the unique, dedicated email address. In the instance of emails sent to the universal platform email address, the appropriate engagement workspace is identified via an analysis described below in reference to Figures 13A-13C.

[0202] Criteria and information used by the system in mapping emails/threads to engagements may include, but are not limited to:

• Origin of the thread: User cc universal platform email address; User cc engagement-specific email addresses; User uses Compose in-app (e.g., from a user interface of the system)

• User’s type: Registered user; Non-registered (e.g., email only) user

• User’s role: Sender; Recipients

• Context: User is in the in-app; User is in a separate email app

• Types of mapping (described further below): Auto-mapping; Suggestions;

Manual

• Mapping Source: Unmapped thread; Already mapped thread

• Mapping destination (described further below): Create a new engagement;

Existing engagement

• Email information: Recipients; Subject line; Email content; Attachment name; Attachment content; Already mapped by another recipient

[0203] Figure 13 A illustrates an example process of the system when a user includes an engagement- specific email address (also referred to as a“smart address” in the figure) on an email. At block 1302, the user sends an email to the engagement-specific email address. At block 1304, the system determines whether this is the first time this email/thread has been seen by the system, whether no engagement associated with the engagement- specific email address is already created, or whether this is the user’s first email interaction with the system. If not, the system uses a previous mapping and associates the email with the known engagement workspace at block 1306. If so, the system at block 1308 initiates an onboarding process, which may include sending an email back to the user with information about the system/platform, engagement, and mapping. At blocks 1310 and 1312, the system either creates a new engagement, or maps the email to an existing engagement (mapping to existing engagements is described further below). At block 1314, the email is associated with the engagement workspace.

[0204] Figure 13B illustrates an example process of the system when a user includes the universal platform email address on an email. At block 1320, the user sends an email to the universal platform email address. At block 1322, the system associates the email with the user’s workspace. At block 1324, the system determines whether this is the first time this email/thread has been seen by the system, or whether this is the user’s first email interaction with the system. If so, the system at block 1326 initiates an onboarding process, which may include sending an email back to the user with information about the system/platform, engagement, and mapping. If not, or following block 1326, the system, at block 1328, detects whether there is email content useable for analyzing and mapping the email. If not, at blocks 1336 and 1338 the system performs a search to determine whether the sender has any existing engagements. If there is no existing engagement, at block 1342 the system creates a new engagement workspace and associates the email with it. If there are existing engagements, at block 1340 the system allows the user to select an existing engagement (which selection may be provided via a user interface and/or an email reply to the user) and associates the email with it.

[0205] If the system detects that there is email content useable for analyzing and mapping the email, at block 1330 the system analyzes the email, and determines whether a confidence in mapping of the email to an existing engagement workspace satisfies a threshold. If so, the system, at block 1332 automatically associates the email with the existing engagement workspace. If not, the system, at block 1334, provides a list of suggested mappings to the user for selection (which may be provided via a user interface and/or an email reply to the user). Once the user provides a selection, the email is associated with the selected engagement workspace.

[0206] Figure 13C illustrates an example process of the system when a user composes an email within the system, or in conjunction with an email client addon. Compose happens at blocks 1350 (in which the system may associate the email with the user’s workspace) and 1352. At block 1354, the system determines whether this is the first time this email/thread has been seen by the system, or whether this is the user’s first email interaction with the system. If so, the system at block 1356 initiates an onboarding process, which may include sending an email back (or showing a user interface) to the user with information about the system/platform, engagement, and mapping. If not, or following block 1356, the system, at blocks 1358 and 1360, allows the user to select an existing engagement or create a new engagement with which to associate the email. If the user preforms one of these actions, once the user sends the email at block 1362, the email is associated with the selected/created engagement workspace. If the user does not perform one of these actions, once the user sends the email at block 1464, the system, at block 1366, detects whether there is email content useable for analyzing and mapping the email. If not, at blocks 1374 and 1378 the system performs a search to determine whether the sender has any existing engagements. If there is no existing engagement, at block 1382 the system creates a new engagement workspace and associates the email with it. If there are existing engagements, at block 1380 the system allows the user to select an existing engagement (which selection may be provided via a user interface and/or an email reply to the user) and associates the email with it. The system also optionally, at block 1376, allows the user to skip associating the email with an engagement workspace.

[0207] If the system detects that there is email content useable for analyzing and mapping the email, at block 1368 the system analyzes the email, and determines whether a confidence in mapping of the email to an existing engagement workspace satisfies a threshold. If so, the system, at block 1370 automatically associates the email with the existing engagement workspace. If not, the system, at block 1372, provides a list of suggested mappings to the user for selection (which may be provided via a user interface and/or an email reply to the user). Once the user provides a selection, the email is associated with the selected engagement workspace.

[0208] As noted above, in various implementations and processes the system may map emails to existing engagements automatically. Such mapping may be based on one or more of the criteria listed above. In an implementation, an email can be automatically mapped when one or more of the following is true: the email is sent to an engagement- specific email address; the list of recipients of the email match only one existing engagement; a name of the engagement appears in the email information; or the email is mapped by another recipient.

[0209] As noted above, in various implementations and processes the system may provide suggestions for mapping emails to existing engagements. Such suggested mappings may be based on one or more of the criteria listed above. In an implementation, suggestions are provided (rather than automatically mapping) when one or more of the following is true: the list of recipients of the email match more than one existing engagement; or only a partial match is made between names of existing engagements and email information.

[0210] In various implementations, when a thread/email is mapped to a new engagement, the following is performed by the system: recipients are added to the engagement workspace as email-only contacts; and email attachments are added to the engagement workspace data room.

[0211] In various implementations, when a thread/email is mapped to an existing engagement, the following is performed by the system: recipients who are not yet in the contacts of the engagement are added to the engagement workspace as email-only contacts; and email attachments are added to the engagement workspace data room.

[0212] In an implementation, users may configure behavior of the system with respect to automatic mapping.

[0213] Figure 14 is a diagram illustrating example associations of threads/emails with engagements by the system, according to various embodiments of the present disclosure. In general, all threads 1402 in the system are mapped to an engagement 1404. In an implementation, if the system cannot map a thread to an existing engagement, the system creates a new engagement for the thread. Users can keep existing mappings, or re-map threads to different engagements via various user interfaces of the system. [0214] According to various embodiments, interactions between users and the system of various processes described above may be accomplished via email exchange, user interfaces of the system, or email client addon (as described above).

[0215] Advantageously, according to various embodiments, because the system provides engagement workspaces as collaborative spaces that are accessible by many users (e.g., users associated with the engagement), all the recipients on a given email may provide a mapping of the email/attachments to an engagement. Such mapping can apply for all other recipients of the email. In various implementations, the system enables individual users to re map already mapped emails, but such mapping may only be reflected in the user’s workspace.

[0216] Figures 15A-15G are diagrams illustrating example email integration/mapping of the system, according to various embodiments of the present disclosure. Figures 15A-15G only provide an example implementation of email mapping of the system, and other implementations are contemplated, as described throughout this disclosure. Chronology of event will be specified using tl, t2 etc.

[0217] Referring to Figure 15A, at tl, User A sends an email to B and C while cc’ing the system 1502, with the subject“Review Aqme”. In response, a new undefined engagement is created by the system that includes A, B & C.

[0218] Referring to Figure 15B, at t2, User B sends a new email to D & E in the same thread while cc’ing the system. The thread is already mapped to the engagement “Review Aqme”, and contacts and attachments are mapped by the system as indicated.

[0219] Referring to Figure 15C, at t3, User D creates a new thread and emails E & F while cc’ing the system, with the subject“Aqme diligence”. In response, a new undefined engagement is created by the system that includes D, E & F.

[0220] Referring to Figure 15D, at t4, the system suggests to User D to map this engagement to existing engagement“Review Aqme”. User D accepts. In response, the thread “Aqme Diligence” is now mapped to engagement“Review Aqme”. Attachments & Contacts are transferred to“Review Aqme” by the system.

[0221] Referring to Figure 15E, at t4, the engagement“Aqme Diligence” may still exist, but doesn’t contain the attachment from the“Aqme Diligence” thread anymore [0222] Referring to Figure 15F, at t5, User A manually adds G & H as Contacts in the engagement. G & H can see the engagement and use the label in their inbox. They only see the shared folder in the data room because they weren’t included in any thread mapped to this engagement.

[0223] Referring to Figure 15G, at t6, User D configures the engagement to include some modules, adding TS, Deal Docs & Signatures. The system automatically adds dedicated folders for these modules in the data room.

[0224] Advantageously, according to various embodiments, the system and functionality described herein provides interactive user interfaces that provide clear indications of private vs. shared spaces, collaborative interactions among various users, granular controls over information sharing, customizability of engagements, and email integration, among other benefits.

[0225] As mentioned above, in various embodiments the system gathers all recipients of the threads that have been mapped to an engagement, and stores them as contacts in the engagement workspace so the various contacts can collaborate via the workspace. Additional contacts can be added to an engagement by making them a recipient on an email/thread that maps to the engagement, or manually adding the contacts to the engagement.

[0226] In various embodiments, parties/organizations associated with users matter in engagement modules, and therefore may be introduced when one of the contacts decides to include modules in the engagement. For example, the Term Sheet engagement modules expect the contacts who have access to it to be divide into two distinct groups, Investor & Company. When the user chooses to include Term Sheet engagement module in the engagement, the system will ask the user to indicate who among the contacts should be in the Investor and the Company. In an embodiment, the system pre-populates the contacts to be included in each team based on email domain and organization.

[0227] In an embodiment, the system may include a Board Consent engagement module that may be added to engagements to enable processing of board consents.

Additional Implementation Details and Embodiments

[0228] In some embodiments, the alerts and/or notifications (e.g., the various notifications that may be sent by the system as described here) are automatically transmitted to a device operated by, e.g., the user associated with a corresponding notifications. The alerts and/or notifications can be transmitted at the time that the alerts and/or notifications are generated or at some determined time after generation of the alerts and/or notifications. When received by the device, an alert and/or notification can cause the device to display the alert and/or notification via the activation of an application on the device (e.g., a browser, a mobile application, etc.). For example, receipt of the alert and/or notification may automatically activate an application on the device, such as a messaging application (e.g., SMS or MMS messaging application), a standalone application (e.g., a dedicated application associated with the systems described herein), or a browser, for example, and display information included in the alert and/or notification. If the device is offline when the alert and/or notification is transmitted, the application may be automatically activated when the device is online such that the alert and/or notification is displayed. As another example, receipt of the alert and/or notification may cause a browser to open and be redirected to a login page generated by the system so that the user can log in to the system and view the alert and/or notification. Alternatively, the alert and/or notification may include a URL of a webpage (or other online information) associated with the alert and/or notification, such that when the device (e.g., a mobile device) receives the alert, a browser (or other application) is automatically activated and the URL included in the alert and/or notification is accessed via the Internet.

[0229] As described herein, the system may be configured and/or designed to generate user interface data useable for rendering the various interactive user interfaces described. The user interface data may be used by the system, and/or another computer system, device, and/or software program (for example, a browser program), to render the interactive user interfaces. The interactive user interfaces may be displayed on, for example, electronic displays (including, for example, touch-enabled displays).

[0230] In an implementation, the systems described herein (e.g., system 1500 and/or other aspects of the present disclosure) may comprise a “virtual computing environment”. As used herein, the term “virtual computing environment” should be construed broadly to include, for example, computer readable program instructions executed by one or more processors (e.g., as described below in the example of Figure 8) to implement one or more aspects of the modules, engines, and/or functionality described herein (e.g., the functionality described in references to various flowcharts, blocks, user interfaces, and/or the like). Further, in this implementation, one or more modules/engines/etc. (e.g., user role action engine 108, etc.) of the system may be understood as comprising one or more rules engines of the virtual computing environment that, in response to inputs received by the virtual computing environment, execute rules and/or other program instructions to modify operation of the virtual computing environment. For example, inputs and outputs provided via interactive user interfaces of the system (e.g., as presented on user devices) may be understood as modifying operation of the virtual computing environment to cause the system, e.g., to execute the graph, track user roles and goals/tasks, parse documents, generate documents, etc. Such functionality may comprise a modification of the operation of the virtual computing environment in response to inputs and according to various rules. Other functionality implemented by the virtual computing environment (as described throughout this disclosure) may further comprise modifications of the operation of the virtual computing environment, for example, the operation of the virtual computing environment may change depending on the information gathered by the system and/or responses received and analyzed by the system. Initial operation of the virtual computing environment may be understood as an establishment of the virtual computing environment. In some implementations the virtual computing environment may comprise one or more virtual machines, containers, and/or other types of emulations of computing systems or environments. In some implementations the virtual computing environment may comprise a hosted computing environment that includes a collection of physical computing resources that may be remotely accessible and may be rapidly provisioned as needed (commonly referred to as“cloud” computing environment).

[0231] Implementing one or more aspects of the system as a virtual computing environment may advantageously enable executing different aspects or modules of the system on different computing devices or processors, which may increase the scalability of the system. Implementing one or more aspects of the system as a virtual computing environment may further advantageously enable sandboxing various aspects, data, or modules of the system from one another, which may increase security of the system by preventing, e.g., malicious intrusion into the system from spreading. Implementing one or more aspects of the system as a virtual computing environment may further advantageously enable parallel execution of various aspects or modules of the system, which may increase the scalability of the system. Implementing one or more aspects of the system as a virtual computing environment may further advantageously enable rapid provisioning (or de provisioning) of computing resources to the system, which may increase scalability of the system by, e.g., expanding computing resources available to the system or duplicating operation of the system on multiple computing resources. For example, the system may be used by thousands, hundreds of thousands, or even millions of users simultaneously, and many megabytes, gigabytes, or terabytes (or more) of data may be transferred or processed by the system, and scalability of the system may enable such operation in an efficient and/or uninterrupted manner.

[0232] Various embodiments of the present disclosure may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or mediums) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0233] For example, the functionality described herein may be performed as software instructions are executed by, and/or in response to software instructions being executed by, one or more hardware processors and/or any other suitable computing devices. The software instructions and/or other executable code may be read from a computer readable storage medium (or mediums).

[0234] The computer readable storage medium can be a tangible device that can retain and store data and/or instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device (including any volatile and/or non-volatile electronic storage devices), a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non- exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a solid state drive, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0235] Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

[0236] Computer readable program instructions (as also referred to herein as, for example,“code,”“instructions,”“module,”“applic ation,”“software application,” and/or the like) for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. Computer readable program instructions may be callable from other instructions or from itself, and/or may be invoked in response to detected events or interrupts. Computer readable program instructions configured for execution on computing devices may be provided on a computer readable storage medium, and/or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression or decryption prior to execution) that may then be stored on a computer readable storage medium. Such computer readable program instructions may be stored, partially or fully, on a memory device (e.g., a computer readable storage medium) of the executing computing device, for execution by the computing device. The computer readable program instructions may execute entirely on a user's computer (e.g., the executing computing device), partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0237] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

[0238] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart(s) and/or block diagram(s) block or blocks. [0239] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions and/or modules into its dynamic memory and send the instructions over a telephone, cable, or optical line using a modem. A modem local to a server computing system may receive the data on the telephone/cable/optical line and use a converter device including the appropriate circuitry to place the data on a bus. The bus may carry the data to a memory, from which a processor may retrieve and execute the instructions. The instructions received by the memory may optionally be stored on a storage device (e.g., a solid state drive) either before or after execution by the computer processor.

[0240] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. In addition, certain blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate.

[0241] It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. For example, any of the processes, methods, algorithms, elements, blocks, applications, or other functionality (or portions of functionality) described in the preceding sections may be embodied in, and/or fully or partially automated via, electronic hardware such application- specific processors (e.g., application- specific integrated circuits (ASICs)), programmable processors (e.g., field programmable gate arrays (FPGAs)), application- specific circuitry, and/or the like (any of which may also combine custom hard-wired logic, logic circuits, ASICs, FPGAs, etc. with custom programming/execution of software instructions to accomplish the techniques).

[0242] Any of the above-mentioned processors, and/or devices incorporating any of the above-mentioned processors, may be referred to herein as, for example,“computers,” “computer devices,” “computing devices,” “hardware computing devices,” “hardware processors,” “processing units,” and/or the like. Computing devices of the above embodiments may generally (but not necessarily) be controlled and/or coordinated by operating system software, such as Mac OS, iOS, Android, Chrome OS, Windows OS (e.g., Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server, etc.), Windows CE, Unix, Linux, SunOS, Solaris, Blackberry OS, VxWorks, or other suitable operating systems. In other embodiments, the computing devices may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface functionality, such as a graphical user interface (“GUI”), among other things.

[0243] For example, Figure 8 is a block diagram that illustrates a computer system 800 upon which various embodiments may be implemented (e.g., system 100 and/or various other aspects of the present disclosure). Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a hardware processor, or multiple processors, 804 coupled with bus 802 for processing information. Hardware processor(s) 804 may be, for example, one or more general purpose microprocessors.

[0244] Computer system 800 also includes a main memory 806, such as a random access memory (RAM), cache and/or other dynamic storage devices, coupled to bus 802 for storing information and instructions to be executed by processor 804. Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Such instructions, when stored in storage media accessible to processor 804, render computer system 800 into a special- purpose machine that is customized to perform the operations specified in the instructions.

[0245] Computer system 800 further includes a read only memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus 802 for storing information and instructions.

[0246] Computer system 800 may be coupled via bus 802 to a display 812, such as a cathode ray tube (CRT) or LCD display (or touch screen), for displaying information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to bus 802 for communicating information and command selections to processor 804. Another type of user input device is cursor control 816, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 804 and for controlling cursor movement on display 812. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. In some embodiments, the same direction information and command selections as cursor control may be implemented via receiving touches on a touch screen without a cursor.

[0247] Computing system 800 may include a user interface engine or module to implement a GUI that may be stored in a mass storage device as computer executable program instructions that are executed by the computing device(s). Computer system 800 may further, as described below, implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 800 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 800 in response to processor(s) 804 executing one or more sequences of one or more computer readable program instructions contained in main memory 806. Such instructions may be read into main memory 806 from another storage medium, such as storage device 810. Execution of the sequences of instructions contained in main memory 806 causes processor(s) 804 to perform the process steps described herein. In altemative embodiments, hard- wired circuitry may be used in place of or in combination with software instructions.

[0248] Various forms of computer readable storage media may be involved in carrying one or more sequences of one or more computer readable program instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 802. Bus 802 carries the data to main memory 806, from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.

[0249] Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupling to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicate with a WAN). Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0250] Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the“Internet” 828. Local network 822 and Internet 828 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are example forms of transmission media.

[0251] Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818.

[0252] The received code may be executed by processor 804 as it is received, and/or stored in storage device 810, or other non-volatile storage for later execution.

[0253] As described above, in various embodiments certain functionality may be accessible by a user through a web-based viewer (such as a web browser), or other suitable software program). In such implementations, the user interface may be generated by a server computing system and transmitted to a web browser of the user (e.g., running on the user’s computing system). Alternatively, data (e.g., user interface data) necessary for generating the user interface may be provided by the server computing system to the browser, where the user interface may be generated (e.g., the user interface data may be executed by a browser accessing a web service and may be configured to render the user interfaces based on the user interface data). The user may then interact with the user interface through the web-browser. User interfaces of certain implementations may be accessible through one or more dedicated software applications. In certain embodiments, one or more of the computing devices and/or systems of the disclosure may include mobile computing devices, and user interfaces may be accessible through such mobile computing devices (for example, smartphones and/or tablets).

[0254] Many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the systems and methods can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the systems and methods should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the systems and methods with which that terminology is associated.

[0255] Conditional language, such as, among others,“can,”“could,”“might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

[0256] The term“substantially” when used in conjunction with the term“real-time” forms a phrase that will be readily understood by a person of ordinary skill in the art. For example, it is readily understood that such language will include speeds in which no or little delay or waiting is discernible, or where such delay is sufficiently short so as not to be disruptive, irritating, or otherwise vexing to a user.

[0257] Conjunctive language such as the phrase“at least one of X, Y, and Z,” or“at least one of X, Y, or Z,” unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof. For example, the term“or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term“or” means one, some, or all of the elements in the list. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present.

[0258] The term“a” as used herein should be given an inclusive rather than exclusive interpretation. For example, unless specifically noted, the term“a” should not be understood to mean“exactly one” or“one and only one”; instead, the term“a” means“one or more” or“at least one,” whether used in the claims or elsewhere in the specification and regardless of uses of quantifiers such as“at least one,”“one or more,” or“a plurality” elsewhere in the claims or specification.

[0259] The term“comprising” as used herein should be given an inclusive rather than exclusive interpretation. For example, a general purpose computer comprising one or more processors should not be interpreted as excluding other computer components, and may possibly include such components as memory, input/output devices, and/or network interfaces, among others.

[0260] While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it may be understood that various omissions, substitutions, and changes in the form and details of the devices or processes illustrated may be made without departing from the spirit of the disclosure. As may be recognized, certain embodiments of the inventions described herein may be embodied within a form that does not provide all of the features and benefits set forth herein, as some features may be used or practiced separately from others. The scope of certain inventions disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.