Methods and Systems for User Authentication and File Access Control

Abstract

This disclosure relates, in general, to methods, systems, devices, and non-temporary computer-readable media for providing access to stored files. These systems can significantly reduce the human capital required to transmit files to customers and other stakeholders across a broad business. Furthermore, these systems can enable the secure transmission of these files without imposing burdensome security requirements on the file recipients. In particular, embodiments of this disclosure may utilize a server to generate a Uniform Resource Identifier (URI) associated with a file. This URI may be transmitted to an end user who uses it to request access to the file. The server may use various pieces of information received from this request to verify the end user's identity locally and using an identity provider. The server may then permit or deny the end user's request based on the results of its verification.

Description

Technical Field

[0001] This disclosure generally relates to data management, and more particularly, to methods, systems, devices, and non - transient computer - readable media for providing access to stored files.

Background Art

[0002] For many modern organizations, sharing files with relevant stakeholders is a critically important business component. These files can include contracts, invoices, information notices, and certificates. These files often contain confidential data that must be kept secret. Beyond concerns about confidentiality, organizations often need proof of file delivery to meet regulatory requirements or to provide evidence in case of disputes. Further, to meet various regulatory requirements or to maintain evidence in case of disputes, many organizations also desire proof that files were delivered to their intended recipients.

[0003] However, the vast amount of files that modern organizations need to share externally poses significant challenges. Manually sending such a large number of files, whether electronically or otherwise, is extremely inefficient, consuming valuable human capital on a mundane task while significantly increasing the error rate. This increases the likelihood that unauthorized parties will access confidential information, risking the reputation of the organization and exposing the organization to legal consequences. Further, the issue of securely sending files to suppliers, customers, shareholders, and various other external parties is exacerbated by users' low tolerance for the friction induced by additional security measures.

[0004] Existing methods for sharing files with third parties tend to be slow, labor-intensive, and error-prone. The common practice of electronically transferring files often leaves transmitted data accessible and vulnerable, sometimes indefinitely. This not only undermines the confidentiality of sensitive information but also exacerbates the risk of unauthorized access, subsequently increasing legal and reputational risks.

[0005] Therefore, there is a long-sought-after need to develop a system that can securely transmit files electronically to external third parties without requiring significant human intervention or requiring recipients to comply with burdensome security measures. The disclosures and embodiments herein set out to address this long-sought-after need. [Brief explanation of the drawing]

[0006] This disclosure can be better understood by referring to the following drawings. The elements of the drawings are not necessarily to scale with respect to one another, but rather the emphasis is on clearly illustrating the principles of this disclosure. Furthermore, similar reference figures designate corresponding parts throughout several of the drawings.

[0007] [Figure 1] Figure 1 is a block diagram of an exemplary embodiment of a file generation and management system.

[0008] [Figure 2] Figure 2 is a block diagram of an exemplary embodiment of the file creation subsystem.

[0009] [Figure 3] Figure 3 is a flowchart illustrating an exemplary method for generating a file from a file template.

[0010] [Figure 4] Figure 4 is a flowchart illustrating an exemplary method for managing the deletion of generated files.

[0011] [Figure 5] Figure 5 is a flowchart of a first exemplary method for managing the generated files.

[0012] [Figure 6] Figure 6 is a flowchart of a second exemplary method for managing the generated files.

[0013] [Figure 7] Figure 7 is a diagram of the layout of an exemplary file template.

[0014] [Figure 8] Figure 8 is a diagram of the data structure of an exemplary file template (e.g., the exemplary file template of Figure 7).

[0015] [Figure 9] Figure 9 is a flowchart of an exemplary method for generating a file from a file template.

[0016] [Figure 10] Figure 10 is a flowchart of an exemplary method for saving the generated file.

[0017] [Figure 11] Figure 11 is a flowchart of an exemplary method for controlling access to the saved file.

[0018] [Figure 12] Figure 12 is a block diagram of a computing device that can be a client device or a server in this specification.

[0019] [Figure 13] Figure 13 is a block diagram of one aspect of a file creation subsystem.

[0020] [Figure 14] FIG. 14A and FIG. 14B are flowcharts of an exemplary method for managing access to a generated file.

[0021] [Figure 15] FIG. 15 is a sequence diagram of one aspect of an orchestrator subsystem. **DETAILED DESCRIPTION OF THE INVENTION**

[0022] Next, a detailed description will be given of exemplary embodiments shown in the accompanying drawings. The following description refers to the accompanying drawings, and the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following description of the exemplary embodiments do not represent all implementations that are consistent with the present invention. Instead, these are merely examples of apparatuses and methods that are consistent with aspects related to the present invention described in the appended claims. Specific aspects of the present disclosure are described better below. If the terms and definitions provided herein conflict with the terms and / or definitions incorporated by reference, the terms and definitions provided herein shall prevail.

[0023] The present disclosure generally relates to systems and methods for managing file generation and retention. These systems can be used across a wide range of businesses to greatly automate file generation and storage. By utilizing nested file templates as described below, the systems of the present disclosure make it easier to generate file templates. Further, by using a file retention and storage system as described below, the systems of the present disclosure can simplify the process of ensuring that files are retained for an appropriate period and further ensuring that files are deleted when they are no longer needed. Thus, the systems and methods herein can assist with various regulatory compliance and can assist with protecting confidential information by destroying or securely erasing / removing files after a deletion trigger event.

[0024] For many, or most, modern organizations, a critical aspect of ongoing operations is the creation, communication, and retention of various files for the organization's relevant stakeholders. These files can serve a variety of purposes, such as communicating relevant information, making certain requests, or fulfilling certain legal obligations. For example, compliance files are maintained in the financial and healthcare industries.

[0025] The proliferation of these files creates problems for businesses. Manually entering all relevant customer information is a time-consuming and costly task. Organizations need the ability to automate this process and create files that populate fields based on specific criteria. For example, if files are generated that must comply with each given state law, each generated file should not only populate the respective fields but also generate the applicable state sections.

[0026] Broadly speaking, embodiments of this disclosure can generate a file from a file template in response to receiving a file creation request. Among other pieces of information, a file creation request may specify the template to be used and one or more entries of information to be used to fill in the file template. As will be discussed further below, this process may include the step of generating one or more subfiles. Subfiles are generated from one or more templates (called subtemplates) through the same process. This process may continue to occur recursively through multiple layers of subfiles (i.e., subfiles of subfiles). Finally, the final generated file may be stored in a file storage system. Thereafter, the file is associated with metadata, trigger parameters, and / or action items, which automatically control the retention and deletion of the file, as will be further detailed below.

[0027] In a first embodiment, a method for generating a file using nested templates is disclosed. In one aspect of the first embodiment, a first server may receive a first file template creation request from a client device. In response to receiving the first file template creation request, the first server may generate a first file template comprising static content data and dynamic content markers. The first server may then receive a first file creation request from a client device. Generally, the first file creation request may include a set of one or more merge parameter data structures. In response to receiving the first file creation request, the first server creates a copy of the first file template comprising static content data and dynamic content markers. Typically, one or more dynamic content markers in the first file template are associated with their respective merge parameter identifiers. The first server then inserts the merge parameter data into one or more dynamic content markers in the copy of the first file template. This insertion is performed using a set of one or more merge parameter data structures. Generally, a set of one or more merge parameter data structures includes a merge parameter identifier and a merge parameter data source, and the merge parameter data is obtained from one or more of these merge parameter data sources.

[0028] In a second embodiment, a computer implementation method for managing generated files is disclosed. In one embodiment of the second embodiment, a first server may receive a first file template creation request from a client device. In response to receiving the first file template creation request, the first server may generate a first file template comprising static content data and dynamic content markers. Subsequently, the first server may receive another first file creation request from a client device. In response to receiving the first file creation request, the first server may generate a first file from the first file template. The first server may then store the first file in non-volatile memory accessible by the first server. Subsequently, the first server may detect a delete trigger event. In response to detecting a delete trigger event, the first server may delete the first file from non-volatile memory.

[0029] In a third embodiment, a method for managing access to generated files displayed on a third-party application is disclosed. In one embodiment of the third embodiment, a first server may store a first file created from a file template in non-volatile memory accessible by the first server. The first server may then receive a connection request relating to a first user account of the first server. Typically, this connection request is received from a second server associated with a third-party portal. Furthermore, the first user account is typically associated with a first user. In response to receiving the connection request, the first server may authenticate the second server to connect to the first user account based on the received connection request for the first user account. In response to authentication by the second server, the first server may generate a first uniform resource identifier (URI) associated with the first file. Typically, the first URI links to a first resource containing the first file.

[0030] After generating the first URI, the first server may send the first URI and information identifying the first file to the second server. Subsequently, the first server may detect a delete trigger event. In response to the detection of a delete trigger event, the first server may delete the first file from non-volatile memory.

[0031] In a fourth embodiment, a method for managing access to a generated file is disclosed. In one embodiment of the fourth embodiment, the server may store the file in non-volatile memory accessible by the server. Subsequently, the server may receive a Uniform Resource Identifier (URI) generation request from a first client device. Typically, the first URI is associated with a file, an identity, and a dynamic expire time. In response to receiving the URI generation request, the first server generates a Uniform Resource Identifier (URI) associated with the file. Typically, the generated URI links to the resource containing the file and is generated on the server. After generating the URI, the server may, at the request of the first client device, send the URI to a second client device.

[0032] After sending the URI to the second client device, the server may receive a request from the second client device using the URI to request a resource. In response, the server may validate the identity through the server to ensure it is an authorized identity. To do this, the server may check that the identity is included in the server's database of authorized identities. The server may also validate the identity through an identity provider, which requests the user to log in to their identity on the identity hosting platform. The server may then grant or deny access to the resource based on the responses from the server and the identity provider.

[0033] In a fifth embodiment, a method for generating files using nested templates is disclosed. In one embodiment of the first embodiment, a first file template may be generated. Generally, the first file template may include static content data and dynamic content markers.

[0034] In one embodiment of the fifth embodiment, a copy of the first file template may be created. Typically, the copy of the first file template may include both static content data and dynamic content markers from the first template. The dynamic content markers of the first file template (and therefore copies of these dynamic content markers in the copy of the first file template as well) may be associated with their respective merge parameter identifiers.

[0035] In one embodiment of the fifth embodiment, merge parameter data may be inserted at the location of one or more dynamic content markers in a copy of the first file template. Generally, merge parameter data is obtained from a set of one or more merge parameters. A merge parameter includes at least a name (merge parameter identifier) ​​and a data type (merge parameter data source), and may include formats such as JSON, XML, and YAML, to name a few. Each merge parameter structure may include a merge parameter identifier and a merge parameter data source. Merge parameter data may be obtained from a merge parameter data source, and collective merge parameter data may similarly be obtained from a collective merge parameter data source for an entire set of one or more merge parameter tuples.

[0036] Generally, dynamic markers are removed from the copy of the first file template either explicitly or implicitly as part of the insertion process. For example, dynamic content markers are replaced.

[0037] In an additional embodiment of the fifth embodiment, the first file template may be stored in non-volatile memory after it has been generated.

[0038] In an additional embodiment of the fifth embodiment, a file creation request may be received from a client device. Among other potential data, the file creation request may include a first file template identifier and the set of one or more merge parameter tuples described above. Generally speaking, the first file template identifier may be associated with a first file template, thereby enabling the request to identify the template on which the requested file should be based. The step of receiving a file creation request may, among other effects, trigger the creation of a copy of the first file template.

[0039] In an additional embodiment of the fifth embodiment, a copy of the first file template may be sent to the first destination. As described above, when the merge parameter data has been inserted into all of the dynamic data markers of the first copy of the first file template, the first file template (which can be considered "filled") represents a fully generated file. Since a fully generated file is usually desired, a copy of the first file template is typically sent only after the merge parameter data has been inserted into all of the dynamic content markers of the first file template. The first destination may be associated with a first destination identifier, which may be indicated in the file creation request.

[0040] In an additional embodiment of the fifth embodiment, the first destination identifier may be associated with native non-volatile memory. Correspondingly, a first copy of the first file template may be stored in native non-volatile memory after it has been generated.

[0041] In an additional embodiment of the fifth embodiment, the process of inserting merge parameter data into one or more dynamic content markers of a copy of the first file template may first begin with the step of identifying a merge parameter tuple from a set of one or more merge parameter tuples. A merge parameter tuple can be identified by comparing the merge parameter identifier associated with each merge parameter tuple with the merge parameter identifier associated with the current dynamic content marker. A merge parameter tuple containing a merge parameter identifier that matches the merge parameter identifier associated with the current dynamic content marker may then be selected.

[0042] Next, merge parameter data can be retrieved from the merge parameter data source indicated by the selected merge parameter tuple. The retrieved merge parameter data can then be inserted at the current dynamic content marker's position. This process can then be repeated for the next remaining dynamic content markers to which merge parameter data has not yet been inserted.

[0043] In an additional embodiment of the fifth embodiment, at least one of the one or more merge parameter tuples may include a merge parameter data source containing a native data payload. Furthermore, at least one of the one or more merge parameter tuples may include a merge parameter data source containing a remote data pointer.

[0044] In an additional embodiment of the fifth embodiment, at least a first merge parameter tuple from the identified merge parameter tuple includes a first merge parameter data source that represents a second file template. The step of obtaining merge parameter data from this first merge parameter data source can be achieved by recursively generating subfiles. The process of recursively generating subfiles can be initiated by creating a copy of the second file template. The merge parameter data can then be inserted into one or more dynamic content markers of the copy of the second file template using one or more merge parameter tuples. The generated subfiles can then be inserted into associated dynamic content markers of the copy of the first file template.

[0045] In an additional embodiment of the fifth embodiment, the second file template is associated with a second file template identifier. The first merge parameter data source can indicate the second file template by identifying it with the second file template identifier.

[0046] In a sixth embodiment, a method for managing the saving and deletion of generated files is disclosed.

[0047] In one embodiment of the sixth embodiment, the first file may be generated from the first file template.

[0048] In one embodiment of the sixth embodiment, the first file may be stored in non-volatile memory after it has been generated.

[0049] In one embodiment of the sixth embodiment, the non-volatile memory may be monitored to detect a delete trigger event.

[0050] In one embodiment of the sixth embodiment, the first file may be deleted from non-volatile memory in response to the detection of a delete trigger event.

[0051] In an additional embodiment of the sixth embodiment, the delete trigger event may include a combination of one or more parameters. For example, in one embodiment, the delete trigger event may include a combination of one or more of the following: (i) elapsed time since the first file was created; (ii) user views (number of views); (iii) IP address or viewing address; (iv) time spent viewing the first file; or (v) expiration date; or (vi) response to a biometric scan.

[0052] In an additional embodiment of the sixth embodiment, the deletion trigger event may be the elapsed time of one hour from the date associated with the creation of the first file.

[0053] In an additional embodiment of the sixth embodiment, the deletion trigger event may be that the number of times the first file has been accessed exceeds the first access limit threshold.

[0054] In an additional embodiment of the sixth embodiment, a first file template may be generated. For example, in one embodiment, the first file template may include static content data and dynamic content markers. A copy of the first file template may be created to generate a first file from the first file template. Generally, a copy of the first file template may include both static content data and dynamic content markers from the first template. The dynamic content markers of the first file template (and therefore copies of these dynamic content markers in the copy of the first file template as well) may be associated with their respective merge parameter identifiers.

[0055] Next, merge parameter data can be inserted at the location of one or more dynamic content markers in the copy of the first file template. Generally, merge parameter data is obtained from a set of one or more merge parameter tuples. Each merge parameter tuple may contain a merge parameter identifier and a merge parameter data source. Merge parameter data may also be obtained from a merge parameter data source, and similarly, collective merge parameter data may be obtained from a collective merge parameter data source for the entire set of one or more merge parameter tuples.

[0056] In a seventh embodiment, a method for controlling access to the generated file is disclosed.

[0057] In one embodiment of the seventh embodiment, the first file may be generated from a first nested file template.

[0058] In one embodiment of the seventh embodiment, the first file may be stored in non-volatile memory.

[0059] In one embodiment of the seventh embodiment, a first uniform resource identifier (URI) associated with the first file may be generated. Generally, the first URI may link to a first resource containing the first file.

[0060] In one embodiment of the seventh embodiment, the first URI (along with information identifying the first file) may be provided to an authenticated third-party portal.

[0061] In an additional embodiment of the seventh embodiment, a URI can be used to access a first file. Specifically, a request for a first resource identified by the first URI may be received from an authenticated third-party portal. Generally, a request for a first resource may be sent in response to input from a first user provided to an authenticated third-party portal to access a first file. The first resource may then be provided to the first user in response to the receipt of a request for the first resource. Generally, the step of providing the first resource to the first user includes the step of providing the first file to the first user.

[0062] In an additional embodiment of the seventh embodiment, a third-party portal may be authenticated with respect to a first user account associated with a first user. To begin, a request to authenticate the third-party portal with respect to a first user may be received from the third-party portal. Generally, the authentication request includes credentials derived from local login credentials associated with the first user account. The credentials may then be analyzed to verify that the credentials are derived from the correct login credentials associated with the first user account. In response to the verification of the credentials, a response indicating that the third-party portal has been authenticated with respect to the first user may then be sent to the third-party portal.

[0063] In an additional embodiment of the seventh embodiment, the response sent to the third-party portal may include an authentication token for the first user account.

[0064] In an additional embodiment of the seventh embodiment, the information identifying the provided first file may include the title associated with the first file. Furthermore, the input from the first user provided to the authenticated third-party portal to access the first file may include the input from the first user selecting a display title associated with the first user, which is hyperlinked to the first URI.

[0065] In an additional embodiment of the seventh embodiment, a first nested file template may be generated.

[0066] In an additional embodiment of the seventh embodiment, the first nested file template may include static content data and dynamic content markers. Furthermore, the first file may be generated from the first nested file template in a process that begins with creating a copy of the first nested file template containing the static content data and dynamic content markers. Generally, one or more dynamic content markers of the first nested file template may be associated with their respective merge parameter identifiers. The merge parameter data may then be inserted into one or more dynamic content markers of the copy of the first nested file template using one or more sets of merge parameter tuples. Generally, one or more sets of merge parameter tuples may each include their respective merge parameter identifiers and merge parameter data sources. Furthermore, the merge parameter data may be retrieved from one or more respective merge parameter data sources.

[0067] Figure 1 is a block diagram of an exemplary embodiment of a file generation and management system.

[0068] Figure 2 shows a block diagram of a file creation subsystem according to an exemplary embodiment of the present disclosure. As shown in the figure, the file creation subsystem 107 may comprise a dispatch subsystem 204, a parameter acquisition subsystem 206, a security subsystem 209, a file generation subsystem 212, a flow director subsystem 215, and a storage subsystem 108. Also shown as external elements interacting with the file creation subsystem 107 are a third-party system 219, a third-party data source 220, and a third-party data destination 221.

[0069] Generally speaking, the dispatch subsystem functions to coordinate the operation of the file creation subsystem 107. The dispatch subsystem 204 may also act as an interface between the rest of the file creation subsystem and an external third-party system 219 that uses the file creation subsystem 107 (for example, for creating and saving various files). Roughly speaking, when the dispatch subsystem 204 receives a file creation request, it may interface with the parameter acquisition subsystem 206, the security subsystem 209, and the generation subsystem 212 as part of the process of initiating the handling of the request.

[0070] With respect to the parameter retrieval subsystem 206, the file creation request may include information (called merge parameters) that can be used to populate the selected template. In addition to the data directly included in the file creation request, the file creation request may instead specify a source for the indicated data, such as a universal resource identifier (URI). The parameter retrieval subsystem 206 may operate to access the indicated URI in an appropriate third-party data source 220, retrieve the indicated data, and then provide the retrieved data to the generation subsystem 212 as fully resolved merge parameters.

[0071] With respect to the generation subsystem 212, a file creation request may include an identifier for a file template called a file template ID. This indicated template can be used as the basis for generating the requested file. Using this information, the generation subsystem 212 can obtain a copy of the indicated template and then populate the dynamic elements of the indicated template with merge parameters provided by the dispatch subsystem 204 and the parameter acquisition subsystem 206.

[0072] Specifically, as shown in Figure 2, the file generation subsystem 212 may comprise a render engine 213, a composition engine 214, and a template database 218. Generally speaking, the render engine 213 may first operate to retrieve a copy of the template, indicated by the file template ID, from the template database 218. The render engine 213 may then proceed to replace the dynamic elements of the template with matching merge parameters received from the dispatch subsystem 204 and the parameter retrieval subsystem 206.

[0073] After a file is generated by the generation subsystem 212, the generated file may be provided to the flow director subsystem 215. The flow director subsystem 215 can then handle the process of sending the generated file to its intended destination. One such possible destination is the storage subsystem 108. Another possible destination is one or more external third-party data destinations 221, such as a cloud service provider. For files stored in the storage subsystem 108, the flow director subsystem may also provide metadata indicating the retention policy for the file.

[0074] Specifically, as shown in Figure 2, the file storage subsystem 108 may comprise a storage engine 216 and file storage 217. Generally speaking, the storage subsystem 108 may function to perform two interrelated functions. For one function, the storage subsystem 108 may receive generated files from the flow director subsystem 215 and store the files on the file storage 217 along with metadata indicating the retention policy for the stored files. For the other function, the storage subsystem 108 may periodically scan the metadata of generated files stored on the file storage 217 and determine whether their associated retention metadata indicates that a delete trigger event has occurred. If the storage subsystem 108 determines that a delete trigger event has occurred for a generated file, the storage engine 216 may proceed to delete the file from the file storage 217.

[0075] Figure 3 is a flowchart showing the process of generating a file from a file template. To begin, as shown in block 302 of Figure 3, the template creation subsystem 106 generates a first file template.

[0076] After the template creation subsystem 106 generates the first file, the file creation subsystem 107 creates a copy of the first file template through the generation subsystem 212, as shown in block 303 of Figure 3.

[0077] Subsequently, the file creation subsystem 107 inserts the merge parameter data into one or more dynamic content markers of the copy of the first file template through the generation subsystem 212.

[0078] Figure 4 is a flowchart of the process for managing the deletion of generated files. To begin, as shown in block 402 of Figure 4, the file creation subsystem 107 generates a first file from a first file template.

[0079] After the file creation subsystem 107 generates the first file, the orchestrator subsystem 105 saves the first file to the non-volatile memory of the file storage 217 of the storage subsystem 108, as shown in block 403 of Figure 4.

[0080] After the orchestrator subsystem 105 saves the first file to the non-volatile memory of the file storage 217, the storage subsystem 108 can monitor for and eventually detect a delete trigger event through the storage engine 216, as shown in block 404 of Figure 4.

[0081] After the storage engine 216 detects the delete trigger event, the storage subsystem 108 deletes the first file from the non-volatile memory of the file storage 217 of the storage subsystem 108 through the storage engine 216, as shown in block 405 of Figure 4.

[0082] Figure 5 is a flowchart showing the first process for managing the generated files. To begin, as shown in block 502 of Figure 5, the file generation and storage system 102 generates a first file from a first nested file template.

[0083] After the file generation and storage system 102 generates the first file, it stores the first file in the non-volatile memory of the file storage 217 of the storage subsystem 108, as shown in block 503 of Figure 5.

[0084] After the file generation and storage system 102 saves the first file to non-volatile memory, the file generation and storage system 102 generates a uniform resource identifier (URI) that links to the first file, as shown in block 504 of Figure 5.

[0085] After the file generation and storage system 102 generates a URI that links to the first file, the file generation and storage system 102 provides the authenticated third-party portal with information identifying the first file and the first URI, as shown in block 505 of Figure 5.

[0086] Figure 6 is a flowchart showing the second process for managing the generated files. To begin, as shown in block 602 of Figure 6, the file generation and storage system 102 generates a first file from a first nested file template.

[0087] After the file generation and storage system 102 generates the first file, it stores the first file in the non-volatile memory of the file storage 217 of the storage subsystem 108, as shown by block 603 in Figure 6.

[0088] After the file generation and storage system 102 saves the first file to non-volatile memory, the file generation and storage system 102 generates a uniform resource identifier (URI) that links to the first file, as shown in block 604 of Figure 6.

[0089] After the file generation and storage system 102 generates a URI that links to the first file, the file generation and storage system 102 sends the generated URI to the first user, as shown in block 605 of Figure 6.

[0090] After the file generation and storage system 102 sends the URI to the first user, the file generation and storage system 102 may receive a request using the first URI, as shown in block 606 of Figure 6.

[0091] After the file generation and storage system 102 receives a request using the first URI, the file generation and storage system 102 may evaluate one or more parameters to verify the validity of the first request, as shown in block 607 of Figure 6.

[0092] After the file generation and storage system 102 verifies the validity of the received request, it may, in response to the verification of the first request, provide the first resource to the first user, as shown in block 608 of Figure 6.

[0093] Figure 7 shows a schematic diagram illustrating the layout of an exemplary file template. As shown in the figure, a file template may consist of one or more static elements (indicated here by text and dotted lines) and one or more dynamic elements (indicated by text in parentheses). In the exemplary template shown in Figure 7, the dynamic elements include a dynamic logo, dynamic address line 1, dynamic address line 2, dynamic address line 3, dynamic greeting, dynamic name 1, dynamic name 2, dynamic name 3, and dynamic name 4. As also shown in the figure, a template may have one or more nested subtemplates (indicated as nested subtemplate 1 in Figure 3).

[0094] Figure 8 shows a schematic diagram illustrating the data structure of an exemplary file template. As shown in the diagram, a file creation request may contain a tuple of various pieces of information. These include the request type (i.e., "Request_Type"), the file template ID (i.e., "File_Template_ID"), the security template ID (i.e., "Security_Template_ID"), the flow template ID (i.e., "Flow_Template_ID"), the merge parameters (i.e., "Merge_Parameters"), the security parameters (i.e., "Security_Parameters"), and the flow parameters (i.e., "Flow_Parameters").

[0095] Figure 9 is a flowchart illustrating the process of generating a file. To begin, as shown by block 902 in Figure 9, the dispatch subsystem 204 receives a file creation request from a third-party system.

[0096] After the dispatch subsystem 204 receives the file creation request, the generation subsystem 212 retrieves a copy of the template identified by the file creation request (or associated data tuple) from the template database 218, as shown by block 903 in Figure 9.

[0097] After the generation subsystem 212 obtains a copy of the identified template, the render engine 213 modifies the template copy by replacing the dynamic elements of the template with data from matching merge parameter tuples, as shown in block 904 of Figure 9. Specifically, the render engine 213 replaces the remaining dynamic elements of the obtained file template with matching merge parameter tuples included in the received file creation request.

[0098] If a matching merge parameter tuple has the first template identifier as its data source, the generation subsystem 212 returns to block 902 to recursively generate the identified nested subtemplate, as shown in block 905 of Figure 9.

[0099] Otherwise, as shown by block 906 in Figure 9, the render engine 213 returns to step 904 if there are any remaining unreplaced dynamic elements. Otherwise, the method proceeds to block 907.

[0100] After all dynamic elements have been replaced, as shown in block 907 of Figure 9, the flow director subsystem 215 sends a modified copy of the identified template and saves it as the requested file to either the storage subsystem 108 or the third-party data destination 221.

[0101] Figure 10 is a flowchart illustrating an example method for saving the generated files.

[0102] To begin, as shown by block 1002 in Figure 10, the storage system 108 receives the files generated for storage from the flow director subsystem 215. The storage system 108 also receives information indicating one or more retention parameters for the received files.

[0103] After the storage system 108 receives the generated file, the storage engine 216 stores the received, generated file on the file storage 217, along with metadata indicating the associated retention parameters, as shown by block 1003 in Figure 10.

[0104] After the storage engine 216 has saved it (the received file) onto the file storage 217, the storage engine 216 may periodically scan the retention parameters of the saved, generated files (including the file that was just saved) and determine whether those retention parameters indicate that a delete trigger event has occurred, as shown by block 1004 in Figure 10.

[0105] If the retention parameter of the saved file indicates that a delete trigger event has occurred, the method proceeds to block 1007, as shown by block 1005 in Figure 10.

[0106] Otherwise, if there are remaining saved files that the storage engine 216 has queued for scanning, as shown by block 1006 in Figure 10, the method returns to block 1004 for the next remaining saved files to be scanned. Otherwise, the method terminates.

[0107] If the retention parameters of a saved file indicate that a delete trigger event has occurred, the storage engine 216 deletes the saved file from the file storage 217, as shown in block 1007. A delete trigger event can occur for any number of parameters, including multiple parameters such as the number of times the file has been viewed and the duration for which the file has been viewed. These may be set as parameters or variables and may form algorithmic means of deletion and retention, such as if-then (conditional branching) or other rule-based deterministic systems. In one embodiment, the delete / retain parameters may be linked to the device's biometric authentication engine (FaceID; fingerprint). In another embodiment, the delete / retain parameters may be associated with an IP address or the location accessed. In such embodiments, deletion may be enabled if the parameters are set so that a sensitive file is not opened outside a given area. This thus makes it possible to counter the actions of foreign agents, and even states, by placing security within file retention.

[0108] Figure 11 is a flowchart illustrating an exemplary method for controlling access to saved files.

[0109] To begin, as shown by block 1102 in Figure 11, the orchestrator subsystem 105 receives a request from the third-party portal to authenticate the third-party portal with respect to the first user account of the file management system 102.

[0110] After the orchestrator subsystem 105 receives the authentication request, as shown by block 1103 in Figure 11, the orchestrator subsystem 105 processes the request and, in response to verifying the provided credentials, authenticates the third-party portal with respect to the first user account.

[0111] After the orchestrator subsystem 105 authenticates the third-party portal, the orchestrator subsystem 105 generates one or more URIs associated with one or more generated files, as shown by block 1104 in Figure 11.

[0112] After the orchestrator subsystem 105 generates one or more URIs, as shown by block 1105 in Figure 11, the orchestrator subsystem 105 sends the generated URIs, along with information identifying the generated files associated with the URIs, to an authenticated third-party portal.

[0113] After the orchestrator subsystem 105 sends the URI and associated identification information to the third-party portal, the orchestrator subsystem 105 receives a request for the resource identified by one of the URIs, as shown by block 1106 in Figure 11.

[0114] After the orchestrator subsystem 105 receives a request for a resource, it provides the first resource in response to the request, as shown in block 1107 of Figure 11.

[0115] Figure 12 is a block diagram of a computing device. As shown in the figure, the computing device 1202 may include a processing system 1203, a memory system 1206, a storage system 1209, a network adapter 1212, an input / output (IO) interface 1213, and a bus interface 1214. Similarly, the processing system 1203 may include one or more processing units (indicated here as processing units 1204 and 1205). Similarly, the memory system 1206 may include one or more RAM modules (indicated here as RAM modules 1207 and 1208). Similarly, the storage system 1209 may include one or more storage drives (indicated here as storage drives 1210 and 1211).

[0116] Broadly speaking, the I / O interface 1213 can be connected to various peripheral devices (indicated here as the display 1216 and the input device 1217). Similarly, the network adapter 1212 can be connected to one or more external networks (indicated here as network 1215).

[0117] Figure 13 is a block diagram of one embodiment of the file creation subsystem. As shown in the figure, the file creation subsystem may include a document generation queue 1302, a document generation worker 1303, a template database 1304, a conversion queue 1305, a file conversion worker 1306, a render DB 1307, a temporary file storage 1308, a file composition queue 1309, and a file composition worker 1310.

[0118] Figure 14 is a flowchart illustrating an exemplary method for managing access to the generated files.

[0119] Figure 15 is a sequence diagram of one embodiment of the orchestrator subsystem.

[0120] In some embodiments, non-temporary computer-readable storage media containing instructions are also provided. Instructions may be executed by the device to perform the methods described above. Common forms of non-temporary media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media having a pattern of holes, RAM, PROMs, and EPROMs, FLASH-EPROMs, or any other flash memory, NVRAMs, caches, registers, any other memory chips or cartridges, and networked versions thereof. The device may include one or more processors (CPUs), input / output interfaces, network interfaces, and / or memory.

[0121] The devices, modules, and other functional units described in this disclosure may be implemented in hardware, software, or a combination of hardware and software. In some embodiments, functions described as being implemented in hardware may instead be implemented in software, or a combination of hardware and software. Similarly, in some embodiments, functions described as being implemented in software may instead be implemented in hardware, or a combination of hardware and software. If something is implemented in software, it may be stored in a non-temporary computer-readable medium, such as the computer-readable medium described above. When executed by a processor, such software may perform the functions of the device, module, or other functional unit that the software implements. The devices, modules, and other functional units described above may also be combined or further divided into multiple subunits.

[0122] In several places, references are made to standards that include standard methods for performing certain tasks. These standards are revised from time to time, and unless otherwise explicitly stated, references to standards in this disclosure refer to the most recently published standards at the time of filing.

[0123] Spatially relative terms such as "under," "below," "lower," "over," and "upper" may be used herein for ease of explanation to describe the relationship between one element or feature and another element or feature when the apparatus is upright.

[0124] When a feature is described as being "on" another feature, that feature may be directly on the other feature in the absence of an intervening feature, or indirectly on the other feature in the presence of an intervening feature. In contrast, when a feature is described as being "directly on" another feature, that feature is directly on the other feature in the absence of an intervening feature. When a feature is described as being "connected," "attached," or "coupled" to another feature, it will be understood that that feature may be directly connected, attached, or coupled to the other feature in the absence of an intervening feature, or indirectly connected, attached, or coupled to the other feature in the presence of an intervening feature. In contrast, when a feature is described as being "directly connected," "directly attached," or "directly coupled" to another feature, that feature may be directly connected, directly attached, or directly coupled to the other feature in the absence of an intervening feature.

[0125] The terms “about” and “approximately” generally refer to an acceptable degree of error or variation in a measured quantity, taking into account the nature or precision of the measurement. Typically, an exemplary degree of error or variation is within 20%, preferably 10%, more preferably 5%, and even more preferably 1% of a given value or range of values. Numerical quantities given in this description are approximations unless otherwise stated, meaning they can be inferred when the terms “about” or “approximately” are not explicitly stated.

[0126] Ordinal numbers or terms such as “first” and “second” are used solely to distinguish one entity or action from another, and do not imply or require any actual relationship or order between these entities or actions. Thus, a first feature or element may be referred to as a second feature or element, and similarly, a second feature or element may be referred to as a first feature or element without departing from the teachings of this disclosure. Furthermore, the words “comprising,” “having,” “containing,” and “including,” as well as other similar forms, are semantically equivalent and are intended to be open-ended, so as not to mean that the items or groups of items following any one of these words are an exhaustive list of such items or groups, or are limited to only the listed items or groups of items.

[0127] As used herein, unless otherwise specifically stated, the terms “or” and “at least one of” encompass all possible combinations, unless impractical. For example, if it is stated that a component may include “A or B,” then unless otherwise specifically stated or impractical, the component may include “A,” “B,” or “A and B.” As a second example, if it is stated that a component includes “at least one of A, B, or C,” then unless otherwise specifically stated or impractical, the component may include “A,” “B,” “C,” “A and B,” “A and C,” “B and C,” or “A, B, and C.” This same interpretation applies to longer lists (e.g., “may include A, B, C, or D”).

[0128] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0129] Any given element or step of the embodiments disclosed above may be embodied in one element or step, or in multiple elements or steps. Furthermore, any given element or step of the embodiments disclosed above may be combined to be embodied in one element or step, or in multiple elements or steps.

[0130] The order of steps shown in various figures is for illustrative purposes only and does not necessarily indicate that embodiments of the present disclosure are limited to a particular order of steps. Therefore, the steps performed by various embodiments of the present disclosure may be performed in different orders, while implementing the same method.

[0131] In the aforementioned specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Specific adaptations and modifications of the described embodiments may be made. Other embodiments may be apparent to those skilled in the art from considering the specification and practice of the invention disclosed herein. The specification and examples are intended to be considered merely illustrative, and the true scope and spirit of the invention are set forth by the following claims. The order of steps shown in the figures is for illustrative purposes only and is not intended to limit the steps to any particular order. Therefore, those skilled in the art will understand that these steps can be performed in different orders while implementing the same method.

[0132] Item 1: A method for managing access to generated files, The server performs the process of saving files in non-volatile memory, The server receives a request from the first client device to generate a uniform resource identifier (URI) (the URI is associated with the file, identity, and dynamic expiration date), The process involves generating a uniform resource identifier (URI) associated with the file on the server (the URI links to a resource containing the file and is generated on the server), The server performs the following steps in response to a request from the first client device: sending the URI to the second client device; The server receives a request from the second client device using the URI for requesting the resource, The process includes verifying through the server that the identity is an authorized identity (the server checks that the identity is included in the authorized identity database within the server), The process involves verifying the identity through an identity provider (the identity provider requests the user to log in to the identity on the identity hosting platform), The steps include granting or denying access to the resource based on the responses from the server and the identity provider, A method that includes [a certain feature].

[0133] Item 2: The method described in Item 1, wherein the identity may include an email address, login, username, or telephone number.

[0134] Item 3: A step of verifying the dynamic expiration date associated with the URI (the dynamic expiration date associated with the URI may consist of a first time period after the creation of the URI, or a second time period after the first use of the URI), A step of granting or denying access to the resource based on verification of the dynamic expiration date associated with the URI, The method described in item 1, further comprising:

[0135] Item 4: Further comprising the step of providing the resource to the second client device in response to granting access to the resource, The method according to item 1, wherein the step of providing the resource to the second client device comprises the step of providing the file to the second client device.

[0136] Section 5: The method described above is The server has the process of receiving a file creation request, In response to receiving the aforementioned file creation request, the process involves generating the file from a file template (the file is generated on the server), The method described in item 1, further comprising:

[0137] Section 6: The method described above is The server includes the step of receiving a file template creation request, In response to receiving the aforementioned file template creation request, the process includes generating the file template with static content data and dynamic content markers (the file template is generated on the server), The method described in paragraph 5, further comprising:

[0138] Item 7: The file template comprises static content data and one or more dynamic content markers, The aforementioned file template is a nested file template, The step of generating the file from the file template includes the step of creating a copy of the file template with the static content data and one or more dynamic content markers (each of the one or more dynamic content markers in the file template is associated with its respective merge parameter identifier), A step of inserting merge parameter data into one or more dynamic content markers of the copy of the file template using one or more sets of merge parameter data structures (each set of one or more merge parameter data structures comprises a respective merge parameter identifier and a respective merge parameter data source, and the merge parameter data is obtained from one or more respective merge parameter data sources), The method according to item 5, comprising:

[0139] Item 8: A file management system, The server is equipped with a server, and the server is Save the file in non-volatile memory, The first client device receives a request to generate a uniform resource identifier (URI) associated with the file, identity, and dynamic expiration date. A uniform resource identifier (URI) associated with the aforementioned file is generated, The aforementioned URI links to the resource containing the aforementioned file, In the request from the first client device, the URI is sent to the second client device. The second client device receives a request using the URI for requesting the resource, Verify that the aforementioned identity is an authorized identity, The server checks that the identity is included in the authorized identity database on the server. The identity is verified through an identity provider, The identity provider requests login to the identity on the identity hosting platform, Based on the responses from the server and the identity provider, access to the resource is permitted or denied. A system that is configured in such a way.

[0140] Item 9: The system described in Item 8, wherein the identity may include an email address, login, username, or telephone number.

[0141] Item 10: The server is, Verify the dynamic expiration date associated with the URI (the dynamic expiration date associated with the URI may consist of a first time period after the creation of the URI, or a second time period after the URI was first used), and, Based on the verification of the dynamic expiration date associated with the URI, access to the resource is permitted or denied. The system described in paragraph 8 is further configured as follows.

[0142] Item 11: The server is further configured to provide the resource to the second client device in response to granting access to the resource, The system according to item 8, wherein the step of providing the resources to the second client device comprises the step of providing the file to the second client device.

[0143] Item 12: The server is, A file creation request has been received, and, The system according to paragraph 8, further configured to generate the file from a file template in response to receiving the aforementioned file creation request.

[0144] Item 13: The server is, A file template creation request has been received, and In response to receiving the aforementioned file template creation request, the system generates the file template with static content data and dynamic content markers. The system described in paragraph 12 is further configured as follows.

[0145] Section 14: The file template comprises static content data and one or more dynamic content markers, The aforementioned file template is a nested file template, The process of generating the file from the aforementioned file template is as follows: A step of creating a copy of the file template with the static content data and the dynamic content markers (the one or more dynamic content markers of the file template are associated with their respective merge parameter identifiers), A step of inserting merge parameter data into one or more dynamic content markers of the copy of the file template using one or more sets of merge parameter data structures (each set of one or more merge parameter data structures comprises a respective merge parameter identifier and a respective merge parameter data source, and the merge parameter data is obtained from one or more respective merge parameter data sources), The system according to item 12, comprising:

[0146] Item 15: A non-temporary computer-readable medium comprising instructions, wherein, when the instructions are executed by one or more processors, the instructions are directed to the one or more processors. The server performs the process of saving files in non-volatile memory, The server receives a request from the first client device to generate a uniform resource identifier (URI) (the URI is associated with the file, identity, and dynamic expiration date), The process involves generating a uniform resource identifier (URI) associated with the file on the server (the URI links to a resource containing the file and is generated on the server), The server performs the following steps in response to a request from the first client device: sending the URI to the second client device; The server receives a request from the second client device using the URI for requesting the resource, The process of verifying through the server that the identity is an authorized identity (the server checks that the identity is included in the authorized identity database within the server), The process involves verifying the identity through an identity provider (the identity provider requests login to the identity on the identity hosting platform), The steps include granting or denying access to the resource based on the responses from the server and the identity provider, A non-temporary, computer-readable medium that controls access to the generated file by performing this action.

[0147] Section 16: The identity may comprise an email address, login, username, or telephone number in a non-temporary computer-readable medium as described in Section 15.

[0148] Section 17: The instruction is to one or more processors, A step of verifying the dynamic expiration date associated with the URI (the dynamic expiration date associated with the URI may consist of a first time period after the creation of the URI, or a second time period after the URI was first used), The steps include granting or denying access to the resource based on verifying the dynamic expiration date associated with the URI, A non-temporary computer-readable medium as described in paragraph 15, which controls access to the generated file by performing the following actions.

[0149] Section 18: The instruction causes the at least one processor to control access to the file generated by the process of providing the resource to the second client device in response to granting access to the resource. The non-temporary computer-readable medium according to paragraph 15, wherein the step of providing the resource to the second client device comprises the step of providing the file to the second client device.

[0150] Item 19: The instruction further provides to one or more processors: The server has the process of receiving a file creation request, In response to receiving the aforementioned file creation request, the process involves generating the file from a file template (the file is generated on the server), A non-temporary computer-readable medium as described in Section 15, which controls access to files generated by [the specified entity].

[0151] Item 20: The file template comprises static content data and one or more dynamic content markers, The aforementioned file template is a nested file template, The process of generating the file from the aforementioned file template is as follows: A step of creating a copy of the file template with the static content data and the dynamic content markers (the one or more dynamic content markers of the file template are associated with their respective merge parameter identifiers), A step of inserting merge parameter data into one or more dynamic content markers of the copy of the file template using one or more sets of merge parameter data structures (each set of one or more merge parameter data structures comprises a respective merge parameter identifier and a respective merge parameter data source, and the merge parameter data is obtained from one or more respective merge parameter data sources), A non-temporary computer-readable medium as described in paragraph 19, comprising:

Claims

1. A method for managing access to generated files, The preservation process, The process involves receiving a request to generate a uniform resource identifier (URI), The process of generating a uniform resource identifier (URI), The transmission process, The process of receiving a request using a URI, The process of verifying identity through a server, The process of verifying the identity through an identity provider, The process includes granting or denying access to a resource, In the aforementioned saving process, the server saves the file in non-volatile memory. In the step of receiving a request to generate the Uniform Resource Identifier (URI), the server receives a request from the first client device to generate a Uniform Resource Identifier (URI) associated with the file, identity, and dynamic expiration date. In the process of generating the uniform resource identifier (URI), the server generates a uniform resource identifier (URI) associated with the file, The URI is linked to a resource containing the file and is generated on the server. In the transmission step, the server transmits the URI to the second client device in the request from the first client device. In the step of receiving a request using the URI, the server receives a request from the second client device using the URI to request the resource, In the process of verifying identity through the server, the server verifies that the identity is an authorized identity. The server checks that the identity is included in the authorized identity database within the server. The identity provider requests the user to log in to the identity on the identity hosting platform. A method for granting or denying access to the resource, wherein access to the resource is granted or denied based on responses from the server and the identity provider.

2. The method according to claim 1, The aforementioned identity may include an email address, login, username, or phone number.

3. The method according to claim 1, A step of verifying the dynamic expiration date associated with the URI, The process further comprises granting or denying access to the resource based on verifying the dynamic expiration date associated with the URI, A method wherein the dynamic expiration time associated with the URI may comprise a first time length after the creation of the URI, or a second time length after the first use of the URI.

4. The method according to claim 1, The process further includes providing the resource to the second client device in response to granting access to the resource, A method comprising the step of providing the resource to the second client device, wherein the step of providing the file to the second client device.

5. The method according to claim 1, The aforementioned method, The server has the process of receiving a file creation request, The process further comprises: in response to receiving the aforementioned file creation request, generating the file from a file template, The aforementioned file is generated on the aforementioned server by the method described above.

6. The method according to claim 5, The aforementioned method, The server includes the step of receiving a file template creation request, The process further comprises: generating the file template with static content data and dynamic content markers in response to receiving the aforementioned file template creation request, The method by which the aforementioned file template is generated on the server.

7. The method according to claim 5, The aforementioned file template comprises static content data and one or more dynamic content markers. The aforementioned file template is a nested file template, The process of generating the file from the aforementioned file template is as follows: The process of creating a copy, The process includes an insertion step, In the process of creating the copy, a copy of the file template is created with the static content data and one or more dynamic content markers. Each of the one or more dynamic content markers in the aforementioned file template is associated with its respective merge parameter identifier. In the insertion step, a set of one or more merge parameter data structures is used to insert the merge parameter data into one or more dynamic content markers of the copy of the file template. Each of the sets of one or more merge parameter data structures comprises a merge parameter identifier and a merge parameter data source, A method for obtaining the merge parameter data from one or more merge parameter data sources.

8. A file management system, The server is equipped with a server, and the server is Save the file in non-volatile memory, The first client device receives a request to generate a Uniform Resource Identifier (URI) associated with the file, identity, and dynamic expiration date. A uniform resource identifier (URI) associated with the aforementioned file is generated, The URI links to the resource containing the file, In the request from the first client device, the URI is sent to the second client device. The second client device receives a request using the URI to request the resource, The server verifies that the aforementioned identity is an authorized identity. The server checks that the identity is included in the database of authorized identities on the server, The identity is verified through an identity provider, The identity provider requests login to the identity on the identity hosting platform, Based on the responses from the server and the identity provider, access to the resource is permitted or denied. A system that is configured in such a way.

9. The system according to claim 8, The aforementioned identity may include an email address, login information, a username, or a phone number, within a system.

10. The system according to claim 8, The aforementioned server, Verify the dynamic expiration date associated with the aforementioned URI, The dynamic expiration time associated with the URI may comprise a first time length after the creation of the URI, or a second time length after the first use of the URI. Based on the verification of the dynamic expiration date associated with the URI, access to the resource is permitted or denied. The system is further configured in this way.

11. The system according to claim 8, The server is further configured to provide the resource to the second client device in response to granting access to the resource, and The system comprises the step of providing the resources to the second client device, and the step of providing the files to the second client device.

12. The system according to claim 8, The aforementioned server, A file creation request has been received, and, In response to receiving the aforementioned file creation request, the system generates the file from the file template. The system is further configured in this way.

13. The system according to claim 12, The aforementioned server, A file template creation request has been received, and In response to receiving the aforementioned file template creation request, the system generates the file template with static content data and dynamic content markers. The system is further configured in this way.

14. The system according to claim 12, The aforementioned file template comprises static content data and one or more dynamic content markers. The aforementioned file template is a nested file template, The process of generating the file from the aforementioned file template is as follows: The process comprises a step of creating a copy and a step of inserting it. In the process of creating the copy, a copy of the file template is created with the static content data and the dynamic content marker. Each of the one or more dynamic content markers in the aforementioned file template is associated with its respective merge parameter identifier. In the insertion step, a set of one or more merge parameter data structures is used to insert the merge parameter data into one or more dynamic content markers of the copy of the file template. Each of the sets of one or more merge parameter data structures comprises a merge parameter identifier and a merge parameter data source, The merge parameter data is obtained from one or more merge parameter data sources in the system.

15. A non-temporary computer-readable medium having instructions, wherein when the instructions are executed by one or more processors, the one or more processors The preservation process, The process of receiving a request, The process of generating a uniform resource identifier (URI), The process of sending to the second client device, The process of receiving a request, The process involves verifying through the server that the aforementioned identity is an authorized identity, The process of verifying the identity through an identity provider, By performing the process of allowing or denying access, access to the generated file is controlled. In the aforementioned saving process, the server saves the file in non-volatile memory. In the step of receiving the aforementioned request, the server receives a request from the first client device to generate a uniform resource identifier (URI) associated with the file, identity, and dynamic expiration date. In the process of generating the uniform resource identifier (URI), the server generates a uniform resource identifier (URI) associated with the file, The URI is linked to a resource containing the file and is generated on the server. In the step of sending to the second client device, the server sends the URI to the second client device in the request from the first client device. In the step of receiving the request, the server receives a request from the second client device using the URI to request the resource, The server checks that the identity is included in the authorized identity database within the server. The identity provider requests login to the identity on the identity hosting platform, In the step of granting or denying access, access to the resource is granted or denied based on the response from the server and the identity provider. A non-temporary computer-readable medium.

16. A non-temporary computer-readable medium according to claim 15, The aforementioned identity may be a non-temporary, computer-readable medium comprising an email address, login information, username, or telephone number.

17. A non-temporary computer-readable medium according to claim 15, wherein the instruction is transmitted to one or more processors. A step of verifying the dynamic expiration date associated with the URI, The process involves allowing or denying access to the resource based on verifying the dynamic expiration date associated with the URI, thereby controlling access to the generated file. The dynamic expiration time associated with the URI may comprise a first time length after the creation of the URI, or a second time length after the first use of the URI. A non-temporary computer-readable medium.

18. A non-temporary computer-readable medium according to claim 15, The instruction causes at least one processor to perform the step of providing the resource to the second client device in response to permission to access the resource, thereby controlling access to the generated file. The step of providing the resource to the second client device comprises the step of providing the file to the second client device, and is a non-temporary computer-readable medium.

19. A non-temporary computer-readable medium according to claim 15, The instruction is given to one or more processors, The server has the process of receiving a file creation request, In response to receiving the aforementioned file creation request, the process involves generating the file from a file template, and thereby controlling access to the generated file. The aforementioned file is a non-temporary, computer-readable medium generated on the aforementioned server.

20. A non-temporary computer-readable medium according to claim 19, The aforementioned file template comprises static content data and one or more dynamic content markers. The aforementioned file template is a nested file template, The process of generating the file from the aforementioned file template is as follows: The process comprises a step of creating a copy and a step of inserting it. In the process of creating the copy, a copy of the file template is created with the static content data and the dynamic content marker. Each of the one or more dynamic content markers in the aforementioned file template is associated with its respective merge parameter identifier. In the insertion step, a set of one or more merge parameter data structures is used to insert the merge parameter data into one or more dynamic content markers of the copy of the file template. Each of the sets of one or more merge parameter data structures comprises a merge parameter identifier and a merge parameter data source, The merge parameter data is obtained from one or more merge parameter data sources in a non-temporary, computer-readable medium.

Images