Method and system for generating and automatically deleting files based on parameterized conditions

Abstract

This disclosure relates, in general, to methods, systems, devices, and non-temporary computer-readable media for managing generated files. These systems can be used to significantly automate the generation, storage, and eventual deletion of files across a wide range of businesses. Specifically, embodiments of this disclosure may include a step in which a server creates a file from a file template in response to a request from a client device. This request or the provided file template may indicate when the file should be deleted. After the file is generated, the server may store the first file and subsequently monitor for the occurrence of an associated delete trigger event. If the server detects the occurrence of a delete trigger event, the server may then delete the stored file. Thus, files are retained for an appropriate period and deleted when it is no longer appropriate to retain them.

Description

Technical Field

[0001] The present disclosure generally relates to data management, and more specifically, to methods, systems, devices, and non - transient computer - readable media for managing generated files.

Background Art

[0002] In today's digital - dominated era, organizations heavily rely on the systematic creation, communication, and retention of countless files to support business effectiveness and regulatory compliance. These files range from official documents to informal communications, serve evidentiary purposes, fulfill legal and regulatory mandates, and are retained for a specific period to facilitate information and business continuity.

[0003] However, there are challenges in file retention. While it is important for specific files to be retained for a defined period, retaining files indefinitely is neither practical nor beneficial. Retaining files permanently exacerbates issues related to data storage management, inflates costs, and complicates the data acquisition process. Moreover, it hinders the rapid and efficient acquisition of up - to - date and relevant files, reducing the agility and responsiveness of the organization. The pervasiveness of data and the increasing volume of files generated daily exacerbate this problem, rendering manual deletion strategies obsolete and impractical.

[0004] Considering the diverse nature of files and their distinct retention requirements, a granular approach to file retention is essential. Different file categories require different retention timelines defined by regulations, laws, and business necessities. The absence of a systematic and automated approach to file management and deletion increases the risk of human error, inefficiency, and non - compliance, thereby compromising the efficiency and integrity of the organization.

[0005] Traditional file retention management methods, which heavily rely on human intervention, have proven inadequate, making processes inefficient and prone to errors. The numerous file types, each with different retention timelines, exacerbate the complexity of this issue, highlighting the need for a granular, automated approach to file retention and deletion. Furthermore, modern file storage systems either lack automated file deletion capabilities or, in many cases, require cumbersome human intervention for configuration on a per-file basis.

[0006] Therefore, there is a long-sought need to develop a system that can significantly reduce the burden incurred during the process of generating and managing files. The disclosures and embodiments herein set out to address this long-sought need. [Brief explanation of the drawing]

[0007] 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.

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

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

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

[0011] [Figure 4]FIG. 4 is a flowchart of an exemplary method for managing deletion of generated files.

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

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

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

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

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

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

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

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

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

[0022] [Figure 15] Figure 15 is a sequence diagram of one aspect of the orchestrator subsystem.

Best Mode for Carrying Out the Invention

[0023] Next, a detailed description will be given of the 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 consistent with the present invention. Instead, these are merely examples of apparatuses and methods consistent with aspects related to the present invention described in the appended claims. Specific aspects of the present disclosure are better described 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.

[0024] This 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 significantly automate file generation and storage. By utilizing nested file templates, as described below, the systems of this disclosure facilitate the generation of file templates. Furthermore, by using file retention and storage systems, as described below, the systems of this disclosure can simplify the process of ensuring that files are retained for an appropriate period and that they are deleted when they no longer need to be retained. Thus, the systems and methods herein can assist in compliance with various regulations and help protect sensitive information by destroying or securely erasing / removing files after a deletion trigger event.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] In a first embodiment, a method for generating a file using nested templates is disclosed. In one embodiment 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 corresponding 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 comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, and the merge parameter data is obtained from one or more corresponding merge parameter data sources.

[0029] 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 a 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 to 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.

[0030] 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 to 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.

[0031] 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.

[0032] 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 expiration date. 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 a 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.

[0033] 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 verify through the server that the identity 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 verify 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.

[0034] 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.

[0035] 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 corresponding merge parameter identifiers, respectively.

[0036] 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 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.

[0037] 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.

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

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

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

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

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

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

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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 corresponding merge parameter identifiers, respectively.

[0056] 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.

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

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

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

[0060] 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.

[0061] 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.

[0062] 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.

[0063] In an additional embodiment of the seventh embodiment, the third-party portal may authenticate with respect to the first user account associated with the first user. To begin, a request to authenticate the third-party portal with respect to the first user may be received from the third-party portal. Generally, the authentication request includes credentials derived from the 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.

[0064] 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.

[0065] 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.

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

[0067] 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 corresponding 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 include corresponding merge parameter identifiers and corresponding merge parameter data sources. Furthermore, the merge parameter data may be obtained from one or more corresponding merge parameter data sources.

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

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] Figure 3 is a flowchart illustrating 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.

[0077] 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.

[0078] 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.

[0079] Figure 4 is a flowchart illustrating 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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).

[0095] 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").

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

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

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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 (Face ID; fingerprint) and may be activated during a biometric scan. In one embodiment, a failed biometric scan returns a delete trigger event within the system. 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 cannot be 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.

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

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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).

[0117] 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).

[0118] 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.

[0119] Figures 14A and 14B are flowcharts illustrating an exemplary method for managing access to the generated files.

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

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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”).

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

[0130] 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.

[0131] 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.

[0132] In the above 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 a particular order. Therefore, those skilled in the art will understand that these steps can be performed in different orders while implementing the same method.

[0133] Item 1: A computer implementation method for managing generated files, The first server receives a request to create a first file template from a client device, The first server, in response to receiving the first file template creation request, generates a first file template comprising static content data and dynamic content markers; The first server includes the step of receiving a first file creation request from the client device, The first server, in response to receiving the first file creation request, performs the steps of generating the first file from the first file template, The first server saves the first file in non-volatile memory accessible by the first server, The first server performs the steps of detecting a deletion trigger event, The steps include: deleting the first file from the non-volatile memory in response to the detection of the deletion trigger event; A method that includes [a certain feature].

[0134] Item 2: The method according to Item 1, wherein the deletion trigger event may comprise one or more combinations of parameters.

[0135] Sub-sub

[0136] Item 4: The method according to Item 1, wherein the deletion trigger event is the elapsed time of one hour from the date associated with the creation of the first file.

[0137] Item 5: The method according to Item 1, wherein the deletion trigger event is that the number of times the first file has been accessed exceeds the first access limit threshold.

[0138] Section 6: The first file template comprises static content data and one or more dynamic content markers, The process of generating the first file from the first file template is as follows: A step of creating a copy of the first file template comprising the static content data and the one or more dynamic content markers (each of the one or more dynamic content markers in the first file template is associated with a corresponding merge parameter identifier), The process includes inserting merge parameter data into one or more dynamic content markers of the copy of the first file template using one or more sets of merge parameter data structures, Each of the one or more sets of merge parameter data structures comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, The method according to item 1, wherein the merge parameter data is obtained from one or more corresponding merge parameter data sources.

[0139] Item 7: After saving the first file in the non-volatile memory, the first server receives a request to access the first file; The system further comprises the step of authenticating the request to access the first file using the first server, The method described in item 1, wherein the first server's failure to authenticate the request to access the first file is a delete trigger event.

[0140] Item 8: A file storage system, The system includes a first server, and the first server is: Upon receiving a request to create the first file template from the client device, In response to receiving the first file template creation request, a first file template comprising static content data and one or more dynamic content markers is generated. Upon receiving a first file creation request from the aforementioned client device, In response to receiving the first file creation request, the first file is generated from the first file template, The first server saves the first file in non-volatile memory accessible by the first server, Detect the delete trigger event, and also, In response to the detection of the deletion trigger event, delete the first file from the non-volatile memory. A system that is configured in such a way.

[0141] Section 9: The delete trigger event may comprise one or more combinations of parameters, as described in Section 8.

[0142] Item 10: The system according to Item 9, wherein one or more parameters include at least one of (i) time since the first file was generated, (ii) user view, (iii) IP address or browsing address, (iv) time spent browsing the first file, or (v) expiration date, or (vi) response to a biometric scan.

[0143] Item 11: The deletion trigger event is the elapsed time from the date associated with the creation of the first file, as described in Item 8.

[0144] Item 12: The deletion trigger event is the number of times the first file has been accessed exceeds the first access limit threshold, as described in Item 8 of the system.

[0145] Section 13: The first file template comprises static content data and one or more dynamic content markers, The system is configured to perform the step of generating a first file from the first file template, and the step of generating a first file from the first file template is: A step of creating a copy of the first file template comprising the static content data and the one or more dynamic content markers (each of the one or more dynamic content markers in the first file template is associated with a corresponding merge parameter identifier), The process includes inserting merge parameter data into one or more dynamic content markers of the copy of the first file template using one or more sets of merge parameter data structures, Each of the one or more sets of merge parameter data structures comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, The system according to paragraph 8, wherein the merge parameter data is obtained from one or more corresponding merge parameter data sources.

[0146] Item 14: The aforementioned first server is, After saving the first file in the non-volatile memory, a request to access the first file is received. Authenticate the request to access the first file. It is further structured in the following way: The authentication failure of the request to access the first file is a delete trigger event, as described in Section 8 of the system.

[0147] Item 15: A non-temporary computer-readable medium, when executed by one or more processors, the one or more processors, The first server receives a request to create a first file template from a client device, The first server, in response to receiving the first file template creation request, generates a first file template comprising static content data and dynamic content markers; The first server includes the step of receiving a first file creation request from the client device, The first server, in response to receiving the first file creation request, performs the steps of generating the first file from the first file template, The first server saves the first file in non-volatile memory accessible by the first server, The first server performs the steps of detecting a deletion trigger event, The steps include: deleting the first file from the non-volatile memory in response to the detection of the deletion trigger event; A non-temporary computer-readable medium that includes commands to manage the saving and deletion of generated files by performing the following actions.

[0148] Section 16: A deletion trigger event may comprise one or more combinations of parameters in a non-transient computer-readable medium as described in Section 15.

[0149] Item 17: The non-temporary computer-readable medium described in Item 16, wherein the combination of one or more parameters comprises at least one of (i) the time since the first file was generated, (ii) a user view, (iii) an IP address or browsing address, (iv) the time spent browsing the first file, or (v) an expiration date, or (vi) a response to a biometric scan.

[0150] Item 18: The deletion trigger event is the elapsed time of one hour from the date associated with the creation of the first file, as described in Item 15 for non-transient computer-readable media.

[0151] Item 19: A deletion trigger event is the number of times the first file has been accessed exceeds the first access limit threshold, for non-transient computer-readable media as described in Item 15.

[0152] Section 20: The first file template comprises static content data and one or more dynamic content markers, The system is configured to perform the step of generating a first file from the first file template, and the step of generating a first file from the first file template is: A step of creating a copy of the first file template comprising the static content data and the one or more dynamic content markers (each of the one or more dynamic content markers in the first file template is associated with a corresponding merge parameter identifier), The process includes inserting merge parameter data into one or more dynamic content markers of the copy of the first file template using one or more sets of merge parameter data structures, Each of the one or more sets of merge parameter data structures comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, The merge parameter data is obtained from one or more corresponding merge parameter data sources in a non-temporary computer-readable medium as described in paragraph 15.

Claims

1. A computer implementation method for managing generated files, The process of receiving a request to create the first file template, The first step is to generate a file template, The process of receiving the first file creation request, The process of generating the first file, The preservation process, The detection process, The process includes a deletion step, In the step of receiving the first file template creation request, the first server receives the first file template creation request from the client device, In the process of generating the first file template, the first server generates a first file template comprising static content data and dynamic content markers in response to receiving the first file template creation request. In the step of receiving the first file creation request, the first server receives the first file creation request from the client device, In the process of generating the first file, the first server generates the first file from the first file template in response to receiving the first file creation request. In the saving step, the first file is saved in a non-volatile memory accessible by the first server. In the detection step described above, the first server detects the deletion trigger event, The deletion step involves deleting the first file from the non-volatile memory in response to the detection of the deletion trigger event.

2. The method according to claim 1, The method wherein the deletion trigger event may comprise one or more combinations of parameters.

3. The method according to claim 2, A method in which the one or more parameters include at least one of (i) time since the first file was generated, (ii) user view, (iii) IP address or browsing address, (iv) time spent browsing the first file, (v) expiration date, or (vi) response to a biometric scan.

4. The method according to claim 1, The deletion trigger event is the elapsed time of one hour from the date associated with the creation of the first file, in this method.

5. The method according to claim 1, The deletion trigger event is that the number of times the first file has been accessed exceeds a first access limit threshold.

6. The method according to claim 1, The first file template comprises static content data and one or more dynamic content markers, The process of generating the first file from the first 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 first file template comprising the static content data and one or more dynamic content markers is created. Each of the one or more dynamic content markers in the first file template is associated with a corresponding merge parameter identifier, In the insertion step, a set of one or more merge parameter data structures is used to insert merge parameter data into one or more dynamic content markers of the copy of the first file template. Each of the one or more sets of merge parameter data structures comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, A method for obtaining the merge parameter data from one or more corresponding merge parameter data sources.

7. The method according to claim 1, The first step is to save the first file in the non-volatile memory, and then the first server receives a request to access the first file, The system further comprises the step of authenticating the request to access the first file using the first server, A method in which the authentication failure of the request to access the first file by the first server is a delete trigger event.

8. A file storage system, The system includes a first server, and the first server is: Upon receiving a request to create the first file template from the client device, In response to receiving the first file template creation request, a first file template comprising static content data and one or more dynamic content markers is generated. Upon receiving a first file creation request from the aforementioned client device, In response to receiving the first file creation request, the first file is generated from the first file template, The first server saves the first file in non-volatile memory accessible by the first server, Detect the delete trigger event, In response to the detection of the deletion trigger event, the first file is deleted from the non-volatile memory. A system that is configured in such a way.

9. The system according to claim 8, The deletion trigger event may comprise one or more combinations of parameters in the system.

10. The system according to claim 9, A system in which one or more parameters include at least one of the following: (i) time since the first file was generated, (ii) user view, (iii) IP address or browsing address, (iv) time spent browsing the first file, (v) expiration date, or (vi) response to a biometric scan.

11. The system according to claim 8, The deletion trigger event is the elapsed time of one hour from the date associated with the creation of the first file, according to the system.

12. The system according to claim 8, The deletion trigger event is when the number of times the first file has been accessed exceeds the first access limit threshold in the system.

13. The system according to claim 8, The first file template comprises static content data and one or more dynamic content markers, The system is configured to perform the step of generating a first file from the first file template, and the step of generating a first file from the first file template is: The process of creating a copy, The process includes an insertion step, In the process of creating the copy, a copy of the first file template comprising the static content data and one or more dynamic content markers is created. Each of the one or more dynamic content markers in the first file template is associated with a corresponding merge parameter identifier, In the insertion step, a set of one or more merge parameter data structures is used to insert merge parameter data into one or more dynamic content markers of the copy of the first file template. Each of the one or more sets of merge parameter data structures comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, The merge parameter data is obtained from one or more corresponding merge parameter data sources in the system.

14. The system according to claim 8, The first server is, After saving the first file in the non-volatile memory, a request to access the first file is received, and Authenticate the request to access the first file. It is further structured in the following way: The system determines that the authentication failure of the request to access the first file is a delete trigger event.

15. A non-temporary computer-readable medium, When executed by one or more processors, the one or more processors: The first server receives a request to create a first file template from a client device, The first server, in response to receiving the first file template creation request, generates a first file template comprising static content data and dynamic content markers; The first server includes the step of receiving a first file creation request from the client device, The first server, in response to receiving the first file creation request, includes the step of generating the first file from the first file template, The first server saves the first file in a non-volatile memory accessible by the first server, The first server performs the steps of detecting a deletion trigger event, The steps include: deleting the first file from the non-volatile memory in response to the detection of the deletion trigger event; A non-temporary computer-readable medium equipped with commands to manage the saving and deletion of generated files by performing the following actions.

16. A non-temporary computer-readable medium according to claim 15, The deletion trigger event may comprise a non-transient, computer-readable medium comprising one or more combinations of parameters.

17. A non-temporary computer-readable medium according to claim 16, A non-temporary computer-readable medium comprising at least one of the following combinations of one or more parameters: (i) time since the first file was generated, (ii) user view, (iii) IP address or browsing address, (iv) time spent viewing the first file, (v) expiration date, or (vi) response to a biometric scan.

18. A non-temporary computer-readable medium according to claim 15, The deletion trigger event is a non-transient, computer-readable medium, where the first time interval is elapsed from the date associated with the creation of the first file.

19. A non-temporary computer-readable medium according to claim 15, A deletion trigger event is a non-transient computer-readable medium in which the number of times the first file has been accessed exceeds a first access limit threshold.

20. A non-temporary computer-readable medium according to claim 15, The first file template comprises static content data and one or more dynamic content markers, The system is configured to perform the step of generating a first file from the first file template, and the step of generating a first file from the first file template is: The process of creating a copy, The process includes an insertion step, In the process of creating the copy, a copy of the first file template comprising the static content data and one or more dynamic content markers is created. Each of the one or more dynamic content markers in the first file template is associated with a corresponding merge parameter identifier. In the insertion step, a set of one or more merge parameter data structures is used to insert merge parameter data into one or more dynamic content markers of the copy of the first file template. Each of the one or more sets of merge parameter data structures comprises a corresponding merge parameter identifier and a corresponding merge parameter data source, The merge parameter data is obtained from one or more corresponding merge parameter data sources in a non-temporary, computer-readable medium.

Images