Server and method for processing emails
A processing server and client terminal system addresses collaborative email management challenges by storing emails centrally, reducing duplication and ensuring secure, efficient access and resource conservation.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- DEVMEDIA
- Filing Date
- 2025-11-25
- Publication Date
- 2026-06-25
Smart Images
Figure EP2025084112_25062026_PF_FP_ABST
Abstract
Description
[0001] Description
[0002] Title of the invention: Email server and processing method
[0003] Domain
[0004] The invention relates to the field of email management and more particularly concerns devices and methods for processing emails.
[0005] Previous technique
[0006] Email plays a central role in communication between individuals, particularly professionals, making it an essential tool for business communication and in many other environments. With the widespread adoption of email, managing email within an organization presents a significant challenge. Companies face an increasing number of emails to process and a continuous rise in the volume of attachments exchanged, which poses certain technical difficulties.
[0007] Traditional email systems, such as Microsoft's Exchange-Outlook® integration, no longer meet current requirements. These conventional systems rely on a model where emails are first received by a central server (Exchange) before being distributed to users' client devices. On each client device, the emails are then stored locally in specific databases, for example, as OST files (Outlook Storage Tables or Outlook Offline Data Files) for Outlook®. This architecture has inherent limitations, particularly regarding collaboration, storage resource management, and long-term data retention.
[0008] One of the limitations of these systems lies in their very design, intended for individual rather than collaborative use. While some solutions, such as shared inboxes, allow multiple users to work together to some extent, these approaches remain poorly suited to collaborative environments where transparency and coordinated actions are crucial. For example, if a user in a workgroup accesses an email in a shared inbox and marks it as read, this status becomes visible to all other users, which can lead to confusion. Similarly, when a user files or replies to an email, these actions are not necessarily reflected or visible to other team members.This leads to an increased risk of information loss or problems with duplication and confusion in processing efforts, issues that become critical in projects requiring strong collaboration.
[0009] Furthermore, storing emails locally on client devices consumes significant resources. Each device connected to an inbox downloads and stores a complete copy of the emails, resulting in massive data duplication. This duplication is particularly problematic in a context where email volumes continue to grow exponentially, largely due to the proliferation of large attachments such as videos, high-resolution images, and other multimedia content. This leads to an overload of local storage space and increased network traffic, especially between servers and devices. This overload, combined with limited network infrastructure in some environments, can result in slowdowns, increased operating costs, and a degraded user experience.
[0010] Another major problem, stemming particularly from the local storage architecture of conventional systems, is the high risk of data loss. Emails stored locally on a client device become vulnerable if the device malfunctions, is stolen, or is removed from the IT environment, such as in a corporate local area network. In such circumstances, emails stored only on that device risk being irretrievably lost. For businesses and other organizations, these losses can have serious consequences, especially in sectors where the security and long-term preservation of emails is paramount. For example, in the insurance or legal disputes sectors, it can be crucial to retrieve an email that is decades old.However, with current solutions, this often becomes impossible if the terminals or software that initially handled these emails are no longer available.
[0011] Furthermore, rapid technological evolution poses additional challenges to data preservation. Locally stored emails can become inaccessible when the tools or formats used to store them become obsolete. For example, a user who used now-defunct email software or a specific proprietary format might find themselves unable to retrieve their emails, once again exposing users to significant risks of data loss.
[0012] Given the limitations of traditional messaging systems, it is necessary to rethink how emails are handled. Current solutions, while having enabled significant progress in the efficiency of electronic communications, no longer meet the growing demands of modern environments, particularly in the workplace, whether in terms of collaboration, resource management, or data security and ease of access.
[0013] Description of the invention
[0014] One of the objects of the present invention is to solve at least one of the problems or deficiencies of the technological background described above.
[0015] Another object of the present invention is to enable efficient processing of emails ensuring reliable storage and easy access to data, while limiting the resources required.
[0016] Another object of the present invention is to ensure email management adapted in particular to collaborative work.
[0017] According to a first aspect, the invention relates to a first method for processing emails implemented by a processing server cooperating with a plurality of client terminals belonging to a local network, said local network comprising a local file server controlling a file system, the method comprising:
[0018] - receiving, from outside the local network, an email containing header data and email body data;
[0019] - generation, from the email, of files comprising a header file and an email body file corresponding respectively to the header data and the email body data;
[0020] - determination, from the header data, of an identifier for an associated project box;
[0021] - determination, for each generated file, of a network location associated with the project box according to location data;
[0022] - selection of a client terminal as the agent terminal; and
[0023] - sending, to the agent terminal, the generated files and save commands specifying the respective network locations of the generated files, said save commands causing the agent terminal to save each generated file in the local file server's file system at the respective network location of the associated project box.
[0024] The first method of the invention may include other features which may be taken separately or in combination, particularly among the following embodiments which are presented by way of illustration only and may be combined or associated unless otherwise stipulated. According to a particular embodiment, the email header file and body file are in text format.
[0025] According to a particular embodiment, the received email includes at least one attachment, the files generated from said email including an attachment file, in native format, for each attachment of the email.
[0026] According to a particular embodiment, the process further comprises:
[0027] - receipt, from the agent terminal, of a confirmation message indicating that the saving of each generated file has been carried out in accordance with the saving commands; and
[0028] - in response to said confirmation message, update index data specifying that each generated file is stored at its respective network location in the file system.
[0029] According to a particular embodiment, the process further comprises:
[0030] - recording, in association with index data, of each generated file.
[0031] According to a particular embodiment, the process further comprises:
[0032] - sending, to each client terminal, descriptive data specifying that said email is stored in the file system at the network locations of the generated files.
[0033] According to a particular embodiment, the selection of a client terminal as an agent terminal includes:
[0034] - obtaining performance data representative of the performance of client terminals that have operated in the past as agent terminals; and
[0035] - selection, as agent terminal, of the client terminal meeting at least one performance criterion according to the performance data.
[0036] According to a particular embodiment, for each client terminal selected as an agent to record an email in the file system, the process comprises:
[0037] - sending, to the client terminal operating as an agent, registration commands requesting the registration of all or part of an email in the local server's file system;
[0038] - measurement of the execution time elapsed between sending said registration commands and receiving a confirmation message specifying that said registration commands have been executed; the performance data of said client terminal being a function of the execution time. According to a particular embodiment, the processing server selects, as an agent, from among the client terminals, the one exhibiting the highest execution speed according to the performance data.
[0039] According to a particular embodiment, a single client terminal is selected as the agent terminal.
[0040] According to a particular embodiment, the process further comprises:
[0041] - determination, from the received email, of a number N of client terminals required to process said email, N being an integer at least equal to 2; in which N client terminals are selected as agent terminals.
[0042] According to a particular embodiment, a plurality of received emails are processed according to said method, said method further comprising:
[0043] - generation of a summary file specifying each email received for said project mailbox and the network locations of the files generated for said received email; and
[0044] - sending the summary file to the local file server, via a client terminal acting as an agent terminal, for recording in the file system, said summary file allowing consultation in text format of each email associated with the project mailbox.
[0045] According to a second aspect, the invention relates to a second method for processing emails, implemented by a processing system comprising a processing server and a plurality of client terminals belonging to a local network, said local network comprising a local server controlling a file system, the method comprising:
[0046] - reception, by the processing server, from outside the local network, of an email containing header data and email body data;
[0047] - generation, by the processing server, from the email, of files comprising a header file and an email body file corresponding respectively to the header data and the email body data;
[0048] - determination, by the processing server, from the header data, of an identifier for an associated project box;
[0049] - determination, by the processing server, for each generated file, of a network location associated with the project box according to location data;
[0050] - selection, by the processing server, of a client terminal as an agent terminal; and
[0051] - sending, by the processing server to the agent terminal, the generated files and save commands specifying the respective network locations of the generated files; and
[0052] - in response to the save commands, the terminal agent saves each generated file in the local file server's file system to the respective network location of the associated project box.
[0053] The second method of the invention may include other features which may be taken separately or in combination, in particular among the following embodiments which are presented by way of illustration only and may be combined or associated unless otherwise stipulated.
[0054] According to a particular embodiment, the second method further comprises:
[0055] - sending, by the agent terminal to the processing server, a confirmation message indicating that the saving of each generated file has been carried out in accordance with the saving commands; and
[0056] - in response to said confirmation message, the processing server updates index data specifying that each generated file is stored at its respective network location in the file system.
[0057] According to a particular embodiment, the second method further comprises:
[0058] - sending, by the processing server, to each client terminal, descriptive data indicating that said email is stored in the file system at the network locations of the generated files;
[0059] - receipt, by a second client terminal among the client terminals, of a user instruction to access said email;
[0060] - in response to said user instruction, determination, by the second terminal, from the description data, of the respective network locations of the files generated for said email; and
[0061] - retrieval, by the second terminal, from the local file server, of the files stored in the file system at the respective network locations of the associated project box.
[0062] According to a particular embodiment, recovery includes:
[0063] - sending, by the second client terminal to the local file server, a request to access the files stored in the respective network locations of the file system;
[0064] - receipt, in response to said access request, by the second terminal, of a data stream representative of said stored files; and
[0065] - Retrieval, by the second client terminal, from the data stream, of said stored files by means of a user interface. According to a third aspect, the different stages of the first processing method and / or the second processing method are defined by computer program instructions.
[0066] Consequently, the third aspect of the invention also relates to one or more computer programs on one or more information storage media (or recording media), this program or these programs being capable of being implemented in at least one device, for example a server and / or a terminal or more generally by at least one computer. This program or these programs include instructions adapted to the implementation of the steps of the first processing method and / or the second processing method as defined above and described below in exemplary embodiments.
[0067] In particular, the third aspect of the invention may include such a computer program capable of being implemented by an email processing server, this program comprising instructions adapted to the implementation of the steps of the first processing method according to the first aspect of the invention.
[0068] In particular, the third aspect of the invention may include such a computer program capable of being implemented by a terminal (or client terminal), this program having instructions adapted to the implementation of the steps of the second processing method according to the second aspect of the invention.
[0069] Each processing method of the invention can, for example, be implemented by means of a non-volatile memory storing computer program instructions and by means of a processor executing these instructions.
[0070] Each of the aforementioned computer programs can use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.
[0071] According to a fourth aspect, the invention relates to one or more information carriers (or recording media) readable by at least one device, such as a server and / or a terminal or more generally at least one computer, and comprising instructions for one of the computer programs (or both) as mentioned above and described below in particular examples.
[0072] This fourth aspect may include a first information carrier, readable by an email server, containing instructions to execute the steps of the first processing method according to the first aspect of the invention. This fourth aspect may include a second information carrier, readable by a terminal (or client terminal), containing instructions to execute the steps of the second processing method according to the second aspect of the invention.
[0073] Each information carrier mentioned in this disclosure can be any entity or device capable of storing the computer program as required for the case at hand. For example, the carrier can include a storage medium, such as rewritable non-volatile memory (flash memory, SSD, or other) or ROM (read-only memory), for example, a CD-ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example, a hard drive.
[0074] Furthermore, each information carrier can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. Each program according to the invention can, in particular, be downloaded onto an Internet-type network.
[0075] Alternatively, each information carrier can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.
[0076] According to a fifth aspect, the invention relates to an email processing server (also called a processing server) configured to implement the first processing method according to the first aspect of the invention. The fifth aspect relates, for example, to a processing server capable of cooperating with a plurality of client terminals belonging to a local network, said local network comprising a local file server controlling a file system, said processing server comprising:
[0077] - a receiving module configured to receive, from outside the local network, an email including header data and email body data;
[0078] - a generation module is configured to generate, from the email, files comprising a header file and an email body file corresponding respectively to the header data and the email body data;
[0079] - a first determination module configured to determine, from the header data, an identifier of an associated project box;
[0080] - a second determination module configured to determine, for each generated file, a network location associated with the project box according to location data;
[0081] - a selection module configured to select a client terminal as the agent terminal; and
[0082] - a sending module configured to send, to the agent terminal, the generated files and save commands specifying the respective network locations of the generated files, said save commands causing the agent terminal to save each generated file in the local file server's file system at the respective network location of the associated project box.
[0083] For each step of the first processing method, the processing server of the fifth aspect of the invention may include a corresponding module configured to carry out said step.
[0084] According to a sixth aspect, the invention relates to a processing system configured to implement the second processing method according to the second aspect of the invention.
[0085] The sixth aspect concerns, for example, a processing system comprising:
[0086] - the processing server according to the fifth aspect of the invention; and
[0087] - a plurality of client terminals belonging to a local network, said local network comprising a local server controlling a file system, in which each client terminal is configured, when selected as an agent terminal by the processing server, to cause the saving, in the file system at respective network locations of a project mailbox, of files associated with an email in accordance with save commands sent by said processing server, each save command specifying the respective network location of a file of said email.
[0088] For each step of the second processing method, the processing system of the sixth aspect of the invention may include a corresponding module configured to carry out said step.
[0089] Note that the various embodiments mentioned above (as well as those described below) in relation to the first and second processing methods of the invention and the associated advantages apply analogously to the processing server and the processing system according to the first and second aspects of the invention respectively.
[0090] In particular embodiments, the invention is implemented using software and / or hardware components. In this context, the term "module" may refer in this document to a software component, a hardware component, or a set (or combination) of hardware and software components.
[0091] A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or set of functions, as described below for the module in question. Such a software component can be executed by a data processor of a physical entity (terminal, server, etc.) and is capable of accessing the hardware resources of that physical entity (memory, storage media, communication buses, input / output cards, user interfaces, etc.).
[0092] Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions, as described below for the module in question. This could be a programmable hardware component or one with an integrated processor for software execution, for example, an integrated circuit, an electronic board, etc.
[0093] Brief description of the drawings
[0094] Other features and advantages of the present invention will become apparent from the description of the specific and non-limiting embodiments of the present invention below, with reference to the attached Figures 1 to 7, in which:
[0095] [Fig. 1] Figure 1 schematically represents an environment comprising a processing server and client terminals, according to particular embodiments of the invention;
[0096] [Fig. 2] Figure 2 schematically represents a processing server according to particular embodiments of the invention;
[0097] [Fig. 3] Figure 3 schematically represents a client terminal according to particular embodiments of the invention;
[0098] [Fig. 4] Figure 4 schematically represents, in the form of a diagram, the steps of the treatment processes implemented in the environment of Figure 1, according to particular embodiments of the invention;
[0099] [Fig. 5] Figure 5 schematically represents certain aspects of the treatment processes implemented in the environment of Figure 1, according to particular embodiments of the invention;
[0100] [Fig. 6] Figure 6 schematically represents certain aspects of the treatment processes implemented in the environment of Figure 1, according to particular embodiments of the invention; and [Fig. 7] Figure 7 schematically represents, in the form of a diagram, the steps of the treatment processes implemented in the environment of Figure 1, according to particular embodiments of the invention.
[0101] Description of implementation methods
[0102] Examples of implementations of the invention will now be described in what follows with joint reference to Figures 1-7. Unless otherwise indicated, common or similar elements in several figures bear the same reference symbols and have identical or similar characteristics, so that these common elements are generally not described again for the sake of simplicity.
[0103] The terms "first(s)", "second(s)", etc.) are used in this document by arbitrary convention to allow identification and distinction of different elements (such as features, steps, etc.) implemented in the embodiments described below.
[0104] The invention proposes to improve email processing, particularly to address the problems and limitations mentioned earlier. To achieve this, the invention implements a processing server that cooperates with a plurality of client terminals on a local network to enable efficient email processing, especially for emails received by the processing server. This processing relies on a local file server, also on the local network, capable of storing emails transmitted via the client terminals in a file system. Each file corresponding to an email can thus be stored in a structured, accessible, and secure manner in its respective network location, associated with a file system element called a "project mailbox," as described in more detail below with specific examples.
[0105] The invention relates in particular, according to embodiments, to a method for processing emails, implemented by a processing server cooperating with a plurality of client terminals belonging to a local network, said local network comprising a local file server controlling a file system, the method comprising:
[0106] - receiving, from outside the local network, an email containing header data and email body data;
[0107] - generation, from the email, of files comprising a header file and an email body file corresponding respectively to the header data and the email body data;
[0108] - determination, from the header data, of an identifier for an associated project box;
[0109] - determination, for each generated file, of a network location associated with the project box according to location data;
[0110] - selection of a client terminal as the agent terminal; and
[0111] - sending, to the agent terminal, the generated files and save commands specifying the respective network locations of the generated files, said save commands causing the agent terminal to save each generated file in the local file server's file system at the respective network location of the associated project box.
[0112] The invention also relates to a client terminal capable of acting as an agent terminal in cooperation with a processing server as described above, as well as a processing system comprising such a processing server and such user terminals.
[0113] Other aspects and advantages of the present invention will become apparent from the embodiments described below with reference to the drawings mentioned above.
[0114] Figure 1 schematically represents an environment 1 comprising an email processing server SV1, also called the processing server, and a plurality of client terminals CL, namely 5 client terminals labeled CL1 to CL6 in this example. The processing server SV1 is capable of cooperating (or communicating) with the client terminals CL, which belong to a local NT2 network.
[0115] The nature and configuration of the NT2 local network can vary depending on the case. It could be, for example, a local network of a company or any other organization, for example an organization involving multiple users who communicate with each other by exchanging emails.
[0116] The NT2 local network also includes a local SV2 file server, separate from the SV1 processing server. The CL client terminals are each capable of cooperating with the local SV2 file server within the NT2 local network, as described in more detail later.
[0117] In the examples considered, the processing server SV1 is located outside the NT2 local network, namely in a network labeled NT1. From outside the NT2 local network, the processing server SV1 is able to communicate with each of the client terminals CL1-CL5.
[0118] The communication methods used between the SV1 processing server and the CL client terminals, and between the CL client terminals and the SV2 local file server, can be adapted as needed. For example, the NT1 network can correspond to all or part of the Internet, and the NT2 local network can be a local network connected to the Internet. The SV1 processing server is capable of receiving and processing emails (or electronic mail, or emails) originating from outside the NT2 local network. As shown in Figure 1 for illustrative purposes only, the SV1 processing server can thus receive and process emails, for example, an MG1 email sent by an SVO mail server belonging to the NT1 network.This SVO server is configured, for example, to send emails to the SV1 processing server using an appropriate email protocol, for example, the POP3 protocol (for "Post Office Protocol version 3") or IMAP (for "Internet Message Access Protocol").
[0119] As described below, an MG1 email received from the SVO server by the SV1 processing server comprises header data, denoted MG1a, and email body data, MG1b. The MG1a header data defines various pieces of information associated with the email, such as the email creation date, the sender's user ID, the recipient's user ID (or account, or project ID), and so on. The nature and format of the data contained in the MG1a header data may vary. The MG1b email body data defines the body of the email, that is, the message intended to be sent (or delivered) via that email.
[0120] Note that each MG1 email received by the SV1 processing server may include, in addition to the MG1a header data and the MG1b email body data, MG1c attachments corresponding to at least one attached file. An email may therefore contain one or more attached files, the number, nature, and format of which may vary. However, an MG1 email may not contain any attachments.
[0121] The SV1 processing server is configured to process each incoming email in cooperation with the CL client terminals on the NT2 local network. Specifically, the SV1 processing server is configured to generate FL files from a received MG1 email. These FL files comprise an FL1a header file and an FL1b email body file, corresponding respectively to the MG1a header and MG1b email body data. In the case of an attachment, the SV1 processing server can also generate, obtain, or retrieve a corresponding FL1c file for each email attachment. Furthermore, the SV1 processing server can cooperate with at least one CL client terminal, acting as an AG1 agent terminal, to cause the FL files to be saved to specific EM1 network locations on a file system managed by the SV3 local file server.
[0122] To this end, the processing server SV1 may include at least one processor 10 (Figure 2) and at least one non-volatile memory (not shown), the processor 10 being configured to implement instructions defined in a first computer program PG1 stored in said memory of the processing server SV1. This non-volatile memory (for example, rewritable memory or ROM) constitutes a first storage medium (or information medium) according to one embodiment of the invention. This program PG1 includes instructions for executing the steps of a first processing method, as described below in exemplary embodiments.
[0123] Processor 10 of the SV1 processing server is configured to execute the instructions of the first computer program PG1 in order to carry out steps of the first processing procedure. To this end, processor 10 of the SV1 processing server may include onboard memory, an input / output interface, and various circuits known to those skilled in the art. In particular, this processor 10 may use volatile memory (not shown) to perform the various operations and functions necessary for the operation of the SV1 processing server, including executing the PG1 computer program during the implementation of the first processing procedure.
[0124] As illustrated in Figure 1, the SV1 processing server is capable of using predefined DT1 data, called location data, stored for example in a DB1 memory (or database) accessible by the SV1 server in the NT1 network.
[0125] The SV1 processing server is also capable of using DT2 data, known as index data, stored, for example, in a DB2 memory (or database) accessible by the SV1 server on the NT1 network. DT1 and DT2 data may form a single data group or separate groups, as appropriate. The nature and functions of DT1 and DT2 data are described in more detail later in specific examples.
[0126] Each client terminal CL is a terminal suitable for use by an end user to access or process a given email, such as email MG1, in cooperation with the processing server SV1 and the local file server SV2. To this end, each client terminal CL may include at least one processor 14 (Figure 3) and at least one non-volatile memory (not shown), the processor 14 being configured to execute instructions defined in a second computer program PG2 stored in said memory of the client terminal CL. This non-volatile memory (for example, rewritable memory or ROM) constitutes a second storage medium (or information medium) according to one embodiment of the invention. This program PG2 includes instructions for executing a portion of the steps of a second processing method, as described below in exemplary embodiments.
[0127] The processor 14 of each CL client terminal is configured to execute the instructions of the second computer program PG2 in order to perform a portion of the steps in the second processing method. To this end, the processor 14 of each CL terminal may include onboard memory, an input / output interface, and various circuits familiar to those skilled in the art. In particular, this processor 14 may use volatile memory (not shown) to perform the various operations and functions necessary for the operation of the CL terminal, including executing the PG2 computer program during the implementation of the second processing method.
[0128] Each CL client terminal can be, for example, a computer, a tablet, a smart phone (called "smartphone"), or any other suitable IT equipment.
[0129] Each CL client terminal may also include a user interface (not shown) allowing a user to interact with said terminal, in particular to view or process a given email such as the MG1a email in the examples that follow.
[0130] This user interface can, for example, display an email accessed by a user of the given CL terminal. The user interface may, for instance, include or utilize a screen or any other display device within the given CL terminal.
[0131] The processing server SV1 and the client terminals CL together form a system SY1, called the processing system, capable of processing an email MG1 according to the second processing method described above. The computer programs PG1 and PG2 jointly define instructions for carrying out the steps of the second processing method when these programs PG1 and PG2 are executed respectively by the processing server SV1 and at least one given client terminal CL.
[0132] The local file server SV2 is a server capable of storing data in a structured and centralized manner and making it accessible across the NT2 local network. Specifically, this local server SV2 controls or manages a file system, denoted 20 (Figure 1), in which files, particularly FL files generated by the processing server SV1, can be stored centrally for later use. The file system 20 may include folders, for example, in a folder and subfolder structure (e.g., a tree architecture), in which the FL files are stored. To accomplish this, the local server SV2 uses at least one local memory location 22 in which the file system 20 is stored.
[0133] As shown in Figure 1, we will assume that each email processed by the SV1 processing server and stored by the local SV2 file server is associated with a network location in filesystem 20, which we will call a "project mailbox" BP (or simply, "project"). A project mailbox BP, such as the project mailbox BP1 considered later, can correspond, for example, to a given end user, a workgroup, a topic, or a project about which users interact.
[0134] As described in more detail later, a specific network location is assigned (or associated) to each BP project box. In particular, the DT1 location data accessible by the SV1 processing server can specify, for each BP project box, an associated network location in file system 20. Thus, from this predefined DT1 data, the SV1 processing server can determine a network location assigned to a given BP project box in file system 20.
[0135] For each email associated with a given BP project mailbox, the FL files generated by the SV1 processing server are saved in file system 20, at the network location associated with that BP project mailbox. The local SV2 file server can thus store, at a respective network location within a given BP project mailbox, each FL file generated from an email associated with that BP project mailbox. Each FL file is therefore stored in a network sub-location within the network location of the corresponding BP project mailbox. The local SV2 file server operates under the control of a CL client terminal, acting as AG1, to save the received FL files to the appropriate network locations.As described later in specific examples, the way in which the client terminal(s) selected as agent terminals to enable the recording of each email in the file system 20 may vary depending on the case.
[0136] As described later in specific examples, the DT2 index data controlled by the SV1 processing system defines the respective network locations, within file system 20, of each FL file stored in association with a given BP project box. The SV1 processing server is configured, for example, to update the DT2 index data so that it reflects the FL files stored for a given BP project box, as well as the respective network locations of those files within file system 20.
[0137] As shown in Figures 1-2 by way of a particular example, the processor 10 of the processing server SV1, driven by the computer program PG1, implements a number of modules, namely: a receive module MD2, a generate module MD4, a first determination module MD6, a second determination module MD8, a select module MD10 and a send module MD12.
[0138] The MD2 receiving module can be configured to receive, from outside the NT2 local network, an MG1 email containing MG1a header data and MG1b email body data. The MD4 generating module can be configured to generate, from the MG1 email, FL files containing an FL1a header file and an FL1b email body file corresponding to the MG1a header data and the MG1b email body data, respectively. As described later, the MG1 email may also include at least one FL1c attachment, which is processed by subsequent modules of the SV1 server in a manner similar to the FL1a and FL1b files.
[0139] The first MD6 determination module can be configured to determine, from the MG1a header data, an ID1 identifier of an associated BP1 project box.
[0140] The second MD8 determination module can be configured to determine, for each generated FL file, a network location (namely location EM 1a for FL1a and location EM 1b for FL1b) associated with the BP1 project box according to DT 1 location data.
[0141] The MD10 selection module can be configured to select a CL client terminal as an AG1 agent terminal.
[0142] The MD12 send module can be configured to send, to the AG1 agent terminal, the generated FL files and save commands (e.g. C1a and C1b) specifying the respective network locations (e.g. EM 1a and EM 1b respectively) of the generated FL files, these save commands causing the AG1 agent terminal to save each generated FL file in the local SV2 file server's file system 20 at the respective network location (EM 1a and EM 1b respectively) of the associated project box BP1.
[0143] In the case where an attached file FL1 c is processed jointly with the files FL1 a and FL1 b, this file FL1c is sent to the terminal AG1 with a save command C1 c specifying a respective network location EM 1c, this save command causing the agent terminal AG1 to save the attached file FL1c in the file system 20, at the respective network location EM 1c of the associated project box BP1.
[0144] As shown in Figures 1 and 3 by way of a particular example, the processor 14 of a CL client terminal, driven by the computer program PG2, implements at least one MD20 registration module, or even, where appropriate, at least one of an MD22 confirmation module, an MD24 reception module and an MD26 processing module.
[0145] The MD22 registration module can be configured, when said CL client terminal is selected as AG1 agent terminal by the SV1 processing server, to cause (or command) the registration, in file system 20 at respective network locations EM 1a and EM 1 b (or also EM 1c) of a BP1 project box, of FL files (namely FL1a and FL1 b, or also FL1c) associated with an MG1 email in accordance with registration commands C1 a and C1 b (or also 01 c) sent by the SV1 processing server, each registration command specifying the respective network location EM 1a and EM 1b (or also EM 1c) of an FL file of said email.
[0146] The MD22 confirmation module can optionally be configured to send a confirmation notification to the SV1 processing server, to confirm that the registration commands sent by the SV1 processing server have been executed.
[0147] The MD24 receiving module can optionally be configured to receive DT3 description data provided by the SV1 processing server, this DT3 description data defining each FL file stored in file system 20 for a given BP project box as well as the respective network location where each of these FL files is stored in file system 20.
[0148] The MD26 processing module can optionally be configured to process a user instruction INS1 received by the client terminal to access an email stored in the file system 20.
[0149] For the purposes of this example, we assume that each CL client terminal has the same configuration for processing emails in accordance with this disclosure. Each CL client terminal can operate either as an agent terminal if selected by the SV1 processing server to cause FL file records in filesystem 20, or as a standard (non-agent) client terminal if an INS1 user instruction is received to access or process a given email.
[0150] The configuration and operation of the MD2-MD12 modules of the SV1 processing server and the MD20-MD26 modules of each CL client terminal will be shown in more detail in the embodiment examples described below. It should be understood that the MD2-MD12 and MD20-MD26 modules as shown in Figures 2 and 3 are only non-limiting examples of implementation of the invention.
[0151] As illustrated in Figures 4-6 with implementation examples, the steps of a first processing method implemented by the SV1 processing server are now described, and more generally, the steps of a second processing method implemented by the SY1 processing system, comprising the SV1 server and the CL client terminals, as described previously with reference to Figures 1-3. In this process, the SV1 processing server executes the instructions of the PG1 computer program, while each of the CL client terminals executes the instructions of its PG2 computer program. It should be noted, however, that variants are possible where only one (or some) of the CL client terminals is able to be selected and act as the agent terminal.
[0152] During a reception step A2 (Figures 4-5), the processing server SV1 receives an initial email MG1a from the mail server SVO. This email contains MG1a header data and M1b email body data. For the sake of example, we will assume that this MG1a email also includes FL1c attachments corresponding to an attached file. Note, however, that the number of attachments can vary, as there are also possible implementations where no attachment is included in the email. Each attachment, for example, is encapsulated in a single file, such as an .eml file, which defines the MG1 email (this .eml file being comparable to a .zip archive).
[0153] During a generation step A4 (Figure 4), the processing server SV1 generates (or determines, or obtains), from the received email MG1, FL files comprising, in particular, a header file FL1a and an email body file FL1b corresponding respectively to the header data MG1a and the email body data MG1b. The server SV1 thus generates the header file FL1a from the header data MG1a and generates the email body file FL1b from the email body data MG1a.
[0154] The MG 1a header data can define various information associated with the MG1a email, such as, for example, the date the email was sent, an ID of the sending user, an ID of the recipient user (or account, or project), etc.
[0155] For example, the header file FL1a and the email body file FL1b are in text format, which greatly facilitates the subsequent retrieval of data from email MG1. The FL1a and FL1b files are, for instance, in .html or .txt format. In another example, the header file FL1a is in .txt format while the body file FL1b is in .html format. This combination of formats allows for the complete reproduction of the email's content in a human-readable format, or one that is undocumented and accessible to any existing or future processing system, thus facilitating access to email content and preventing any data loss.
[0156] In the case considered here, where the received email MG1 includes MG1c data specifying an attachment, the FL1c attachment generated from this MG1c data can be in its native format, that is, the format natively specified by the MG1c data. Thus, the SV1 processing server does not change the format of the attachment, which advantageously limits the processing and resources required and facilitates the subsequent use of the FL1c attachment. More generally, the email MG1 can include at least one attachment, so that, among the FL files generated in A4 (Figure 4), the SV1 processing server generates or obtains an FL1c attachment file for each attachment in the email MG1.
[0157] For example, the MG1c email received by the SV1 server is in the form of a single file, such as an .eml file. Each attachment in the MG1c email can form part of this single file. Instead of converting this single file (including the attachment(s)) into another data type (for example, .OST or "webmail"), the SV1 processing server can be configured to keep the attachments in their native format (without format conversion). The SV1 server then commands the saving of each attachment in its native format to the file system. This advantageously limits the processing required by the SV1 processing server and facilitates subsequent retrieval and reading of the email, as no specialized software or specific processing is required to access the email's content.
[0158] During a determination step A6 (Figure 4), the SV1 processing server determines, from the MG1a header data, an ID1 identifier for an associated BP1 project box. In this example, it is assumed that the MG1a header data includes the ID1 identifier, which is extracted (or decoded) by the SV1 processing server. The nature and format of the ID1 identifier may vary.
[0159] For example, let's consider that the MG1a header data specifies a destination email address in the format [alias@domainname], this email address being associated with the BP1 project mailbox. The SV1 processing server is configured to process all incoming emails destined for the domain name corresponding to this MG1 email. By analyzing the MG1a header data, the SV1 server detects that the MG1 email is being sent to this email address [alias@domainname], which specifies "domainname" as the domain name and "alias" as the alias. The SV1 processing server then identifies the alias as the ID1 identifier.
[0160] During step A8 (Figure 4), the SV1 processing server determines, for each FL file generated in A4 (Figure 4), namely FL1a, FL1b, and FL1c in the example considered, a respective network location, namely EM1a, EM1b, and EM1c, associated with the same project box BP1 according to location data DT1. To do this, the location data DT1 defines, for example, for the ID1 corresponding to the project box BP1, a specific (dedicated) network location EM1 in file system 20 within the NT2 local network. Each BP project box can thus be associated with an identifier (for example an alias or an email address) and a network location in the file system 20. From the DT1 location data, the DT1 server can thus determine (or define) respective network locations (or sublocations) EM 1a, EM 1 b and EM 1c, for the files FL1a, FL1 b and FL1c, within the network location EM1 associated with the BP1 project box.A respective network location is thus assigned and dedicated to each FL file within the EM1 network location reserved for the BP1 project box, which advantageously allows the storage of the different elements of the email, in the form of files, within the file system 20, as described in more detail later.
[0161] During a selection step A10 (Figure 4), the processing server SV1 selects at least one CL client terminal as an agent terminal to enable the subsequent saving of FL files to filesystem 20. For example, it is assumed that the server SV1 selects a single CL client terminal, namely terminal CL2 (Figure 5), as agent terminal AG1. However, it should be noted that variations are possible in which multiple client terminals are selected (A10) as agent terminals to cooperate with the processing server during the subsequent saving phase.
[0162] The method by which the AG1 agent terminal is chosen can vary. For example, the SV1 processing server selects the agent terminal(s) from among the CL client terminals according to at least one predefined selection rule. As an example, the SV1 processing server selects, as the agent terminal, a CL client terminal that meets at least one predefined selection criterion (e.g., availability and / or performance criteria as described below).
[0163] As an example, the SV1 processing server detects, among the CL client terminals, the terminal(s) available to operate as an agent. The agent terminal is then selected from among the available client terminal(s). To do this, each CL client terminal can, for example, send a status notification to the SV1 processing server beforehand, indicating its current status. This status can optionally be sent periodically, either unsolicited or on an ad hoc basis in response to a status request from the SV1 processing server, by each CL client terminal. For example, each available CL client terminal can send a waiting status (indicating that it is available and ready to perform tasks potentially requested by the SV1 server, such as writing to the EM1 network location of file system 20) to the SV1 processing server.Depending on the status specified (waiting or unavailable) by each CL client terminal, the SV1 processing server detects the candidate terminal(s) available to act as an agent terminal and performs its A10 selection from among these candidate terminals. For example, the SV1 processing server selects a CL client terminal as the agent terminal based on the performance (or capabilities) of CL client terminals. As an example, the SV1 server can obtain (regularly or occasionally) performance data representative of the performance (or capabilities) of CL client terminals that have previously operated as agent terminals. The SV1 server then selects, as the agent terminal, the client terminal that meets at least one performance criterion based on the performance data obtained. This performance data can be determined or obtained in various ways, depending on the situation.Various performance criteria (speed of execution, success rate, etc.) can be taken into account depending on the use case.
[0164] The SV1 processing server can, for example, take into account the average execution speed of each CL client terminal, which acted as an agent terminal, to process the registration of an email. In one example, the SV1 server selects, as agent terminal AG1, the CL client terminal with the highest execution speed based on the performance data obtained.
[0165] Depending on the configuration, the SV1 server can select multiple CL client terminals as agent terminals. For example, the SV1 processing server analyzes the MG1 email and determines, based on the MG1 email (e.g., from the data volume MG1a, MG1b, and possibly MG1c of the email), the number N of CL client terminals required to process the MG1 email as agent terminals. The SV1 server can thus advantageously adjust the number of agent terminals according to the resources required to store the MG1 email in the file system 20, for example, based on the amount of data to be stored.
[0166] During a sending step A12 (Figures 4-5), the processing server SV1 sends the generated FL files and save commands specifying the respective network locations where the FL files should be saved to the agent terminal AG1 (namely, terminal CL2 in this example). More specifically, in this example, the server SV1 sends the files FL1a, FL1b, and FL1c along with save commands C1a, C1b, and C1c specifying the network locations EM1a, EM1b, and EM1c associated with these files, respectively. The method by which these elements are sent to the client terminal AG1 can be adapted as needed.The SV1 server can, for example, send the C1a-C1c commands as separate commands, or alternatively by combining at least two of these three commands (or even all of them) into a single command specifying (in the form of a plurality of instructions) the network locations to use for the corresponding FL files. The FL1a-FL1c files can, for example, be sent as a compressed file (e.g., of type .zip) containing the FL1a-FL1c files.
[0167] The agent terminal AG1, namely terminal CL2 in this example, receives the FL1a-FL1c files and the C1a-C1c commands during a B12 reception step (Figure 4). As described below, the C1a-C1c save commands are configured to cause agent terminal AG1 to save each FL file to the local file server SV2's filesystem 20 at the respective network location EM 1a-EM 1c of the associated BP1 project box. Note that, in this example, only client terminal CL2, acting as agent terminal AG1, receives the FL1a-FL1c files and the associated C1a-C1c save commands. Thus, the other client terminals, namely CL1 and CL3-CL5, are not notified of this saving at this stage.
[0168] Selecting and using a CL client terminal as an agent terminal advantageously limits the resources required, particularly in terms of data traffic, processing capacity, and memory space, to perform the recording of FL files in the file system 20. This agent terminal can be chosen based on its capabilities and / or its availability status (available or unavailable) to maximize the chances of successful recording and limit execution time, which advantageously makes the processing of MG1 email even more reliable and efficient.
[0169] In response to the C1a-C1c save commands, the AG1 agent terminal saves (B14) each FL file, namely FL1a, FL1b, and FL1c, to file system 20 at its respective network location, MG1a, MG1b, and MG1c, of the BP1 project box. To do this, the AG1 agent terminal instructs the SV2 local file server to store the FL1a, FL1b, and FL1c files at their respective locations EM1a, EM1b, and EM1c within the EM1 network location associated with the BP1 project box in file system 20. The SV2 local server performs the required storage during a C16 storage step (Figure 4).
[0170] As an example, a folder is created at network location MG1c to contain each attached file, FL1c in this example, associated with the email MG1. This folder and its contents (FL1) can be transferred (A12, Figure 4) by the processing server SV1. This transfer (A12) is performed, for example, only once to the local file server SV2 via the agent terminal AG1 for saving to file system 20. The folder and its contents can thus be stored only once across all local servers (of the type of server SV2) and all CL clients. Note that, to perform the B14 saving of the FL1a-FL1c files according to the C1a-C1c saving commands, the agent terminal AG1 can temporarily save the FL1a-FL1c files locally.Once these registrations are completed, the AG1 agent terminal can then delete the FL1a-FL1c files from its local memory, which advantageously frees up memory space and centralizes the storage of email FL files in the file system 20.
[0171] Since CL client terminals other than agent terminal AG1 do not receive FL1a-FL1c files at the registration stage, these non-agent CL terminals also do not store these files, which advantageously saves resources in terms of data traffic, processing capacity and memory space.
[0172] The present invention advantageously enables efficient email processing, ensuring reliable data storage and easy access, while minimizing resource requirements. This is made possible, in particular, because the various FL files generated for the MG1 email can be stored in a structured manner, as files, within the file system 20, and more specifically in their respective network locations within the general network location associated with the project mailbox BP1.
[0173] Furthermore, due to its discrete FL1 file nature, EM1 email can be effectively backed up using all standard file backup solutions. In simplified terms, copying the folders and their FL contents to another storage location is a viable backup method. This eliminates the need for a specialized email backup solution, simplifying backups and reducing resource requirements.
[0174] A user can then, using one of the CL client terminals, access the FL files in filesystem 20 corresponding to an email of their choice, for example, the MG1 email they wish to view or process. Specifically, a CL client terminal can subsequently retrieve (or download) the FL1a, FL1b, and FL1c files and then generate or view a copy of the MG1 email from these files.
[0175] By centralizing email storage, and more specifically the corresponding FL files, it is possible to significantly save resources, particularly in terms of data traffic, processing capacity, and memory space. Storing emails as files in predefined network locations within a file system offers the advantage of data security, facilitates access over time, and thus minimizes data loss. It is particularly easy for a user or administrator to retrieve an email, even if client devices have undergone changes over time (removal of some CL devices, modifications to the NT2 local network, etc.) or in the event of a failure, theft, or other change to the NT2 local network.Even if the CL client terminal that acted as an agent is no longer available, the email can still be retrieved from the file system 20, which helps to guarantee the long-term preservation of emails.
[0176] Centralizing email storage within a network location dedicated to a BP project mailbox also makes collaborative work more efficient and easier, since each CL client terminal can then access, and edit if necessary, the files of each email stored in association with a given BP project mailbox.
[0177] Using a client terminal acting as an agent terminal also advantageously limits the resources required, particularly in terms of data traffic, processing power, and memory space, to save each email's data to the file system. For example, it is not necessary to use a terminal on the NT2 local network other than one of the CL client terminals to perform these saves. The client terminals do not need to store each email received from the SV1 processing server locally.
[0178] FL files stored in the 20 file system can, for example, be in text format, which advantageously allows for easier access to and processing of emails, since suitable text reader software can be used to retrieve and read the retrieved email. Emails stored centrally in this way remain accessible because there is little to no risk of the FL file text formats becoming obsolete. No specific email software (which can be prone to obsolescence), particularly proprietary software, is then required to read or process these emails. The complexity and specificity of the necessary tools are kept to a minimum to limit the risk of data loss.
[0179] For illustrative purposes only, we now consider the process in Figure 4 to continue during a C18 sending step in which the local SV2 file server sends an ACK1 confirmation notification to the AG1 agent terminal to confirm that the recording of each FL1a-FL1c file has been executed according to the received C1a-C1b recording commands. This ACK1 confirmation message is received by the AG1 agent terminal during a B18 receiving step.
[0180] In response to this first ACK1 confirmation message, the AG1 agent terminal informs (C20, Figure 4) the SV1 processing server that commands C1a, C1b, and C1c have been executed. To do this, the AG1 agent terminal sends (C20), for example, a second ACK2 confirmation message indicating that the saving of each FL1a-FL1c file has been executed according to the C1a-C1b saving commands. This second ACK2 confirmation message is received by the SV1 processing server during a reception step A20. Thanks to this ACK2 message, the SV1 processing server is kept informed of whether or not the saving commands sent in A12 (Figure 4) have been executed and can thus monitor the status of the process of storing each email in the file system 20.
[0181] For example, in response to the received ACK2 confirmation message, the SV1 processing server updates, or saves, the DT2 index data to specify that each generated FL file (namely FL1a, FL1b, and FL1c) is stored in its respective network location (namely EM 1a, EM 1b, and EM 1c) within file system 20. This advantageously enables precise and reliable traceability and monitoring of the storage status of email files over time. These DT2 index data, whose configuration and format may vary depending on the case, are useful for maintaining an up-to-date map of emails stored over time in file system 20.These DT2 index data can include, for example, in association with each FL file stored in the BP1 project mailbox, the following elements: a name for said file (for example, "FL1aName", "FL1bName", and "FL1cName" corresponding to the files FL1a, FL1b, and FL1c), the respective network location of said file (for example, EM1a, EM1b, and EM1c), and possibly additional descriptive data (or metadata) that characterize said FL file and / or the associated email. The data thus stored in the DT2 index data can be accessed and used later to quickly identify emails, in the form of FL files, in the file system.
[0182] According to one example, the SV1 processing server further saves each FL file (namely FL1a, FL1b and FL1c) in association with the DT2 index data, to allow later retrieval if needed of the MG1 email, for example in the event that the 20 file system is not available or accessible (due to, for example, a failure or any other event).
[0183] As an example, following the receipt (A20) of the ACK2 confirmation message, the processing server SV1 sends (A22, Figures 4 and 6) DT3 description data to the CL client terminals, specifying that the email MG1 is stored in file system 20 at the respective network locations EM1a, EM1b, and EM1c of the generated files FL1a, FL1b, and FL1c. This DT3 description data can be sent to each CL client terminal, including the CL2 client terminal that acted as agent terminal AG1 for the registration of said FL files. Each CL terminal can then locally register the DT3 description data, which can be used later if necessary to determine which email is stored in file system 20 and, if so, to access it using the EM1a-EM1c network locations of the associated FL files.
[0184] The AG1 agent terminal is preferably configured not to retain a local copy of the FL files in memory after the C1a-C1c registration commands are executed. A user can later view the DT3 description data from a CL client terminal, detect that the MG1 email is stored in filesystem 20, and access it if necessary. This approach maximizes resource savings, particularly in terms of data traffic and memory space.
[0185] For example, the DT3 description data does not include the corresponding FL files in order to minimize the amount of data transmitted by the SV1 processing server to the CL client terminals. For example, if the local server SV2 is temporarily unavailable (exceptional circumstances), the SV1 server can transmit the FL1a-FL1c files directly to the client terminals for temporary storage, although this will negatively impact access speed.
[0186] According to an example shown in Figure 7, once the FL1a-FL1c files are stored in the respective network locations MG 1a-MG 1c in file system 20 in response to the C1a-C1c save commands, a user can use a CL client terminal, namely terminal CL3 in this example, to access the MG1 email in file system 20. The CL3 client terminal used for viewing can, as the case may be, be a CL client terminal other than the agent terminal AG1, or the CL client terminal that served as the agent terminal.
[0187] More specifically, it is assumed that the client terminal CL3 receives (B3, Figure 7) a user instruction INS1 to access the email MG1. The user can use a user interface on the CL3 terminal to enter this INS1 instruction, the format and configuration of which may vary depending on the case. This INS1 instruction may follow a query by the user of the data storage status in file system 20, as specified in the DT3 description data. As already mentioned, the DT3 description data includes information characterizing the emails stored in the file system in association with their corresponding network locations. From this DT3 data, the user can, for example, identify the email MG1 they wish to access.
[0188] In response to the user instruction INS1, the client terminal CL3 determines (B32, figure 7), from the description data DT3, the respective network locations EM 1a, EM 1 b and EM1c, in file system 20, of the files FL1a, FL1b and FL1c associated with the email MG1.
[0189] During a B34 retrieval (or read) step, the CL3 client terminal retrieves, from the local file server, the FL1a, FL1b and FL1c files stored in file system 20 at the respective network locations EM 1a, EM 1b and EM 1c of the associated BP1 project box.
[0190] To do this, the CL3 client terminal can, for example, send (B40, Figure 7) an RQ1 access request to the local SV2 file server, specifying the network locations EM1a, EM1b, and EM1c that it wishes to access (in other words, the FL files it wants to access). In response to this RQ1 request, the CL3 client terminal receives (B2, Figure 7) the FL1a, FL1b, and FL1c files from the local SV2 file server as a DT4 data stream.
[0191] During a B36 rendering step (Figure 7), the CL3 client terminal can reconstruct the MG1 email from the retrieved FL1a, FL1b, and FL1c files, and then render the reconstructed MG1 email to the user, for example, via its user interface. The method by which the MG1 email is rendered to the user can be adapted as needed. For example, the CL3 client terminal can display a graphical representation of the MG1 email from the DT4 data stream, such as an image. Rendering methods other than display are also possible. The method by which the attached FL1c file is rendered to the user depends, among other things, on the nature of the file (for example, as an image, video, audio, document, etc.).
[0192] For example, the processing server SV1 can store a copy of each FL file associated with the email MG1. This allows the client terminal CL3 to access the FL1a, FL1b, and FL1c files from the processing server SV1, for instance, in the event of a failure or other issue with the local file server SV2. This makes it possible to further enhance the security of each email's data and minimize the risk of data loss.
[0193] It should be noted that the present invention can be implemented to process an email that does not include an attachment such as the FL1c file described above.
[0194] It should also be noted that the SV1 processing server, the CL client terminals, and the SVO local file server, as previously described, can thus process multiple emails in a manner analogous to that described above with reference to the MG1 email (Figure 1-7). As those skilled in the art will understand, all the embodiments and variations described above, some of which have been intentionally simplified for ease of explanation, are merely non-limiting examples of implementation of this disclosure. In particular, those skilled in the art may consider any adaptation or combination of the embodiments and variations described above to meet a specific need.
[0195] The present invention is therefore not limited to the embodiments described above but extends in particular to a control method that would include secondary steps without departing from the scope of the present invention. The same would apply to a control device, or more generally to a control system, for implementing such a method.
Claims
DEMANDS 1. A method for processing emails, implemented by a processing server (SV1) cooperating with a plurality of client terminals (CL) belonging to a local network (NT2), said local network comprising a local file server (SV2) controlling a file system (20), the method comprising: - receiving, from outside the local network, an email (MG1) including header data (MG1a) and email body data (MG1b); - generation, from the email, of files comprising a header file (FL1a) and an email body file (FL1b) corresponding respectively to the header data and the email body data; - determination, from the header data, of an identifier (ID1) of an associated project box (BP1); - determination, for each generated file, of a network location (EM 1a, EM 1b) associated with the project box according to location data (DT1); - selection of a client terminal as the agent terminal (AG1); and - sending, to the agent terminal, the generated files and save commands (C1a, C1b) specifying the respective network locations (EM1a, EM1b) of the generated files, said save commands causing the agent terminal to save each generated file in the file system (20) of the local file server at the respective network location of the associated project box.
2. A method according to claim 1, wherein the email header file and body file are in text format.
3. Method according to claim 1 or 2, wherein the received email includes at least one attachment, the files generated from said email including an attachment file (FL1 c), in native format, for each attachment of the email.
4. A method according to any one of the preceding claims, further comprising: - receipt, from the agent terminal, of a confirmation message (ACK2) indicating that the recording of each generated file (FL1a, FL1b) has been carried out in accordance with the recording commands; and - In response to the confirmation message, the index data (DT2) was updated. specifying that each generated file (FL1, FL2) is stored at its respective network location (EM1) in the file system (20).
5. A method according to any one of the preceding claims, further comprising: - sending, to each client terminal (CL), description data (DT3) specifying that said email is stored in the file system (20) at the network locations (EM 1a, EM 1b) of the generated files (FL1a, FL1b).
6. A method according to any one of the preceding claims, wherein the selection of a client terminal as the agent terminal comprises: - obtaining performance data representative of the performance of client terminals that have operated in the past as agent terminals; and - selection, as agent terminal, of the client terminal meeting at least one performance criterion according to the performance data.
7. A method according to any one of the preceding claims, wherein a plurality of received emails are processed according to said method, said method further comprising: - generation of a summary file specifying each email received for said project mailbox and the network locations of the files generated for said received email; and - sending the summary file to the local file server, via a client terminal acting as an agent terminal, for recording in the file system, said summary file allowing consultation in text format of each email associated with the project mailbox.
8. Processing method, implemented by a processing system (SY1) comprising a processing server (SV1) and a plurality of client terminals (CL) belonging to a local network (NT2), said local network comprising a local server (SV2) controlling a file system (20), the method comprising: - reception, by the processing server, from outside the local network, of an email (MG1) including header data (MG1a) and email body data (MG1b); - generation, by the processing server, from the email, of files comprising a header file (FL1a) and an email body file (FL1 b) corresponding respectively to the header data and the email body data; - determination, by the processing server, from the header data (DT1a), of an identifier (ID1) of an associated project box (BP1); - determination, by the processing server, for each generated file, of a location network (EM 1a, EM 1 b) associated with the project box according to location data (DT1); - selection, by the processing server, of a client terminal as an agent terminal (AG1); and - sending, by the processing server to the agent terminal, the generated files and save commands (C1a, C1b) specifying the respective network locations (EM1a, EM1b) of the generated files; and - in response to the save commands, the terminal agent saves each generated file (FL1a, FL1 b) in the file system (20) of the local file server at the respective network location of the associated project box.
9. A method according to claim 8, further comprising: - sending, by the agent terminal to the processing server, a confirmation message (ACK2) indicating that the recording of each generated file (FL1a, FL1b) has been carried out in accordance with the recording commands; and - in response to said confirmation message, update, by the processing server, of index data (DT2) specifying that each generated file (FL1, FL2) is stored at its respective network location (EM1) in the file system (20).
10. A method according to claim 8 or 9, further comprising: - sending, by the processing server, to each client terminal (CL), description data (DT3) indicating that said email is stored in the file system (20) at the network locations (EM 1a, EM 1 b) of the generated files (FL1a, FL1 b); - receipt, by a second client terminal among the client terminals, of a user instruction (INS1) to access said email; - in response to said user instruction, determination, by the second terminal, from the description data (DT3), of the respective network locations (EM 1a, EM 1b) of the files (FL1a, FL1b) generated for said email; and - retrieval, by the second terminal, from the local file server, of the files (FL1a, FL1 b) stored in the file system (20) at the respective network locations (EM 1a, EM 1 b) of the associated project box (BP1).
11. A method according to claim 10, wherein the recovery comprises: - sending, by the second client terminal to the local file server, a request to access the files stored in the respective network locations of the file system; - receipt, in response to said access request, by the second terminal, of a data stream representative of said stored files; and - retrieval, by the second client terminal, from the data stream, of said stored files by means of a user interface.
12. Computer program (PG1, PG2) comprising instructions for carrying out the steps of the processing method according to any one of the preceding claims when said program is executed by at least one device.
13. Processing server (SV1) capable of cooperating with a plurality of client terminals (CL) belonging to a local network (NT2), said local network comprising a local file server (SV2) controlling a file system (20), said processing server comprising: - a receiving module (MD2) configured to receive, from outside the local network, an email (MG1) including header data (MG1a) and email body data (MG1b); - a generation module (MD4) is configured to generate, from the email, files comprising a header file (FL1a) and an email body file (FL1b) corresponding respectively to the header data and the email body data; - a first determination module (MD6) configured to determine, from the header data, an identifier (ID1) of an associated project box (BP1); - a second determination module (MD8) configured to determine, for each generated file, a network location (EM 1a, EM 1b) associated with the project box according to location data (DT1); - a selection module (MD10) configured to select a client terminal as an agent terminal (AG1); and - a sending module (MD12) configured to send, to the agent terminal, the generated files and save commands (C1a, C1b) specifying the respective network locations (EM1a, EM1b) of the generated files, said save commands causing the agent terminal to save each generated file in the file system (20) of the local file server at the respective network location of the associated project box.
14. Processing system (SY1) comprising: - the processing server (SV1) according to claim 13; and - a plurality of client terminals (CL) belonging to a local network (NT2), said local network comprising a local server (SV2) controlling a file system (20), in which each client terminal is configured, when selected as an agent terminal by the processing server, to cause registration in the system of files to respective network locations of a project mailbox, of files associated with an email according to save commands (C1a, C1b) sent by said processing server, each save command specifying the respective network location of a file of said email.