FR 2847752 A1 20040528 FR 0214868 A 20021127 2002-0144 Domaine technique La présente invention concerne de façon générale les réseaux de transmission de données tels que le réseau Internet dans lesquels il n'est pas facile de transmettre des fichiers joints aux courriers électroniques parce que ces fichiers sont trop importants ou leur transmission est retreinte vers des utilisateurs enregistrés, et a trait en particulier à une méthode et à un système pour gérer l'échange de fichiers joints à des courriers électroniques. Etat de la technique Dans le monde des télécommunications d'aujourd'hui, l'outil principal utilisé chaque jour par plusieurs centaines de millions de personnes est le courrier électronique ou e-mail. Avec cet outil, les gens envoient et reçoivent des messages de base comprenant du texte mais aussi des messages plus sophistiqués en joignant des fichiers électroniques aux messages. Les types de fichiers joints sont nombreux et non limités. Les types de fichiers les plus connus sont les documents (Microsoft Word, Adobe Acrobat...) les présentations (Power Point), les fichiers audio et vidéo. Les fichiers joints peuvent aussi représenter un fichier d'application si le système de courrier n'a aucune restriction de sécurité sur ce type de fichier, ce qui est souvent le cas pour les serveurs e-mails. En plus du fait que les pirates informatiques utilisent cette possibilité de joindre des fichiers pour distribuer des virus, le fichier joint présente d'autres inconvénients. Un inconvénient est d à la taille des fichiers joints qui n'est pas compatible avec les serveurs électroniques. De façon à éviter la congestion du système de courrier, il y a très souvent une 2 2002-0144 limitation sur la taille du fichier qui peut être joint. En outre, un fichier important peut perturber le transmetteur et le receveur. La quantité de fichiers dans la boîte de courrier est aussi une limitation des systèmes de courrier. Tous les receveurs ne désirent pas recevoir un ensemble de fichiers joints qui dépasse la capacité de la boite à courrier et qui prend trop de temps lorsque la liaison n'est pas rapide telle qu'un accès éloigné. Après ça, les receveurs ont de toute façon à transférer le fichier de leur boite au disque dur et ensuite le retirer de leur boite (sinon, leur boite de courrier devient hors fonction rapidement). En conséquence cette voie, les receveurs perdent la liaison entre le courrier et le fichier et ensuite ne se souviennent pas toujours du nom du fichier et o il a été mémorisé. En plus, les fichiers ne sont pas toujours compressés ce qui entraîne un trafic accru sur le réseau et pour l'emmagasinage dans les serveurs et stations de travail. Les fichiers joints sont également utilisés dans les espaces de travail sur serveur, les serveurs web sécurisés (HTTP, FTP...) ou le partage de fichiers point à point qui sont réservés à des utilisateurs enregistrés. Lorsque ces utilisateurs obtiennent l'accès, ils ont accès à tous les documents de l'espace de travail ou de la base de données. Aussi, ces systèmes doivent être gérés et les utilisateurs doivent se souvenir de mots de passe en même temps que des connexions à ces espaces de travail, URL ou serveurs point à point. Manuellement, un utilisateur peut construire un serveur FTP ou HTTP ou une connexion point à point, envoyer un e-mail avec suffisamment d'informations pour qu'un autre utilisateur utilise un client FTP, un navigateur ou un logiciel point à point pour charger le fichier avec les paramètres correspondants. Cependant, ceci prend du temps pour celui qui envoie aussi bien que pour celui qui reçoit pour effectuer toutes les tâches et exige aussi bien de l'habileté 3 2002-0144 qu'un logiciel adéquat. La tâche principale est cependant pour le transmetteur qui doit administrer le serveur ou doit demander à quelqu'un d'autre de le faire, c'est à dire entrer les droits sur le fichier ou le répertoire, définir des comptes pour les receveurs ou offrir un accès total à tous les fichiers ce qui ne présente pas la sécurité voulue même sur un réseau Intranet. Si l'utilisateur permet d'utiliser le protocole FTP sur son PC, alors il devient plus difficile de permettre l'accès à seulement ce fichier spécifique et pas aux autres qui sont mémorisés avec, du fait que FTP est basé sur l'accès au serveur et non sur l'accès au fichier. La gestion des droits devient un cauchemar si l'utilisateur doit les gérer. Si un autre utilisateur a besoin du fichier, le propriétaire du fichier doit contacter à nouveau un administrateur pour l'ajouter en tant qu'utilisateur. Suivant ce procédé, les utilisateurs doivent être membres de tant d'espaces de travail qu'ils ne savent pas dans lequel trouver l'information. Aujourd'hui, les serveurs du web avec des liens URL sont communément utilisés. En fait, les gens les utilisent en tant qu'utilisateurs pour avoir accès à des fichiers, mais tout le monde peut construire des URL et placer des fichiers dans des serveurs. Ce chargement et cette configuration ne sont pas faciles et, en outre, nécessitent des droits fournis par l'administration. Certains serveurs ont un accès libre et d'autres nécessitent une authentification de l'utilisateur même pour l'accès en lecture, ce qui requiert un mécanisme additionnel. Un autre aspect est le partage des fichiers dans une même société. Si le fichier est pour un utilisateur n'appartenant pas à la même société, alors les limitations pour les deux sociétés sont atteintes et il est difficile de trouver un site commun partagé pour transmettre un fichier volumineux. 4 2002-0144 De ce qui précède, il est clair que l'échange de fichiers joints à des emails entre utilisateurs soulève de plus en plus de problèmes dans la mesure o, soit les fichiers sont trop importants et surchargent la boite courrier de l'utilisateur et/ou prennent trop de temps pour être transmis à l'utilisateur et en conséquence, cet usage est une sorte de déni de service, soit les fichiers ne sont pas transmis à cause de la sécurité ou de la limitation de taille. D'autres solutions pour l'échange de fichiers ont leurs propres inconvénients comme mentionné précédemment, spécialement dans l'administration et les zones sécurisées. Exposé de l'invention En conséquence, le but principal de l'invention est de réaliser une méthode et de fournir un système pour gérer l'échange de fichiers joints à des e-mails qui évite les limitations habituelles des fichiers joints en utilisant un mécanisme simple joint à l'e-mail au lieu du fichier lui-même et adapté pour permettre à l'utilisateur de retrouver le fichier plus tard. L'invention a donc pour objet une méthode pour gérer l'échange d'un fichier entre un transmetteur et un receveur dans un réseau de transmission de données dans lequel un utilisateur parmi une pluralité d'utilisateurs peut transmettre un courrier électronique ayant au moins un fichier joint à au moins un autre utilisateur. Cette méthode comprend les étapes suivantes -le fichier d'origine correspondant au fichier à joindre au courrier électronique est envoyé par le transmetteur à un serveur de fichiers, 2002-0144 -un fichier de substitution comprenant au moins des données d'identification du fichier d'origine est transmis par le serveur de fichiers au transmetteur à la réception du fichier d'origine, -le fichier de substitution est joint au courrier électronique avant que celui-ci soit transmis par le transmetteur au receveur, et -le receveur obtient à tout moment le fichier d'origine du serveur de fichiers en fournissant au serveur de fichiers les paramètres du fichier de substitution. Selon un autre aspect, l'invention concerne un système pour gérer l'échange d'un fichier entre un transmetteur et un receveur dans un réseau de transmission de données dans lequel un utilisateur parmi une pluralité d'utilisateurs peut transmettre un courrier électronique avec au moins un fichier joint à au moins un autre utilisateur. Ce système comprend un serveur de fichiers adapté pour élaborer un fichier de substitution lorsqu'il reçoit du transmetteur un fichier d'origine correspondant au fichier à joindre au courrier électronique, le fichier de substitution comprenant des données d'identification du fichier d'origine permettant au receveur qui reçoit le fichier de substitution joint au courrier électronique provenant du receveur d'obtenir à tout moment le fichier d'origine en envoyant le fichier de substitution au serveur de fichiers. Description brève des dessins Les buts, objets et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description qui suit faite en référence aux dessins dans lesquels: la figure 1 est un bloc-diagramme représentant un environnement de courrier électronique dans lequel la méthode selon l'invention peut être réalisée, 6 2002-0144 la figure 2 est un diagramme représentant les chemins de données entre le transmetteur et le serveur de fichiers pour emmagasiner le fichier original et obtenir le fichier de substitution, la figure 3 est un diagramme représentant les chemins de données utilisés par un receveur pour obtenir un fichier original à partir du serveur de fichiers, la figure 4 est un bloc-diagramme représentant les différentes fonctions utilisées pour mettre le fichier original dans le serveur de fichiers ou pour obtenir le fichier original à partir du serveur de fichiers, la figure 5 est un diagramme représentant les chemins de données d'enregistrement utilisés entre l'utilisateur et le serveur de fichiers, et la figure 6 représente la structure du fichier de substitution joint à l'e-mail transmis par le transmetteur au receveur. Description détaillée de l'invention La figure 1 décrit un environnement de réseau comprenant le réseau Internet 10 et un réseau Intranet il dans lequel trois stations de travail 12, 13 et 15 ont la capacité d'échanger des fichiers de données grâce à un serveur de courrier 17. Par exemple, la station de travail 13 est un transmetteur (SND) et les stations de travail 12 et 15 sont des receveurs (RCV1 et RCV2). Il est supposé que le transmetteur 13 n'a pas la capacité de transmettre un fichier au receveur 12 ou 15 soit à cause de sa taille ou à cause de règles de sécurité telles que des règles empêchant de transmettre ou de recevoir des fichiers exécutables. En outre, le transmetteur 13 ne désire pas ou n'a pas la capacité ou ne peut pas agir comme serveur (tel qu'un serveur FTP) lui- 7 2002-0144 même, de sorte que l'échange direct de fichier sans e-mail n'est pas possible. Selon l'invention, le fichier d'origine à échanger est d'abord mémorisé par le transmetteur dans un serveur de fichiers, soit FS1 16 connecté au réseau Internet 10 ou FS2 14 connecté au réseau Intranet 12. Le besoin d'avoir plusieurs serveurs de fichiers est un besoin de redondance et aussi pour limiter l'accès par les utilisateurs à seulement certains réseaux. Ainsi, on peut supposer que RCV1 peut seulement avoir accès à FS1 16 et RCV2 peut seulement avoir accès à FS2 14. A la place du fichier d'origine, un fichier de substitution est alors joint à l'e-mail transmis par SND 13. Le fichier de substitution est soit un fichier exécutable tel qu'un fichier JavaBeans (marque déposée de SUN) ou un fichier ActiveX (marque déposée de Microsoft) qui comprend le logiciel exécutable pour le téléchargement et le fichier de substitution comportant tous les paramètres et informations relatifs au fichier d'origine. Une alternative est d'envoyer seulement le fichier de substitution comme décrit ci-après, sans le code exécutable pour les utilisateurs qui l'ont déjà installé sur leur station de travail ou pour éviter les problèmes de pare-feu bloquant les fichiers exécutables. Le code exécutable qui fournit l'accès au serveur de fichiers peut être chargé à partir du serveur de fichiers luimême, via un serveur web ou fourni dans un e-mail durant la phase d'enregistrement telle que décrite plus loin. Le procédé pour emmagasiner un fichier à partir d'une station de travail telle que SND 13 dans un serveur de fichiers tel que FS2 14 est montré sur la figure 2. Il commence par l'étape 21 d'authentification du transmetteur qui peut être réalisée en utilisant des clés d'authentification connues du serveur de fichiers. Si l'utilisateur n'a pas de clés d'authentification prédéfinies telles qu'un certificat 8 2002-0144 d'utilisateur, le serveur de fichiers peut fournir de telles clés grâce à un procédé de sécurisation basé sur les e-mails. Une fois que l'authentification a été faite, le serveur de fichiers répond par un message ACK SND 22. Puis, le transmetteur peut envoyer le fichier au serveur de fichiers en utilisant le protocole FTP ou HTTP référencé en tant qu'étape "MEMORISER fichier d'origine" 23. Lorsqu'il est traité par un logiciel de traitement de fichier dans la station de travail, le fichier d'origine peut être encrypté et compressé en utilisant des clés fournies par le serveur de fichiers, bien que ce pré-traitement peut être réalisé à n'importe quel moment avant cette étape. Quand le fichier d'origine est reçu par le serveur de fichiers, celui-ci calcule une identification de fichier unique et construit un fichier de substitution envoyé au transmetteur à l'étape "OBTENIR fichier de substitution" 24. Cette étape peut être un simple transfert utilisant FTP ou HTTP mais une méthode préférée peut être d'envoyer le fichier de substitution par e-mail à l'utilisateur attendu que des dispositifs parefeu pourraient empêcher l'utilisation de la première solution. On doit noter que le fichier de substitution peut aussi être construit dans la station de travail mais l'ID du fichier qui est unique dans le serveur de fichiers et la façon de retrouver le fichier d'origine doivent être fournis par le serveur de fichiers. Lorsque l'utilisateur de la station de travail SND 13 désire fournir le fichier aux utilisateurs de RCV1 15 ou RCV2 12 par exemple, il a seulement à ajouter ce fichier de substitution comme fichier joint dans le e-mail envoyé à RCV1 et RCV2. Une option est de mettre en copie le serveur de fichiers dans l'e-mail de manière à ce qu'il sache quels utilisateurs peuvent obtenir le fichier, ce que ce dernier dépend des règles de 9 2002-0144 sécurité appliquées à ce fichier et qui sont détaillées dans des champs du fichier de substitution. Avec ou sans la partie exécutable, le fichier de substitution permet aux receveurs d'e-mails de retrouver le fichier d'origine. Le receveur d'un email ouvre, par exemple, un Activex/javaBeans inclus dans l'e-mail (qui remplace le fichier d'origine) et ceci lui permet de retrouver automatiquement (par chargement) le fichier joint à partir du serveur de courrier en utilisant FTP ou HTTP si aucun moyen de sécurité n'est requis durant les étapes de création. Généralement, un mécanisme plus sécurisé est nécessaire. En référence à ce qui est illustré par les chemins de données de la figure 3, le procédé commence par une authentification du receveur (ici RCV2 12) similaire à la figure 2 comportant les étapes 25 et 26. En fait, comme les utilisateurs peuvent envoyer et recevoir des fichiers, ils ont juste besoin d'un seul moyen d'enregistrement pour les deux actions qui peut être utilisé préalablement comme expliqué ci-dessous. Seul le fichier correspondant au fichier joint et spécifiquement au champ d'identification peut être obtenu à partir du serveur de fichiers. Toutes les informations telles que l'adresse du serveur, le nom du fichier, les paramètres d'authentification sont inclus dans le fichier de substitution et traités de façon transparente. L'étape 27 "FOURNIR ficher de substitution" correspond à un message envoyé par l'utilisateur RCV2 au serveur de fichiers FS2 pour obtenir le fichier. Ceci peut être géré par le même logiciel que celui utilisé pour mémoriser le fichier logiciel qui est pré-chargé dans la station de travail, ou inclus dans le fichier de substitution joint, ou téléchargé à partir de n'importe quel serveur de fichiers grâce au navigateur web. Le fichier d'origine est obtenu en utilisant 2002-0144 le protocole FTP ou HTTP initialisé par l'utilisateur à l'étape 28 "OBTENIR fichier d'origine". On doit noter que, si un autre utilisateur tel que RCV1 15 peut seulement atteindre le serveur de fichiers 16 connecté au réseau Internet 10, et si le serveur de fichiers 16 n'a pas le fichier demandé, il peut l'obtenir à partir du serveur de fichiers 14 pourvu que les serveurs de fichiers aient des moyens sécurisés pour communiquer entre eux. A noter que le mécanisme de récupération gère l'authentification pour le serveur de fichiers, qui est unique pour un fichier, et une fois que l'authentification a été effectuée, la seconde vérification se sert de la valeur de hachage, incluse également dans le fichier de substitution. Par conséquent, une attaque par balayage de toutes les combinaisons possibles peut seulement garantir l'accès à l'étape o la valeur de hachage est requise. Seul le fichier de substitution contiendra cette valeur de hachage, ce qui est difficile à pirater. Les serveurs pour de tels fichiers peuvent être entièrement d'accès libre même pour des gens mémorisant des fichiers spécialement sur Intranet. Maintenant, la figure 4 décrit les fonctions incluses dans le logiciel utilisé pour Interfacer le serveur de fichiers. Le premier bloc fonctionnel important est la fonction d'authentification 30 qui est utilisée pour authentifier l'utilisateur. Cette fonction d'authentification utilise une clé privée et sa clé publique associée qui est mémorisée par le système d'exploitation dans le fichier. Il peut aussi avoir accès à un fichier contenant l'adresse de serveur de fichiers connus tels qu'un fichier HOST. Durant la phase d'authentification, les messages sont hachés/signés en utilisant la clé privée du transmetteur et le receveur utilise la clé publique correspondante pour authentifier la signature. 11 2002-0144 Une fois que l'authentification est effectuée, un choix entre deux procédures est permis: la procédure de mémorisation de fichier ou la procédure d'obtention de fichier. Pour mémoriser des fichiers la procédure "Proc fichier d'origine" 31 permet de préparer le fichier pour son emmagasinage comme le hachage du fichier pour obtenir une signature, la compression, l'encryptage si nécessaire. La clé publique du serveur est aussi utilisée pour encrypter le fichier qui est envoyé de sorte qu'une transmission dans un réseau non sécurisé (Internet) est entièrement protégée: authentification pour la connexion au serveur, vérification pour la connexion au serveur, vérification du hachage du fichier et ensuite encryptage pour téléchargement comme options possibles. Un procédé de mémorisation et d'obtention fichier par fichier sécurisé est utilisé sans nécessiter un mot de passe. Le risque, même avec un serveur se trouvant sur Internet est minimum du fait que c'est un procédé fichier par fichier. Chaque fichier a un accès différent pour l'authentification et une valeur de hachage différente (deux étapes de vérification) et seulement le numéro de port correspondant à ce protocole a besoin d'être ouvert. Il n'y a pas ouverture FTP ou HTTP. La solution proposée n'utilise pas de mot de passe, mais seulement l'ID du fichier de substitution une fois et une clé privée téléchargeable comme décrit ci-dessous. Puis, le mot de passe ne peut pas être perdu. Les clés privées d'utilisateur et les clés publiques associées peuvent être changées à tout moment. Un changement de clé publique de serveur peut être effectué par le serveur grâce à un e-mail avec la validation utilisant la clé courante. Ensuite, le fichier peut être téléchargé dans le serveur en utilisant un protocole de transfert de fichiers standard au moyen de la fonction "Mémorisation" 32. Durant cette phase, l'utilisateur peut définir des paramètres spécifiques à appliquer 12 2002-0144 tels que le temps de conservation du fichier, la protection d'accès et la protection de mémorisation ou la vérification d'absence de virus. Le logiciel attend alors le traitement du fichier côté serveur qui doit se terminer par un message d'accusé réception de la mémorisation et la transmission par le serveur de fichiers du fichier de substitution confirmant les paramètres demandés. La réception et l'emmagasinage du fichier de substitution avec une interface par e-mail optionnelle correspond au bloc fonctionnel "Fourniture fichier de substitution" 33. Pour obtenir les fichiers, la procédure "Proc fichier substitution" 34 analyse le fichier de substitution reçu et présente les paramètres à l'utilisateur sur son interface utilisateur. L'interface utilisateur dans le mode de réalisation proposé est un navigateur web. En se basant sur les informations et les paramètres existants dans la station de travail, l'utilisateur peut alors procéder directement à la localisation du fichier ou peut avoir à l'enregistrer de nouveau si le domaine sur lequel est situé le serveur n'est pas un des domaines enregistrés de la station de travail. La fonction "Situer fonction d'origine" 35 permet l'identification du serveur le plus proche à partir duquel le fichier peut être téléchargé. En se basant sur l'adresse IP courante, le serveur principal indiqué dans le fichier de substitution peut fournir un nom de serveur alterné pour optimiser le téléchargement ou, si le serveur principal ne peut pas être atteint, le serveur local de la station de travail devra trouver l'identification du meilleur site ou même obtenir le fichier lui-même à partir du serveur principal. La dernière fonction 36 est le téléchargement ou "Fourniture fichier d'origine" qui utilise un protocole de transfert de fichiers standard pour obtenir le fichier. Différents niveaux de sécurité peuvent être réalisés par la mémorisation du fichier, mais une étape préliminaire est 13 2002-0144 d'authentifier les utilisateurs. L'utilisation de certificats mémorisés par les stations de travail ou par des dispositifs pouvant être retirés est possible dans une société. Dans ce cas, de tels certificats peuvent être ré-utilisés et ceci élimine le besoin d'authentification de l'utilisateur effectuée au niveau du serveur du fait que le serveur sera capable de valider de tels certificats directement avec l'autorité de certification de la société (CA). Autrement, un mécanisme dédié peut être utilisé comme illustré sur la figure 5. Cette authentification n'est pas toujours exigée si aucune protection n'est nécessaire correspondant à la mémorisation libre des fichiers. Plutôt, les personnes mémorisant des fichiers ou ayant accès à des fichiers peuvent obtenir une clé et un ID la première fois qu'elles mémorisent ou obtiennent quelque chose. Dans le mécanisme d'authentification proposé, il n'y a pas besoin de mot de passe pour cela puisque aucune contrainte administrative n'est imposée par le serveur de fichiers. Le fichier est mémorisé avec un mécanisme prédéfini, la sécurité est au niveau du fichier et aucune mesure spéciale n'est nécessaire du fait que la solution n'exige pas d'être gérée. La vérification d'identité du receveur peut être effectuée si nécessaire: * sinon, le fichier de substitution permettra au receveur d'obtenir le fichier d'origine, * s'il y a une nécessité d'authentifier le receveur, le receveur se verra d'abord attribuer une clé et un ID la première fois qu'il demandera un fichier au serveur. Un receveur devra seulement donner son ID de courrier pour obtenir la clé et l'ID par e-mail. Ceci authentifie l'utilisateur mais aucun mot de passe n'est exigé. En possession de cette clé, un utilisateur peut obtenir des fichiers protégés et placer des fichiers sur le serveur. 14 2002-0144 Le mécanisme d'enregistrement optionnel proposé est basé sur la validation par e-mail. La requête d'enregistrement est initialisée par l'utilisateur 13 à l'aide d'un message d'enregistrement 41 transmis au serveur de fichiers 14, l'utilisateur fournissant son adresse e-mail comme paramètre. Ceci peut être réalisé en mode navigateur sur le serveur de fichiers agissant comme serveur web ou par e-mail. Le serveur de fichiers répond par un e-mail d'accusé réception d'enregistrement 42 envoyé au serveur de courrier sur lequel l'utilisateur peut retrouver et lire le courrier. Ce message 42, dans le mode de réalisation préféré, contient les clés privée et publique et la clé publique du serveur aussi bien que le logiciel utilisateur pour installer ces clés si c'est autorisé. Ces clés peuvent être fournies comme texte ou comme fichier joint. Le logiciel de l'utilisateur se procure ces clés à l'étape 43 et les met dans les fichiers adéquats du système d'exploitation de manière à ce qu'il puisse les ré-utiliser plus tard. Finalement, l'utilisateur répond par un message 44 que les clés ont été reçues, ce message étant un e-mail ou un message direct en mode navigateur utilisé pour envoyer l'enregistrement ou les deux pour plus de sécurité. Comme décrit ci-dessus, le fichier de substitution ou les deux pour plus de sécurité. Comme décrit ci-dessus, le fichier de substitution dans sa version texte, contient plusieurs champs de données. Ce fichier, dans le mode de réalisation préféré, est structuré en utilisant le langage XML de manière à simplifier sa visualisation par un navigateur web. Comme illustré sur la figure 6, les champs principaux du fichier de substitution sont: * L'ID de fichier qui est unique dans le serveur ou mieux dans le domaine qui peut comporter plusieurs serveurs. Cet ID est 2002-0144 donné lorsque le fichier d'origine est mémorisé dans le serveur de fichiers et constitue le pointeur principal vers le fichier d'origine pour simplifier ainsi sa recherche. * La valeur de hachage qui est aussi normalement unique (mais pas obligatoire). Elle est utilisée comme validation de sécurité de manière à ce qu'un fichier ne puisse pas être retrouvé seulement par son ID. Une requête est ensuite transmise à l'utilisateur pour obtenir la valeur de hachage correspondant à la signature du fichier de façon a être autorisé à l'obtenir. De plus, la valeur de hachage peut être utilisée par le serveur pour identifier des fichiers dupliqués et, par conséquent, il suffit de garder seulement un fichier avec plusieurs pointeurs ajoutés au fichier de substitution. * Le champ de protection d'accès qui définit les règles à suivre pour obtenir le fichier d'origine. Un fichier peut être récupéré seulement par des gens listés sur la liste de distribution du e- mail envoyé avec le fichier de substitution. Dans ce cas, un envoi du fichier de substitution à d'autres utilisateurs est sans utilité puisqu'il ne pourront pas obtenir le fichier. Même plus, une exigence d'encrypter le fichier en utilisant la clé publique du receveur peut être établie de sorte que le fichier ne puisse pas être intercepté par quelqu'un d'autre. Aussi, la visualisation du fichier peut être liée avec des dispositifs de visualisation ou des éditeurs à ce fichier encrypté de manière à ce que le fichier ne soit jamais mémorisé en clair. D'autres valeurs du champ peuvent correspondre à l'autorisation de redistribution interne libre (e-mails avec le même suffixe xxx.com), une redistribution contrôlée (nécessité de mettre le serveur de fichiers en copie lorsque le fichier de substitution est transmis). 16 2002-0144 * La protection de mémorisation définissant sur combien de serveurs le fichier d'origine peut être conservé. Un champ additionnel donne la date d'expiration définissant la période de temps pendant laquelle le fichier d'origine doit être mémorisé. Le retrait du fichier peut être automatique ou sous le contrôle du transmetteur. * Un serveur source et un champ de domaine indiquant le serveur principal mémorisant le fichier d'origine, les autres sources pour le fichier correspondant à des serveurs alternatifs, et les domaines de ces serveurs o le fichier peut être retrouvé même si un utilisateur fait une requête à un serveur n'étant pas une source pour le fichier. * La taille du fichier d'origine est aussi utilisée pour informer l'utilisateur et pour la gestion du fichier (avec la valeur de hachage). * L'option de vérification de virus informant le receveur qu'une vérification de la présence de virus a été effectuée sur le fichier d'origine (demandée par le transmetteur). Cette option indique que le logiciel antivirus a été utilisé et à quel niveau. * Un champ de message qui peut contenir toutes informations utiles pour l'utilisation telles que la description du contenu du fichier d'origine. Il peut être très utile pour la recherche puisque le fichier ne peut pas être balayé directement. Ceci peut inclure automatiquement les premières phrases d'un document par exemple. * Le champ du transmetteur d'origine identifiant le ou les utilisateurs qui ont mémorisé le fichier d'origine. Ce peut être une liste si le même fichier a été mémorisé par plusieurs personnes. Un champ associé est la date de création du fichier de substitution. 17 2002-0144 Les paramètres d'encryptage et de compression qui peuvent être aussi fournis comme option. Un fichier d'origine peut être mémorisé en utilisant une technique d'encryptage et/ou compression et peut être récupéré en utilisant d'autres techniques au choix de celui qui le demande. Par exemple, un fichier peut être mémorisé en mode Zip avec un mot de passe et récupéré avec une compression RAR et un encryptage SSL entre l'utilisateur et le serveur. A noter que le nom du fichier de substitution peut être basé sur le nom du fichier d'origine avec une nouvelle extension ajoutée ou remplaçant le type du fichier existant. Ainsi, pour un fichier d'origine appelé nomfichier.ext, le fichier de substitution peut être appelé nomfichier. ext.sub ou nomfichier.sub. Dans ce dernier cas, le type de fichier peut être inclus dans le champ de message ou dans un champ dédié additionnel. Ceci peut être réalisé également pour le nom de fichier si le nom du fichier d'origine est différent du nom du fichier de substitution. 18 2002-0144 REVENDICATIONS 1. Méthode pour gérer l'échange d'un fichier entre un transmetteur (13) et un receveur (12, 15) dans un réseau de transmission de données (10, 11) dans lequel un utilisateur parmi une pluralité d'utilisateurs peut transmettre un courrier électronique ayant au moins un fichier joint à au moins un autre utilisateur parmi ladite pluralité d'utilisateurs; ladite méthode étant caractérisée en ce qu'elle comprend les étapes suivantes: le fichier d'origine correspondant au fichier à joindre audit courrier électronique est envoyé par ledit transmetteur à un serveur de fichiers (14), - un fichier de substitution comprenant au moins des données d'identification dudit fichier d'origine est transmis par ledit serveur de fichiers audit transmetteur à la réception dudit fichier d'origine, ledit fichier de substitution est joint audit courrier électronique avant que celui-ci soit transmis par ledit transmetteur audit receveur, et - ledit receveur obtient à tout moment ledit fichier d'origine dudit serveur de fichiers en fournissant audit serveur de fichiers les paramètre dudit fichier de substitution. 2. Méthode selon la revendication 1, dans laquelle ledit fichier de substitution comprend une valeur de hachage calculée à partir dudit fichier d'origine qui est utilisée comme signature de fichier en combinaison avec lesdites données d'identification par ledit receveur (12) pour obtenir ledit fichier d'origine à partir dudit serveur de fichiers (14). 19 2002-0144 3. Méthode selon la revendication 1 ou 2, dans laquelle une liste de distribution des utilisateurs autorisés à obtenir ledit fichier d'origine est transmise audit receveur (13) par ledit serveur de fichiers (14) avec ledit fichier de substitution. 4. Méthode selon la revendication 3, dans laquelle une date d'expiration définissant une période de temps durant laquelle ledit fichier d'origine est mémorisé dans ledit serveur de fichiers (14) est transmise audit receveur (13) par ledit serveur de fichiers avec ledit fichier de substitution. 5. Méthode selon la revendication 4, dans laquelle des serveurs alternatifs peuvent être accédés par les utilisateurs pour obtenir ledit fichier d'origine, ledit fichier de substitution comprenant l'adresse dudit serveur de fichiers (14) en tant que serveur principal mémorisant ledit fichier d'origine et les adresses desdits serveurs alternatifs. 6. Méthode selon la revendication 5, dans laquelle ledit fichier d'origine est encrypté et/ou compressé avant d'être transmis par ledit transmetteur (13) audit serveur de fichiers (14) en utilisant les clés fournies par ledit serveur de fichiers. 7. Méthode selon l'une des revendications 1 à 6, dans laquelle une procédure d'authentification dudit transmetteur (13) contrôlée par ledit serveur de fichiers (14) est réalisée avant que ledit fichier d'origine soit transmis par ledit transmetteur audit serveur de fichiers. ATT 2002 0149 2002-0144 8. Méthode selon la revendication 7, dans laquelle une procédure d'authentification dudit receveur (12) contrôlée par ledit serveur de fichiers (14) est réalisée avant que ledit receveur demande de recevoir ledit fichier d'origine à partir dudit serveur de fichiers. 9. Méthode selon l'une des revendications 1 à 6, dans laquelle une procédure d'enregistrement dudit transmetteur (13) est effectuée avant que ledit transmetteur envoie ledit fichier d'origine audit serveur de fichiers (14), ladite procédure d'enregistrement consistant pour ledit transmetteur à envoyer au moins son adresse e-mail audit serveur de fichiers comme paramètre, ledit serveur de fichiers renvoyant audit transmetteur les clés privée et publique à utiliser plus tard pour obtenir ledit fichier d'origine et la clé publique dudit serveur de fichiers. 10. Méthode selon l'une quelconque des revendications 1 à 9, dans laquelle aucun code exécutable n'est inclus dans ledit fichier de substitution identifiant ledit fichier d'origine, ce code exécutable étant téléchargé à partir dudit serveur de fichiers (14) vers ledit receveur qui désire obtenir ledit fichier d'origine. 11. Méthode selon l'une quelconque des revendications 1 & 9, dans laquelle ledit fichier de substitution est un fichier exécutable tel q'un "Ben" Java ou un fichier "ActiveX". 12. Système pour gérer l'échange d'un fichier entre un transmetteur (13) et un receveur (12, 15) dans un réseau de transmission de données (10, 11) dans lequel un utilisateur parmi une pluralité d'utilisateurs peut transmettre un courrier électronique avec au moins un fichier joint à au ATT 2002 0149 21 2002-0144 moins un autre utilisateur parmi ladite pluralité d'utilisateurs; ledit système étant caractérisé en ce qu'il comprend un serveur de fichiers (14 ou 16) adapté pour élaborer un fichier de substitution lorsqu'il reçoit dudit transmetteur un fichier d'origine correspondant au fichier à joindre audit courrier électronique, ledit fichier de substitution comprenant des données d'identification dudit fichier d'origine permettant audit receveur qui reçoit ledit fichier de substitution joint audit courrier électronique provenant dudit receveur d'obtenir à tout moment ledit fichier d'origine en envoyant ledit fichier de substitution audit serveur de fichiers. 13. Système selon la revendication 12, dans lequel ledit fichier de substitution comprend une valeur de hachage calculée à partir dudit fichier d'origine qui est utilisée comme signature de fichier en combinaison avec lesdites données d'identification par ledit receveur (12) pour obtenir ledit fichier d'origine à partir dudit serveur de fichiers (14). 14. Système selon la revendication 12 ou 13, dans lequel ledit serveur de fichiers (14) possède une liste de distribution des utilisateurs autorisés à obtenir ledit fichier d'origine, ladite liste de distribution étant transmise audit transmetteur (13) par ledit serveur de fichiers avec ledit fichier de substitution. 15. Système selon la revendication 14, dans lequel ledit serveur de fichiers (14) mémorise une date d'expiration définissant une période de temps durant laquelle ledit fichier d'origine doit être conservé, ladite date ATT 2002 0149 22 2002-0144 d'expiration étant transmise audit transmetteur par ledit serveur de fichiers avec ledit fichier de substitution. 16. Système selon la revendication 15, comprenant en outre des serveurs de fichiers alternatifs (16) qui peuvent être accédés par les utilisateurs pour obtenir ledit fichier d'origine, ledit fichier de substitution comportant l'adresse dudit serveur de fichiers (14) en tant que serveur principal mémorisant ledit fichier d'origine et les adresses desdits serveurs alternatifs. 17. Système selon l'une quelconque des revendications 12 à 16, dans lequel une procédure d'enregistrement dudit transmetteur (13) est effective avant que ledit transmetteur envoie ledit fichier d'origine audit serveur de fichiers (14), ladite procédure d'enregistrement consistant pour ledit transmetteur à envoyer au moins son adresse e-mail audit serveur de fichiers en tant que paramètre, ledit serveur de fichiers renvoyant audit transmetteur les clés privée et publique à utiliser plus tard pour obtenir ledit fichier d'origine et la clé publique dudit serveur de fichiers. 18. Système selon l'une quelconque des revendications 12 à 17, dans lequel aucun code exécutable est inclus dans ledit fichier de substitution identifiant ledit ficher d'origine, ce code exécutable étant téléchargé à partir dudit serveur de fichiers (14) vers ledit receveur que désire obtenir ledit fichier d'origine. 19. Système selon l'une quelconque des revendications 12 à 17, dans lequel ledit fichier de substitution est un fichier exécutable tel qu'un "Bean" Java ou un fichier "ActiveX". ATT 2002 0149