Patent Publication Number: US-2023136059-A1

Title: Electronic document generation and execution

Description:
BACKGROUND 
     Electronic documents are quickly becoming the first choice of many businesses and other entities, which prefer them for their speed of execution, paperless processing, and added convenience. In a typical scenario, a user prepares a document for electronic signature. The user uploads the document to a document server and specifies one or more parties as signatories to the document, e.g., by providing their email addresses or cell phone numbers. The user may add one or more fields for data entry, and such fields may include one or more signature fields. 
     Once all the fields have been placed into the document, the user may submit the document for online execution. For example, the document server responds to the user&#39;s submission by sending an email or other communication to each specified party. The email or other communication may include a brief description of the document and a link to a version of the document prepared for the respective party&#39;s signature. A party clicks on the link, and a version of the document opens, e.g., in a browser or app on the party&#39;s computer or other device. The party can then review the agreement, enter any requested data into fields prepared for this purpose, and sign the document. The party may then submit the signed document, e.g., by clicking or tapping a button. Submitting the document returns the signed document to the document server, which may store the signed document for safekeeping. 
     SUMMARY 
     Unfortunately, current document servers are unable to create new documents or new versions of documents. Rather, such document servers act as passive repositories or databases of documents created by users. The passive nature of document servers may be attributable at least in part to the prior lack of available technical tools for analyzing stored documents efficiently. It may also be attributable to providers failing to see the potential of stored documents in improving server operations and services. We have recognized, however, that document servers can play a more active role in improving server operations and user services. For example, modified versions of many documents can be predicted from the contents of the documents themselves. If a document server could create modified versions of documents, it would avoid user inconvenience as well as the computational burdens of responding to user requests to create new documents. What is needed, therefore, is a way of creating new documents by a document server in cases where the contents of the new documents can be predicted. 
     In contrast with prior approaches, an improved technique to identify documents in need of follow-up actions and to create new documents or versions thereof includes performing a text-based analysis of a document submitted for signature and/or storage. The text-based analysis searches for terms and/or other content that indicate a future action to be performed and a corresponding action date by which to perform the action. In response to detecting such terms and/or other content, the technique further includes creating metadata indicative of the action and a date for performance of that action and storing such metadata in a database. The technique further includes querying the database, e.g., prior to or upon the action date, and creating a modified version of the document to implement the detected action. 
     Advantageously, the improved technique improves user experience and reduces processing and computational demands on server resources. Reducing server demands allows fewer and/or less powerful servers to be deployed, reducing hardware costs as well as costs for power and maintenance. 
     Certain embodiments are directed to a method that includes identifying, based at least in part on a range of dates, an electronic document from a database and obtaining, from the database, metadata indicative of the electronic document. The metadata includes a date and an identifier of an entity of the electronic document. Prior to or upon an occurrence of the date, the method further includes (i) obtaining the electronic document from a service provider, (ii) generating a modified version of the electronic document, and (iii) transmitting a link to the modified version to the entity. Based on activation of the link, the method still further includes providing the modified version of the document for signature. 
     In some examples, the method further includes modifying the modified version of the electronic document based on changes made by the entity. 
     In some examples, the metadata is further indicative of one or more identifiers of parties to the electronic document, and the method further includes, based on the activation of the link, sending respective requests for signing the modified version of the document to the parties. 
     In some examples, generating the modified version of the document includes changing the date on the electronic document to a revised date that is later than the date. 
     In some examples, the method further includes receiving a second document, identifying an action date specified by the second document, and determining, based on text extracted from the second document, an action specified by the second document in connection with the action date. The method further includes sending an electronic message to an entity of the second document, the electronic message requesting confirmation that the action specified by the second document is due for performance by the action date, and in response to confirmation from the entity of the second document, storing second metadata in the database, the second metadata specifying, in connection with an identifier of the second document, an indicator of the action date and an indicator of the action. 
     In some examples, determining the specified action includes performing keyword analysis on the text extracted from the second document. 
     In some examples, determining the specified action includes performing natural language processing on the text extracted from the second document. 
     In some examples, performing the natural language processing includes providing the extracted text to a machine-learning model trained to detect specified actions and associated action dates. 
     In some examples, the method further includes training the machine-learning model at least in part using previously-executed documents stored by the service provider. 
     In some examples, training the machine-learning model includes operating the machine-learning model on a first previous document stored by the service provider to generate a prediction that the first previous document is renewable and an associated renewal date, and providing positive feedback for the prediction made by the machine-learning model responsive to determining that a second previous document stored by the service provider is a renewal of the first previous document. 
     In some examples, the method further includes matching the first previous document to the second previous document is based on at least one of: (i) the first previous document and the second previous document sharing a common owner, (ii) the first previous document and the second previous document sharing a common set of parties, (iii) the first previous document and the second previous document having been generated from a common user account, or (iv) the first previous document and the second previous document having been generated from a common document template. 
     Other embodiments are directed to a method that includes: determining, by a computing device, a time at which to update an electronic document, the determination being made based on content of the document; retrieving, by the computing device, the document from a database at or prior to the determination of the time; extracting, by the computing device, data from the document, the data being indicative of at least one change to be made to the document; determining, by the computing device, at least one modification to the electronic document based on the data extracted; and modifying, by the computing device, the electronic document to include the at least one modification by addition or deletion of content to or from the electronic document at or prior to the determined time. 
     Still other embodiments are directed to a computerized apparatus constructed and arranged to perform any of the methods described above. Further embodiments are directed to a computer program product. The computer program product stores instructions which, when executed on control circuitry of a server, cause the server to perform any of the methods described above. 
     The foregoing summary is presented for illustrative purposes to assist the reader in readily grasping example features presented herein; however, this summary is not intended to set forth required elements or to limit embodiments hereof in any way. One should appreciate that the above-described features can be combined in any manner that makes technological sense, and that all such combinations are intended to be disclosed herein, regardless of whether such combinations are identified explicitly or not. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
       The foregoing and other features and advantages will be apparent from the following description of particular embodiments, as illustrated in the accompanying drawings, in which like reference characters refer to the same or similar parts throughout the different views. 
         FIG.  1    is a block diagram of a server in accordance with certain embodiments. 
         FIG.  2    is a schematic block diagram of a cloud computing environment in which various aspects of the disclosure may be implemented. 
         FIG.  3    is a block diagram of an example computing environment in which embodiments of the improved technique can be practiced. 
         FIG.  4    is a block diagram of example metadata that may be provided in the environment of  FIG.  3   . 
         FIG.  5    is a block diagram of an example document action manager that may be provided in the environment of  FIG.  3   . 
         FIG.  6    is a flowchart showing an example method of receiving a document for processing in the environment of  FIG.  3   . 
         FIG.  7    is a flowchart showing an example method of generating a modified version of a document. 
         FIG.  8    is a flowchart showing example method of processing a document; 
         FIG.  9    is a sequence diagram showing an example sequence of activities related to receiving and analyzing a document. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of the improved technique will now be described. One should appreciate that such embodiments are provided by way of example to illustrate certain features and principles but are not intended to be limiting. 
     An improved technique for document management involves performing a text-based analysis of a document submitted for signature and/or storage. The text-based analysis searches for terms and/or other content that indicate a future action to be performed and a corresponding action date by which to perform the action. In response to detecting such terms and/or other content, the technique further includes creating metadata indicative of the action and associated action date and storing such metadata in a database. The technique further includes querying the database, e.g., prior to or upon the action date, and creating a modified version of the document to implement the detected action. 
     Example Computing Environment: 
       FIGS.  1  and  2    show an example environment in which certain embodiments may be practiced. The depicted environment is provided for purposes of illustration and is not intended to be limiting. 
       FIG.  1    shows a computer device  100  operating as a server (e.g., virtualization server)  110  which is suitable for providing document preparation and management services within the computing environment in accordance with certain embodiments. It should be understood that  FIG.  1    shows a high-level architecture of an illustrative desktop virtualization system. Such a system is suitable for use as at least a portion of the platform  320  ( FIG.  3   ). 
     As shown in  FIG.  1   , the desktop virtualization system may be a single-server or multi-server system, or a cloud system, including at least one computer device  100  operating as a virtualization server  110  configured to provide virtual desktops and/or virtual applications to one or more client access devices. As used herein, a desktop may refer to a graphical environment (e.g., a graphical user interface) or space in which one or more applications may be hosted and/or executed. A desktop may include a graphical shell providing a user interface for an instance of an operating system in which local and/or remote applications can be integrated. Applications may include programs that execute after an instance of an operating system (and, optionally, also the desktop) has been loaded. Individual instances of the operating system may be physical (e.g., one operating system per physical device) or virtual (e.g., many instances of an OS running on a single physical device). Applications may be executed on a local device, or executed on a remotely located device (e.g., remoted). 
     The computer device  100  may be configured as a virtualization server in a virtualization environment, for example, a single-server, multi-server, or cloud computing environment. Virtualization server  110  illustrated in  FIG.  1    may be deployed as and/or implemented by one or more embodiments of the platform  320  or by other known computing devices. Included in virtualization server  110  is hardware layer  120  that may include one or more physical disks  122 , one or more physical devices  124 , one or more physical processors  126 , and one or more physical memories  128 . In some embodiments, firmware  140  may be stored within a memory element in physical memory  128  and be executed by one or more of physical processors  126 . Virtualization server  110  may further include operating system  150  that may be stored in a memory element in physical memory  128  and executed by one or more of physical processors  126 . Still further, hypervisor  160  may be stored in a memory element in physical memory  128  and be executed by one or more of physical processors  126 . Presence of operating system  150  may be optional such as in a case where the hypervisor  160  is a Type A hypervisor. 
     Executing on one or more of physical processors  126  may be one or more virtual machines  170 A,  170 B,  170 C, . . . (generally, VMs  170 ). The VMs  170 A,  170 B,  170 C, . . . include respective virtual disks  172 A,  172 B,  172 C, . . . (generally, virtual disks  172 ) and respective virtual processors  174 A,  174 B,  174 C, . . . (generally, virtual processors  174 ). In some embodiments, the first VM  170 A may execute, using virtual processor  174 A, control program  180  that includes tools stack  182 . Control program  180  may be referred to as a control virtual machine, Domain 0, Dom0, or other virtual machine used for system administration and/or control. In some embodiments, one or more VMs  170 B,  170 C, . . . may execute, using their respective virtual processors  174 B,  174 C, . . . , guest operating systems  190 B,  190 C, . . . (generally, guest operating systems  190 ). 
     Physical devices  124  may include, for example, a network interface card, a video card, an input device (e.g., a keyboard, a mouse, a scanner, etc.), an output device (e.g., a monitor, a display device, speakers, a printer, etc.), a storage device (e.g., an optical drive), a Universal Serial Bus (USB) connection, a network element (e.g., router, firewall, network address translator, load balancer, virtual private network (VPN) gateway, Dynamic Host Configuration Protocol (DHCP) router, etc.), or any device connected to or communicating with virtualization server  110 . Physical memory  128  in hardware layer  120  may include any type of memory. Physical memory  128  may store data, and in some embodiments may store one or more programs, or set of executable instructions.  FIG.  1    illustrates an embodiment where firmware  140  is stored within physical memory  128  of virtualization server  110 . Programs or executable instructions stored in physical memory  128  may be executed by the one or more processors  126  of virtualization server  110 . 
     Virtualization server  110  may also include hypervisor  160 . In some embodiments, hypervisor  160  may be a program executed by processors  126  on virtualization server  110  to create and manage any number of virtual machines  170 . Hypervisor  160  may be referred to as a virtual machine monitor, or platform virtualization software. In some embodiments, hypervisor  160  may be any combination of executable instructions and hardware that monitors virtual machines  170  executing on a computing machine. Hypervisor  160  may be a Type 2 hypervisor, where the hypervisor executes within operating system  150  executing on virtualization server  110 . Virtual machines may then execute at a layer above hypervisor  160 . In some embodiments, the Type 2 hypervisor may execute within the context of a user&#39;s operating system such that the Type 2 hypervisor interacts with the user&#39;s operating system. In other embodiments, one or more virtualization servers  110  in a virtualization environment may instead include a Type 1 hypervisor (not shown). A Type 1 hypervisor may execute on virtualization server  110  by directly accessing the hardware and resources within hardware layer  110 . That is, while Type 2 hypervisor  160  accesses system resources through host operating system  150 , as shown, a Type 1 hypervisor may directly access all system resources without host operating system  110 . A Type 1 hypervisor may execute directly on one or more physical processors  126  of virtualization server  110 , and may include program data stored in physical memory  128 . 
     Hypervisor  150 , in some embodiments, may provide virtual resources to guest operating systems  190  or control programs  180  executing on virtual machines  170  in any manner that simulates operating systems  190  or control programs  180  having direct access to system resources. System resources can include, but are not limited to, physical devices  122 , physical disks  124 , physical processors  126 , physical memory  128 , and any other component included in hardware layer  120  of virtualization server  110 . Hypervisor  160  may be used to emulate virtual hardware, partition physical hardware, virtualize physical hardware, and/or execute virtual machines that provide access to computing environments. In still other embodiments, hypervisor  160  may control processor scheduling and memory partitioning for virtual machines  170  executing on virtualization server  110 . Examples of hypervisor  160  may include those manufactured by VMWare, Inc., of Palo Alto, Calif.; Xen Project® hypervisor, an open-source product whose development is overseen by the open source XenProject.org community; Hyper-V®, Virtual Server®, and Virtual PC® hypervisors provided by Microsoft Corporation of Redmond, Wash.; or others. In some embodiments, virtualization server  110  may execute hypervisor  160  that creates a virtual machine platform on which guest operating systems  190  may execute. In these embodiments, virtualization server  110  may be referred to as a host server. An example of such a virtualization server is Citrix Hypervisor® provided by Citrix Systems, Inc., of Fort Lauderdale, Fla. 
     Hypervisor  160  may create one or more virtual machines  170  in which guest operating systems  190  execute. In some embodiments, hypervisor  160  may load a virtual machine image to create virtual machine  170 . The virtual machine image may refer to a collection of data, states, instructions, etc. that make up an instance of a virtual machine. In other embodiments, hypervisor  160  may execute guest operating system  190  within virtual machine  170 . In still other embodiments, virtual machine  170  may execute guest operating system  190 . 
     In addition to creating virtual machines  170 , hypervisor  160  may control the execution of at least one virtual machine  170 . In other embodiments, hypervisor  160  may present at least one virtual machine  170  with an abstraction of at least one hardware resource provided by virtualization server  110  (e.g., any hardware resource available within hardware layer  110 ). In other embodiments, hypervisor  160  may control the manner in which virtual machines  170  access physical processors  126  available in virtualization server  110 . Controlling access to physical processors  126  may include determining whether virtual machine  170  should have access to processor  126 , and how physical processor capabilities are presented to virtual machine  170 . 
     As shown in  FIG.  1   , virtualization server  110  may host or execute one or more virtual machines  170 . Virtual machine  170  may be a set of executable instructions and/or user data that, when executed by processor  126 , may imitate the operation of a physical computer such that virtual machine  170  can execute programs and processes much like a physical computing device. While  FIG.  1    illustrates an embodiment where virtualization server  110  hosts three virtual machines  170 , in other embodiments virtualization server  110  may host any number of virtual machines  170 . Hypervisor  160 , in some embodiments, may provide each virtual machine  170  with a unique virtual view of the physical hardware, including memory  128 , processor  126 , and other system resources  122 ,  124  available to that virtual machine  170 . In some embodiments, the unique virtual view may be based on one or more of virtual machine permissions, application of a policy engine to one or more virtual machine identifiers, a user accessing a virtual machine, the applications executing on a virtual machine, networks accessed by a virtual machine, or any other desired criteria. For instance, hypervisor  160  may create one or more unsecure virtual machines  170  and one or more secure virtual machines  170 . Unsecure virtual machines  170  may be prevented from accessing resources, hardware, memory locations, and programs that secure virtual machines  170  may be permitted to access. In other embodiments, hypervisor  110  may provide each virtual machine  170  with a substantially similar virtual view of the physical hardware, memory, processor, and other system resources available to virtual machines  170 . 
     Each virtual machine  170  may include a respective virtual disk  172  and respective virtual processor  174 . Virtual disk  172 , in some embodiments, may be a virtualized view of one or more physical disks  122  of virtualization server  110 , or a portion of one or more physical disks  122  of virtualization server  110 . The virtualized view of physical disks  122  may be generated, provided, and managed by hypervisor  160 . In some embodiments, hypervisor  160  may provide each virtual machine  170  with a unique view of physical disks  122 . Thus, in these embodiments, particular virtual disk  122  included in each virtual machine  170  may be unique when compared with other virtual disks  172 . 
     Virtual processor  174  may be a virtualized view of one or more physical processors  126  of virtualization server  110 . In some embodiments, the virtualized view of physical processors  126  may be generated, provided, and managed by hypervisor  160 . In some embodiments, virtual processor  174  may have substantially all of the same characteristics of at least one physical processor  126 . In other embodiments, virtual processor  174  may provide a modified view of physical processors  126  such that at least some of the characteristics of virtual processor  174  are different from the characteristics of the corresponding physical processor  126 . 
     It should be understood that the computer device  100  operating as the virtualization server  110  may be configured to provide electronic signature services as a cloud service. Along these lines, various users involved in preparing and/or electronically signing a document are able to access the cloud service. 
     Referring now to  FIG.  2   , a cloud computing environment  200  is depicted, which may also be referred to as a cloud environment, cloud computing or cloud network. The cloud computing environment  200  can provide the delivery of shared computing services and/or resources to multiple users or tenants. For example, the shared resources and services can include, but are not limited to, networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, databases, software, hardware, analytics, and intelligence. 
     In the cloud computing environment  200 , one or more clients (or user devices)  202   a - 202   n  (such as those described above) are in communication with a cloud network  204 . The cloud network  204  may include back-end platforms, e.g., servers, storage, server farms or data centers. The users or clients  202   a - 202   n  can correspond to a single organization/tenant or multiple organizations/tenants. More particularly, in one example implementation the cloud computing environment  200  may provide a private cloud serving a single organization (e.g., enterprise cloud). In another example, the cloud computing environment  200  may provide a community or public cloud serving multiple organizations/tenants. 
     In some embodiments, a gateway appliance(s) or service may be utilized to provide access to cloud computing resources and virtual sessions. By way of example, Citrix Gateway, provided by Citrix Systems, Inc., may be deployed on-premises or on public clouds to provide users with secure access and single sign-on to virtual, SaaS and web applications. Furthermore, to protect users from web threats, a gateway such as Citrix Secure Web Gateway may be used. Citrix Secure Web Gateway uses a cloud-based service and a local cache to check for URL reputation and category. 
     In still further embodiments, the cloud computing environment  200  may provide a hybrid cloud that is a combination of a public cloud and a private cloud. Public clouds may include public servers that are maintained by third parties to the clients  202   a - 202   n  or the enterprise/tenant. The servers may be located off-site in remote geographical locations or otherwise. 
     The cloud computing environment  200  can provide resource pooling to serve multiple users via clients  202   a - 202   n  through a multi-tenant environment or multi-tenant model with different physical and virtual resources dynamically assigned and reassigned responsive to different demands within the respective environment. The multi-tenant environment can include a system or architecture that can provide a single instance of software, an application or a software application to serve multiple users. In some embodiments, the cloud computing environment  200  can provide on-demand self-service to unilaterally provision computing capabilities (e.g., server time, network storage) across a network for multiple clients  202   a - 202   n.  By way of example, provisioning services may be provided through a system such as Citrix Provisioning Services (Citrix PVS). Citrix PVS is a software-streaming technology that delivers patches, updates, and other configuration information to multiple virtual desktop endpoints through a shared desktop image. The cloud computing environment  200  can provide an elasticity to dynamically scale out or scale in response to different demands from one or more clients  202 . In some embodiments, the cloud computing environment  200  can include or provide monitoring services to monitor, control and/or generate reports corresponding to the provided shared services and resources. 
     In some embodiments, the cloud computing environment  200  may provide cloud-based delivery of different types of cloud computing services, such as Software as a service (SaaS)  208 , Platform as a Service (PaaS)  212 , Infrastructure as a Service (IaaS)  216 , and Desktop as a Service (DaaS)  220 , for example. IaaS may refer to a user renting the use of infrastructure resources that are needed during a specified time period. IaaS providers may offer storage, networking, servers or virtualization resources from large pools, allowing the users to quickly scale up by accessing more resources as needed. Examples of IaaS include AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash., RACKSPACE CLOUD provided by Rackspace US, Inc., of San Antonio, Tex., Google Compute Engine provided by Google Inc. of Mountain View, Calif., or RIGHTSCALE provided by RightScale, Inc., of Santa Barbara, Calif. 
     PaaS providers may offer functionality provided by IaaS, including, e.g., storage, networking, servers or virtualization, as well as additional resources such as, e.g., the operating system, middleware, or runtime resources. Examples of PaaS include WINDOWS AZURE provided by Microsoft Corporation of Redmond, Wash., Google App Engine provided by Google Inc., and HEROKU provided by Heroku, Inc. of San Francisco, Calif. 
     SaaS providers may offer the resources that PaaS provides, including storage, networking, servers, virtualization, operating system, middleware, or runtime resources. In some embodiments, SaaS providers may offer additional resources including, e.g., data and application resources. Examples of SaaS include GOOGLE APPS provided by Google Inc., SALESFORCE provided by Salesforce.com Inc. of San Francisco, Calif., or OFFICE  365  provided by Microsoft Corporation. Examples of SaaS may also include data storage providers, e.g., Citrix ShareFile from Citrix Systems, DROPBOX provided by Dropbox, Inc. of San Francisco, Calif., Microsoft SKYDRIVE provided by Microsoft Corporation, Google Drive provided by Google Inc., or Apple ICLOUD provided by Apple Inc. of Cupertino, Calif. 
     Similar to SaaS, DaaS (which is also known as hosted desktop services) is a form of virtual desktop infrastructure (VDI) in which virtual desktop sessions are typically delivered as a cloud service along with the apps used on the virtual desktop. Citrix Cloud from Citrix Systems is one example of a DaaS delivery platform. DaaS delivery platforms may be hosted on a public cloud computing infrastructure such as AZURE CLOUD from Microsoft Corporation of Redmond, Wash. (herein “Azure”), or AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash. (herein “AWS”), for example. In the case of Citrix Cloud, Citrix Workspace app may be used as a single-entry point for bringing apps, files and desktops together (whether on-premises or in the cloud) to deliver a unified experience. 
     Computing Environment: 
     Example aspects of a computing environment  300  will now be described with reference to  FIG.  3   . One should appreciate that environment  300  may be realized in the computing environment shown in  FIGS.  1  and  2   , for example, although this is not required. 
     As shown in  FIG.  3   , multiple user devices  202  (e.g.,  202   a - 200   n ) of respective users  302  (e.g.,  302   a - 302   n ) connect to a computing platform (e.g., an e-signature platform)  320  over a network  310 . The user devices  202  may include any type or types of computing device capable of connecting to the network  310  and running software, such as desktop computers, laptop computers, tablet computers, smart phones, PDAs (personal data assistants), or the like. The network  310  may be any type of network or combination of networks, such as a local area network (LAN), a wide area network (WAN), the Internet, and/or some other type of network or combination of networks, for example. 
     The platform  320  includes one or more communication interfaces  322 , a set of processors  324 , and memory  330 . The communication interfaces  322  include, for example, network interface adapters for converting electronic and/or optical signals received over the network  310  to electronic form for use by the platform  320 . The set of processors  324  includes one or more processing chips and/or assemblies, such as numerous multi-core CPUs (central processing units). The memory  330  includes both volatile memory, e.g., RAM (Random Access Memory), and non-volatile memory, such as one or more ROMs (Read-Only Memories), disk drives, solid state drives, and the like. The set of processors  324  and the memory  330  together form control circuitry, which is constructed and arranged to carry out various methods and functions as described herein. Also, the memory  330  includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processors  324 , the set of processors  324  carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that the memory  330  typically includes many other software components, which are not shown, such as an operating system, various applications, processes, and daemons. 
     As further shown in  FIG.  1   , the memory  330  “includes,” i.e., realizes by execution of software instructions, a web server  332  and an e-signature application  334 . The e-signature application  334  may be provided as a web application, which may be hosted to user devices  202  via the web server  332 . The memory  330  further includes a database  340 , an object store  350 , and a document action manager  360 . The database  340  is configured to store metadata  342  related to document management and storage. The metadata  342  may include document-specific metadata, as well as metadata for entities (e.g., owners of documents), parties, templates, and the like. The object store  350  is configured to store documents, such as contracts and other documents uploaded to the computing platform  320  by users  302 . The document action manager  360  is configured to perform numerous activities related to analyzing documents for actions and action dates, confirming analysis results with entities, and implementing detected actions, e.g., by generating modified documents. 
     The platform  320  may be realized using any number of physical computers, including just a single computer (as shown). Some of the depicted components may be provided by a third party. For example, the object store  350  may be implemented using Amazon Web Services or some other cloud-based service provider. Such computers and components are all considered herein to be part of the e-signature platform  320 , which may also be referred to herein as the “server.” 
     In example operation, a user  302 , such as user  302   a,  creates a document  370  for signature by one or more parties. The document  370  may be entirely original, i.e., created entirely from scratch, or it may be generated from a template, i.e., a document skeleton that includes standard content as well as fields for receiving custom data. The custom data may specify particular parties, i.e., persons signing the document, contact information, dates, and other information, such as document-specific terms. 
     In an example, the user  302   a  opens a browser or app on the user&#39;s device  202   a  and navigates to the computing platform  320 , e.g., to a landing page of the e-signature application  334  hosted by the web server  332 . The user  302   a  may then specify email or SMS (short message service) addresses of the party or parties to the document and may upload the document  370  to the platform  320 . The user  302   a  may then have the option to create data entry fields, which may include signature fields, date fields, and the like, and may submit the document for signature. In response to the user&#39;s submission, the platform  320  may send links by email or SMS, inviting the party or parties to review and sign the document. Once the parties have done so, the document may be considered complete, and the platform  320  may store the document, e.g., in the object store  350 . 
     In accordance with improvements hereof, the platform  320  analyzes the document  370  to determine whether the document indicates any future action and associated action date. For example, the platform  320  may invoke the document action manager  360 , which may perform OCR (optical character recognition) on the executed document, search for keywords that indicate future actions in the document text, and/or apply the document text to an NLP (natural language processing) engine trained to detect future actions and associated action dates. The result of such an analysis may be a determination of whether the document  370  indicates a future action (e.g., yes or no) and, if yes, the associated action date associated with the action. 
     In a particular example, the action to be determined is a renewal of the document, and the date of the action is an expiration date or renewal date of the document. In an example, the document action manager  360  may determine that the document is renewable based on keywords (e.g., the presence of a word having the root “renew” or the root “expir”) or by a pattern of text in the document that suggests a provision for renewal or expiration of the document. Also in an example, the document action manager  360  may determine that a document is renewable based on a prior pattern of renewals. For example, if a particular document has already been renewed on a particular month over a course of preceding years, the document action manager  360  may conclude that the document is renewable based on the prior history of renewals. The renewal date may be determined based on a field name associated with a date which appears in the document (e.g., a field name called “Renewal Date”), based on proximity to a word or words having any of the above-mentioned word roots, or based on other patterns in the document, for example. 
     Once the document action manager  360  has determined that the document  370  specifies an action, such as “renewable,” and an action date, such as an associated renewal date, the document action manager  360  may contact an entity of the document  370 , such as a person associated with the document, to confirm the determination. For example, the document action manager  360  may contact the entity by sending an email or text message requesting confirmation. The email may identify the determined action and action date and request that the entity confirm that the indicated action and date are proper. The entity is typically the owner of the document, such as the user  302   a,  or some other responsible person known to the platform  320 . The entity may confirm the information by clicking a link in the email or text message. Clicking the link by the entity causes the corresponding user device  202   a  to send a message to the platform  320  indicating that the information is confirmed. In some examples, the entity may also modify the information. For example, the entity may follow a second link in the email or text message to change an action date to something different from the one indicated. The entity may also disconfirm the specified information, e.g., by clicking a third link in the email or text message indicating that the information is incorrect (e.g., that the document is not renewable). In some examples, the email or text message includes only a single link, and clicking the link by the entity opens a page that allows the entity either to confirm, disconfirm, or modify the information. 
     Once the platform  320  receives confirmation from the entity, the e-signature platform  320  may update the metadata  342  in the database  340 , e.g., by storing an indication that the document  370  is renewable (e.g., by setting a flag) and by storing an indication of the associated action date as the determined renewal date. Such indications may be provided in a database record provided for the document  370  or in some other way. Preferably, the indications of action (e.g., renewability) and action date (e.g., renewal date) are stored in queryable elements of the database  340 , such that the records that contain them may be returned at a later time in response to queries of documents based on the action date. 
     One should appreciate that the above-described operations of the document action manager  360  may be scheduled at any convenient time. There is no need for the operations to be performed in real time, e.g., while the entity is logged on, uploading and configuring the document. Thus, the analysis of the document  370  may be asynchronous with the entity&#39;s activities and indeed may proceed in the background, ideally at times when the platform  320  is under light load. 
     In accordance with further improvements hereof, the platform  320  may query the database  334  to identify documents with upcoming action dates. For example, the platform  320  may query the database  334  automatically on some schedule, such as weekly, monthly, or at any other suitable time interval. Such queries may specify ranges of upcoming action dates, such as those which fall within the upcoming week, month, or any other suitable date range. 
     Based on query results, the platform  320  may perform activities in furtherance of the specified actions. Assume, for example, that a query returns the document  370 , e.g., based on the e-signature database  340  storing a renewal date for that document which falls within the query&#39;s specified date range. In such a case, the platform  320  may direct the document action manager  360  to generate a modified version  370   a  of the document  370 . In an example, the modified version  370   a  is similar to the document  370 , except that it is unexecuted and contains an updated action date. For instance, if the original renewal date of document  370  was Nov. 14, 2021, the document action manager  360  may provide the document with a new renewal date, such as Nov. 14, 2022. 
     When updating action dates, the document action manager  360  may increment action dates by one year, by default. This is merely an example, however. For instance, analysis of the document may indicate a different update interval, which may be used in place of the one-year default. In some examples, the e-signature database  340  includes a field or other data element for storing update intervals on a per-document basis. 
     Once the updated document  370   a  has been generated, the platform  320  may send a message (e.g., email or text) to the entity for approval. The message contains a link to the updated document  370   a.  For example, the entity may receive such a message and click the link. Clicking the link has the effect of downloading the document  370   a  to the entity&#39;s device, where the entity can review the document  370   a  and confirm, disconfirm, or modify the document. In some examples, modifications may involve changing field values, making text-based additions, or deleting portions of the document  370   a  that are no longer needed. 
     Assuming that the entity confirms the modified document, the computing platform  320  may process the document  370   a  for signature. For example, the platform  320  sends a message (e.g., email or text) to the identified party or parties. The message contains a link to the modified document  370   a.  The party or parties may review the document  370   a  and sign the document in the usual manner. 
     In the described arrangement, the platform  320  generates modified documents  370   a  automatically and typically in the background, i.e., outside the context of user sessions and out of band with user requests to create new documents. As it can create modified documents in the background, the platform  320  is less burdened with real-time user activities and can operate more efficiently. For example, ingesting a new document may involve many actions on the part of the platform  320 , such as creating a new session for the user, uploading the document from the user, converting the document from text to graphical format, receiving field values associated with the document, storing the field values in one or more databases, and storing the document itself. Such activities may be avoided or more conveniently scheduled, e.g., to coincide with periods of low activity, when new documents or versions thereof are created automatically by the platform  320 . The improved arrangement also benefits entities, as they are not required to generate and upload modified documents themselves. Entities are also prompted to renew their documents on time, thus avoiding potentially costly lapses in document coverage. 
       FIG.  4    shows example metadata  342  of the database  340  in additional detail. Here, such metadata  342  is seen to include metadata  410  about a document, metadata  420  indicative of an owner, and metadata  430  about other parties to or otherwise related to the document. One should appreciate that different or other metadata may be stored from that shown and that the illustration merely provides an example. 
     Metadata  410  may be provided on a per-document basis, for example, where records of the metadata  410  correspond to respective documents, like documents  370  and  370   a.  Example data elements or fields of the document metadata  410  may include the following:
         Doc-ID. A unique identifier of a document in the e-signature platform  320 .   Doc-Loc. A storage location of the document, such as an address of the document in the object store  350 .   Owner. A designated owner of the document (also referred to herein as an “entity”).   Parties. One or more parties to the document. Parties may be identified by respective Party-IDs.   Status. A status of the document, such as pending, executed, or expired.   Template. A skeleton form from which the respective document was created. Could be user-generated or a standard form provided by the e-signature platform  320 .   Actionable. An indicator of whether the document is actionable, e.g., renewable or subject to some other action. May be provided as a flag or other Boolean value.   Action-Date. An indicator of a date by which the respective action is due, such as a renewal date or an expiration date.   Family-ID. An identifier of a document family to which the document belongs. A “family” as used herein refers to a base document and any documents created from the base document according to actions, such as renewals. Multiple renewals may share the same Family-ID, and the existence of multiple renewals may itself contribute to a determination that a document is renewable.       

     As further shown in  FIG.  4   , owner metadata  420  may include the following data elements or fields, which may be provided on a per-owner basis, for example:
         Owner-ID. A unique identifier of an owner. May be based on the owner&#39;s name and/or on automatically-generated content.   Email. An email address of the owner.   Contact-Info. A name and other contact information of the owner.       

     Similar information may be provided for parties named in documents. For example, party metadata  430  may include the following:
         Party-ID. A unique identifier of a party. May be based on the party&#39;s name and/or on automatically-generated content.   Email. An email address of the party.   Contact-Info. A name and other contact information of the party.       

     Preferably, the metadata  410 ,  420 , and  430  are queryable, such that records of the respective metadata may be returned in response to queries that specify any of the data elements or fields thereof in query criteria. For example, actionable (e.g., renewable) documents may be identified by querying the document metadata  410  for all documents for which “Actionable =True.” Likewise, documents due for renewal during the next month may be found by querying the document metadata  410  for all documents for which “(Action-Date&gt;=Now) AND (Action-Date&lt;(Now+one month). It is thus evident that the metadata  342  of the database  340  may be used as a basis for identifying renewable documents and documents due for renewal within any specified time interval. 
       FIG.  5    shows example features of the document action manager  360  in additional detail. Here, the document action manager  360  is seen to have three main components: an action predictor  510 , an action confirmer  520 , and an action implementor  530 . In a non-limiting example, action predictor  510 , action confirmer  520 , and action implementor  530  are realized in software constructs that run in the memory  330  of the platform  320  and are run by the set of processors  324 . Action predictor  510  is configured to determine, i.e., by prediction, whether a particular document uploaded to the e-signature platform  320  is actionable (e.g., renewable), as well as an associated action date, such as a renewal date. Action confirmer  520  is configured to confirm or disconfirm predictions made by action predictor  510 , e.g., by contacting entities (e.g., by email or text) to obtain explicit confirmation that analyzed documents are renewable and their associated renewal dates. Action implementer  530  is configured to implement actions, such as by updating metadata  142  in the database  340  to reflect renewability and renewal dates, by generating modified documents (e.g., to contain new renewal dates), and by performing any other needed activities in furtherance of indicated actions. 
     As further shown in  FIG.  5   , action predictor  510  may include a text extraction engine  512 , a keyword analyzer  514 , and an NLP (natural language processing) engine  516 . These features are described in further detail below. 
     Text extraction engine  512  is configured to extract text from a document, such as by performing OCR (optical character recognition) on the document. For example, the document may be received as a PDF (portable document format) file, a TIFF (tagged image file format) file, a JPEG (Joint Photographic Experts Group) file, a PNG (Portable Network Graphics) file, a GIF (Graphic Interchange Format) file, or some other type of file in a graphical image format. The text extraction engine  512  converts pixel-based, graphical representations of text characters in the file to corresponding text-based data, such as ASCII or ANSI data, or data in some other textual format. Output of the text extraction engine  512  is typically a text file or a text stream. The output file or stream preferably presents text in the same order in which the graphical depictions of text are presented in the original file. 
     Keyword analyzer  514  searches the text file or stream for specified keywords that indicate a document action (e.g., that the document is renewable). The term “keywords” is intended to be broadly construed to include single words as well as phrases and dates. Examples of keywords may include any of the following:
         Words based on the root “renew,” such as renew, renewable, renewal, renewed, or the like.   Words based on the root “expir,” such as expire, expires, expired, expiration, or the like.   Words based on the root “term,” such as term, terminate, termination, or the like.   Any other words or phrases suggestive of document renewal, expiration, or termination.   Text that indicates dates, such as “November 1, 2021” or “11-1-2021.”       

     NLP engine  516  employs natural language processing for the purpose of determining whether a document is actionable and an associated action date. In an example, the NLP engine  516  includes a multi-class model  530  trained for this purpose. For example, multi-class model  530  may include an action classifier  532  and a date classifier  534 , which are trained to determine whether a document is renewable and an associated renewal date, for example. Multi-class models are commonly provided in NLP engines, with one suitable example being Amazon Comprehend. 
     In an example, the multi-class model  530  is trained using documents received by the platform  320 . For example, the multi-class model  530  may receive the text of documents and make corresponding predictions as to renewability and renewal date. The action confirmer  520  may send such predictions to entities, which may confirm the predicted renewability and renewal dates or disconfirm them. Any determination of renewability or renewal date which is confirmed may be provided to the model  530  as positive feedback, and any determination of the model  530  which is disconfirmed may be provided to the model  530  as negative feedback. Based on the positive and negative feedback, the multi-class model  530  can adjust its settings, e.g., by updating weights between nodes of one or more neural networks, converging over time on better and better predictions. 
     In some examples, the multi-class model  530  may be trained based on a corpus of previously stored documents. For example, the object store  350  may contain millions of documents and at least some of these documents may provide a training set for the multi-class model  530 . Training may be supervised or unsupervised. 
     To train the multi-class model  530  based on previously-stored documents, the e-signature platform  320  may analyze previous documents in the object store  350  to identify clear examples of renewals. A renewal may be identified, for example, based on a later document matching an earlier document in terms of the same entity, parties, template, or account, or based on other similarities, such as similar document text. A renewal may further be confirmed based on document terms and language (e.g., keywords). Determinations of renewals among previous documents may be made automatically, for example. Once clear examples of renewals have been identified, the platform  320  may direct the multi-class model  530  to generate predictions of renewability and renewal dates using the earlier documents. If the model  530  generates a correct prediction, the model receives positive feedback. Otherwise, the model may receive no feedback or negative feedback. The model  530  may also be trained based on documents that clearly are not renewable. In such cases, positive and/or negative feedback may be given based on whether the model  530  correctly predicts that a document is not renewable. 
     In an example, the action predictor  510  uses a layered approach in determining whether documents are actionable (e.g., renewable) and action dates (e.g., renewal dates). If one layer fails to indicate clearly whether a document is actionable, one or more subsequent layers may be tried. For example, the action predictor  510  first applies keyword analysis (e.g., as a first layer) to determine whether a document is renewable. If keyword analysis produces a clear result of renewability, then the document may be deemed renewable without requiring the use of the NLP engine  516 . The NLP engine  516  may thus be regarded as a second-layer approach in case keyword analysis fails to provide a clear result. Results of the NLP Engine  516  may themselves be subject to confirmation by entities (e.g., as a third-layer approach). 
       FIGS.  6 - 8    show example methods  600 ,  700 , and  800  that may be carried out in connection with the environment  300 . The methods  600 ,  700 , and  800  are typically performed, for example, by the software constructs described in connection with  FIG.  3   , which reside in the memory  330  of the computing platform  320  and are run by the set of processors  324 . The various acts of methods  600 ,  700 , and  800  may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from those illustrated, which may include performing some acts simultaneously. 
       FIG.  6    shows an example method  600  of receiving a document into the computing platform  320  (e.g., a server or other computing device). For example, method  600  is performed by the platform  320  in response to a user logging onto the platform  320  to provide a new document  370  for signature. 
     At  610 , the user  302  uploads the document  370 , e.g., by dragging and dropping a document into a region of a web page downloaded from the e-signature platform  320  to the user&#39;s device  202 . At this time, the user  302  may also specify email addresses of parties to the document and may specify any required data-entry fields. 
     At  620 , which may be performed at a later time, the platform  320  performs an analysis of the uploaded document  370  to identify an action indicated by the document, such as a renewal, and a corresponding action date, such as a renewal date, by which the specified action is due to be performed. Act  620  may involve operation of the action predictor  510 , described in connection with  FIG.  5   , and may be performed in the background, i.e., out of band with the user sessions during which the documents are uploaded. 
     At  630 , the platform  320  obtains confirmation that the identified action and action date are proper. For example, action confirmer  520  ( FIG.  5   ) messages an entity of the document, such as the owner, requesting confirmation that the document is indeed renewable and that the indicated renewal date is proper. In an example, the message includes a link that the user may click to confirm renewability and renewal date. One should appreciate that act  630  may be optional in some embodiments, as the platform  320  may also proceed without confirmation. 
     At  640 , the platform  320  creates and stores metadata for the analyzed document in the database  340 . For example, the platform  320  creates a new record for the document  370  in the document metadata  410 . The new record may include an indicator of the action, e.g., a value of “yes” in the “actionable” field, and an associated action-date. 
     The acts of method  600  are preferably completed shortly after the user has uploaded the document, such as over the course of the following days. In this manner, the computing platform  320  is not burdened by having to perform document analysis in real time. No particular timing is required, however. Also, once the acts of method  600  are complete, the platform  320  is able to query the document metadata  410  based on action-date to identify any documents with upcoming actions, such as renewals. 
       FIG.  7    shows an example method  700  of generating a modified version of a document prior to a specified action date. Method  700  may be performed at any time after the acts of method  600  are completed. 
     At  710 , the computing platform  320  queries the database  342  to identify documents with upcoming action dates. For example, the platform  320  runs a query of the document metadata  410  that selects documents for which “actionable” is true and “action-date” falls within a specified date range, such as any time over the next month. 
     At  720 , the platform  320  obtains query results as metadata, such as Doc-ID, of a document  370  that meets the query criteria. The query may return additional metadata, such as the associated entity (e.g., owner), action, action date, and email or SMS addresses of parties to the document. 
     At  730 , the platform  320  modifies the document  370  in accordance with the specified action. For example, if the action is to renew the document, the e-signature platform  320  may provide a new version  370   a  of the document that specifies a new renewal date. Other content of the new version  370   a  may be similar to that of the original. 
     At  740 , the platform  320  obtains confirmation that the modified document is proper. For example, the computing platform  320  sends a message to the entity. The message (e.g., email or SMS) may contain a link to the modified document  370   a.  The entity may receive the message and view the modified document  370   a  by activating the link. The entity may then confirm that the modified version is proper. Alternatively, the entity may disconfirm the modified document. 
     Optionally, at  750 , the platform  320  receives further modifications of the document  370   a  made by the entity. For example, upon viewing the modified document  370   a  at step  740 , the entity may make further changes to the document, such as by changing field values, adding text, or removing text. 
     At  760 , upon receiving confirmation that the modified (or further modified) document is proper, the platform  320  transmits the modified document  370   a  (or a link thereto) to the associated party or parties, e.g., those identified in the “Parties” field of the document metadata  410 . Such parties may then execute the document  370   a.  Once all parties have executed the document, the platform  320  may store the document  370   a  in the object store  350 . At or about this time, the e-signature platform  320  may create a new record in the document metadata  410  for the modified document  370   a.  The new record may be accorded a new Doc-ID and a new action date, which may reflect one year from the previous action date (or any other suitable time interval). The new record may also specify a Family-ID that matches the Family-ID of the original document  370 . In this manner, all documents belonging to the same family may be easily found by querying the document metadata  410  for a particular Family-ID. 
       FIG.  8    shows an example of alternative method  800  according to another example of the described subject matter. 
     At  810 , the computing platform  320  determines a time at which to update an electronic document  370 . The determination is made based on content of the document. For example, the determination identifies an action date specified by the document, such as a renewal date. 
     At  820 , the platform  320  retrieves the document  370  at or prior to the determination of the time. For example, the platform  320  retrieves the document  370  from the object store  350  prior to the identified renewal date. 
     At  830 , the platform  320  extracts data from the document. The extracted data is indicative of at least one change to be made to the document. For example, the extracted data may include a renewal date determined to be present in the document. 
     At  840 , the platform  320  determines at least one modification to the electronic document  370  based on the extracted data. For example, the platform  320  may determine that a renewal date present in the document  370  should be changed to a new renewal date, e.g., one year hence. 
     At  850 , the platform  320  modifies the electronic document to include the at least one modification at or prior to the determined time. This act may include, for example, replacing the original renewal date with the newly determined renewal date, thereby producing a modified document  370   a.  The modified document  370   a  may then be distributed to parties for signature. 
       FIG.  9    shows an example sequence of events that may be carried out in accordance with certain embodiments. The depicted events involve the above-described e-signature application  334 , object store  350 , text extraction engine  512 , and NLP (natural language processing) engine  516 . 
     At  910 , an entity uploads a document  370  to the e-signature application  334 . The entity may be an owner of document  370 , or someone working at the behest of the owner. 
     At  912 , the e-signature application  334  submits the document  370  for storage in the object store  150 . 
     At  920 , which is generally sometime later, the e-signature application  334  directs the action predictor  510  to extract text from the document  370 , e.g., via operation of the text extraction engine  512 . At  922  the action predictor  510  requests the document  370  from the object store  350 , and at  924  the text extraction engine  512  receives the document  370  and extracts the text of the document  370 , e.g., using OCR. At  926  the text extraction engine  512  returns the text of document  370  to the e-signature application  334 . 
     At  930 , the e-signature application  334  scans the received document text for keywords that indicate an action, such as renewal. For example, the e-signature application  334  invokes the keyword analyzer  514  to search the document text for keywords indicative of renewal and renewal date. 
     At  932 , if keyword searching is unable to determine that the document is renewable and a renewal date, the e-signature application  334  provides the document text to the multi-class model  530  in the NLP engine  516 . The multi-class model  530  then processes the document text to generate a determination of actionable status (e.g., renewable) and an action date. At  934 , the determined actionable status and action date are returned to the e-signature application  334 . 
     At  940 , the e-signature application  334  obtains and receives confirmation of the actionable status and date, e.g., from the entity/owner. At  950 , the e-signature application  334  sets the document metadata, e.g., by creating a new record in the document metadata  410  for the document  370 . The new record may include the determined actionable status and action date, as well as other field values. 
     An improved technique has been described for document management. The technique includes performing a text-based analysis (e.g., by action predictor  510 ) of a document  370  submitted for signature and/or storage. The text-based analysis searches for terms and/or other content that indicate a future action to be performed and a corresponding action date by which to perform the action. In response to detecting such terms and/or other content, the technique further includes creating metadata indicative of the action and associated action date and storing such metadata in a database  340 . The technique further includes querying the database  340 , e.g., prior to or upon the action date, and creating a modified version of the document to implement the detected action. 
     Having described certain embodiments, numerous alternative embodiments or variations can be made. For example, although specified actions and action dates have been described herein as renewals and renewal dates, these are merely examples. Other examples of actions may include document expirations and expiration dates. In such cases, there may be an opportunity to create new documents upon expiration of previous ones. Still other examples of actions may include archiving a document for document retention, deleting a document after expiration of document retention period, finding similar or related documents, creating amendments to documents, and the like. 
     Further, although features have been shown and described with reference to particular embodiments hereof, such features may be included and hereby are included in any of the disclosed embodiments and their variants. Thus, it is understood that features disclosed in connection with any embodiment are included in any other embodiment. 
     Further still, the improvement or portions thereof may be embodied as a computer program product including one or more non-transient, computer-readable storage media, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like. Any number of computer-readable media may be used. The media may be encoded with instructions which, when executed on one or more computers or other processors, perform the process or processes described herein. Such media may be considered articles of manufacture or machines, and may be transportable from one machine to another. 
     As used throughout this document, the words “comprising,” “including,” “containing,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Also, as used herein and unless a specific statement is made to the contrary, the word “set” means one or more of something. This is the case regardless of whether the phrase “set of” is followed by a singular or plural object and regardless of whether it is conjugated with a singular or plural verb. Also, a “set of” elements can describe fewer than all elements present. Thus, there may be additional elements of the same kind that are not part of the set. Further, ordinal expressions, such as “first,” “second,” “third,” and so on, may be used as adjectives herein for identification purposes. Unless specifically indicated, these ordinal expressions are not intended to imply any ordering or sequence. Thus, for example, a “second” event may take place before or after a “first event,” or even if no first event ever occurs. In addition, an identification herein of a particular element, feature, or act as being a “first” such element, feature, or act should not be construed as requiring that there must also be a “second” or other such element, feature or act. Rather, the “first” item may be the only one. Also, and unless specifically stated to the contrary, “based on” is intended to be nonexclusive. Thus, “based on” should not be interpreted as meaning “based exclusively on” but rather “based at least in part on” unless specifically indicated otherwise. Although certain embodiments are disclosed herein, it is understood that these are provided by way of example only and should not be construed as limiting. 
     Those skilled in the art will therefore understand that various changes in form and detail may be made to the embodiments disclosed herein without departing from the scope of the following claims.