PROCEDE DE CREATION ET D' ENVOI DE MESSAGES ELECTRONIQUES ET SYSTEME DE
MESSAGERIE ASSOCIE
La présente invention concerne un procédé de création et d'envoi de messages électroniques, et un système associé
Les systèmes de messagerie électronique sont aujourd'hui très largement utilisés, à des fins tant personnelles que professionnelles. 5 Ils peuvent être mis en œuvre dans des réseaux privés (de type
Intranet), ou publics (réseau Internet - World Wide Web par exemple).
Les systèmes de messagerie électronique constituent un vecteur de communication qui permet d'échanger des informations de manière rapide.
De plus, les progrès des systèmes de messagerie permettent aujourd'hui
10 d'échanger des messages dont la mise en forme et l'aspect visuel peuvent être adaptés selon une multitude d'options désirées.
A cet égard, une application importante des messageries électroniques est la diffusion de messages d'information sur des produits et des services, par exemple à des fins commerciales. Ce type de diffusion est
15 généralement mis en œuvre par l'intermédiaire d'un réseau public (en particulier le World Wide Web).
La figure 1 représente schématiquement les moyens permettant de transmettre un message électronique par l'intermédiaire d'un réseau. Elle montre un ensemble émetteur 10 relié par une liaison L du réseau à un
2 o ensemble récepteur 20.
Sur cette figure, l'ensemble émetteur 10 associé à un utilisateur émetteur, comprend des moyens 11 d'édition d'un message original M ainsi que des moyens 12 de préparation de la transmission de ce message.
L'ensemble émetteur peut être un ordinateur, ou tout autre type de 25 dispositif pouvant être connecté à un réseau.
Les moyens 11 peuvent par exemple comprendre des logiciels de traitement de texte et de traitements graphiques divers résidant sur un ordinateur de l'utilisateur émetteur.
Les moyens 12 comprennent un programme de messagerie, et
3 o seront désignés dans ce texte par le terme générique de « gestionnaire de messagerie » (correspondant à la désignation anglo-saxonne de « mailer »). Ils permettent de convertir le message original M en un
message converti correspondant M', afin que celui-ci puisse être transmis par l'intermédiaire de la liaison L à l'ensemble récepteur 20.
La liaison L peut mettre en œuvre tout moyen de transmission connu en soi, filaire ou non. Dans le cadre de transmission de message sur le réseau World
Wide Web, les transmissions de message se font habituellement selon le protocole SMTP (Simple Mail Transfer Protocol), les données des messages étant encodées selon un mode en 7 bits.
La liaison L est associée à un serveur de courrier S auquel est relié l'ensemble récepteur 20 (ainsi que généralement une pluralité d'autres ensembles récepteurs).
Ce serveur S fonctionne selon un protocole de distribution de messages, tel que le protocole POP (Post Office Protocol) qui permet de gérer la distribution des messages convertis M' transmis par la liaison L. De nombreux serveurs fonctionnent actuellement selon une version évoluée de POP : POP2 ou POP3, qui permettent de transmettre des messages non seulement en mode texte, mais également sous forme de pages html (hypertext mark-up language), aspect sur lequel on va revenir dans ce texte. Les moyens décrits ci-dessus permettent d'acheminer jusqu'à l'ensemble récepteur un message M', sous forme encodée en 7 bits.
Ce message encodé est reçu par un gestionnaire de messagerie 22 de l'ensemble récepteur 20, puis transmis par ce gestionnaire de messagerie à des moyens d'édition 21 de l'ensemble récepteur destinés à reconstituer un message M", qui correspond également au message M envoyé par l'émetteur.
Les moyens d'édition 21 comprennent une interface telle qu'un écran, l'interface étant généralement associée à des logiciels permettant d'éditer le message M" sous une forme identique - ou au moins similaire - à celle qu'avait le message original correspondant M.
L'expression « correspondre à » employée ci-dessus à propos des messages M, M' et M", signifie que les informations du message M sont
normalement également comprises dans le message M', ainsi que dans le message M" - et dans celui-ci ces informations sont présentées sous une forme intelligible à un utilisateur récepteur.
Et cette correspondance implique également que l'aspect graphique du message M" édité côté utilisateur reproduise fidèlement l'aspect graphique du message M original.
Historiquement, les premiers systèmes de messagerie permettaient de transmettre des messages qui véhiculaient une information en mode texte, mais dont les options de mise en forme étaient inexistantes, ou extrêmement limitées.
Or comme on l'a dit, un avantage important des systèmes de messagerie modernes est qu'ils permettent d'adapter de manière désirée la mise en forme et l'aspect visuel des messages transmis.
Il est ainsi généralement possible d'éditer un message original comportant des options de mise en forme sophistiquées, mettant par exemple en oeuvre des polices de caractères spécifiques.
Une telle possibilité est avantageuse dans de nombreux cas. Un exemple est la diffusion de messages à caractère commercial et/ou promotionnel, dans lesquels il est ainsi possible de faire figurer les caractéristiques visuelles d'un produit ou d'une marque (logo, écriture selon une police de caractères bien particulière, ...).
Une solution répandue pour créer des messages originaux comportant un aspect désiré consiste ainsi à créer le message original M sous forme d'une page html. On comprend que pour certaines applications du type de celles mentionnées ci-dessus, il est important de conserver l'intégrité visuelle du message transmis.
Or dans le cas où les moyens d'édition de l'ensemble récepteur ne disposent pas des mêmes possibilités graphiques que les moyens d'édition de l'ensemble émetteur, il est possible que certains éléments ou options graphiques du message original M soient dégradés dans le message M" visualisé par l'utilisateur récepteur.
Ce sera le cas lorsque par exemple une police de caractères utilisée pour créer le message original M (y compris sous forme d'une page html) n'est pas disponible dans l'ensemble récepteur 20.
Les moyens d'édition 22 de cet ensemble récepteur procéderont alors généralement à une recherche automatique d'une police « similaire », selon des critères tels que l'espacement entre caractères successifs, et à l'utilisation de la police « similaire » ainsi identifiée dans l'ensemble récepteur 20 pour éditer le message M".
Et le problème évoqué ci-dessus concerne également les options de mise en forme de manière générale.
De plus, les gestionnaires de messagerie de certains ensembles récepteurs actuellement installés ne sont pas compatibles avec le format html, et dégradent les messages html en mode texte. Et il en est de même pour certains serveurs de courrier - correspondant au serveur S de la figure 1 - qui fonctionnent selon la version initiale du protocole POP : de tels serveurs dégradent en effet les messages html au format texte.
Par ailleurs, un autre inconvénient associé à la création de messages html est que ce type de message est lourd et complexe à créer, et nécessite de faire appel à un spécialiste qualifié en programmation. Et dans le cas fréquent où les messages envoyés sous forme de pages html comportent des liens hypertexte pointant vers des adresses du réseau mis en œuvre pour la transmission de messages, l'affichage des parties correspondantes du message côté émetteur est retardé, car il est nécessaire que le système récupère ces parties aux adresses indiquées pour les afficher.
Une autre solution connue pour créer des messages originaux comportant un aspect désiré consiste à constituer des fichiers images d'un message original ayant un aspect désiré, lesdits fichiers images étant ensuite envoyés comme pièces attachées d'un message de transmission, envoyé à un utilisateur choisi.
Le document US 6092104 divulgue un exemple d'une telle solution.
Mais le serveur de courrier de l'ensemble récepteur qui est associé à l'utilisateur destinataire du message de transmission, peut ici encore compromettre le bon affichage des pièces jointes sur le poste du destinataire. II est en effet possible que la réception du message de transmission ne s'accompagne pas de l'ouverture automatique des pièces jointes, de sorte que le destinataire recevant un tel message de transmission n'a pas directement accès aux images.
Or, il est parfois souhaitable de garantir que les images correspondant à un message original soient automatiquement et systématiquement éditées sur le poste du destinataire, par exemple pour des opérations d'envoi de messages informatifs et/ou promotionnels.
Et dans le cas de la technique connue divulguée par US 6092104, certaines versions des ensembles récepteurs ne provoquent pas l'ouverture automatique de fichiers images qui sont attachés comme pièces jointes à un message de transmission.
Un but de l'invention est de permettre de transmettre des messages par l'intermédiaire d'un système de messagerie ayant la structure générale représentée ci-dessus, en garantissant que l'intégrité visuelle du message est conservée.
Un autre but de l'invention est de permettre en outre que les messages ainsi transmis demeurent d'une taille mémoire limitée, de manière à ne pas alourdir la transmission du message et contribuer à la saturation du réseau utilisé. Un autre but de l'invention est de permettre en outre que l'affichage du message sur les moyens d'édition de l'ensemble récepteur soit rapide.
Un autre but encore de l'invention est de garantir l'affichage systématique de l'aspect visuel d'un message original sur un ensemble récepteur. Enfin, l'invention vise également à protéger la confidentialité des échanges de messages, et à sécuriser leur transmission.
Afin d'atteindre ces buts, l'invention propose selon un premier aspect un procédé de création et d'envoi de messages électroniques d'un ensemble émetteur à un ensemble récepteur, les deux ensembles étant reliés par une liaison d'un réseau, chaque ensemble étant associé à un gestionnaire de messagerie respectif, caractérisé en ce que le procédé comprend la réalisation des étapes suivantes par l'ensemble émetteur :
• édition sur l'ensemble émetteur d'un fichier original pouvant comprendre du texte et/ou des images,
• acquisition d'au moins une image du fichier original en cours d'édition,
• constitution du message avec la ou les image(s) acquise(s), le message étant encodé en mode 7 bits, et chaque image étant intégrée au message de manière à être directement visualisée à l'ouverture du message correspondant sur l'ensemble récepteur.
Des aspects préférés, mais non limitatifs du procédé selon l'invention sont les suivants :
• l'intégration de chaque image au message se fait par l'intermédiaire d'une instruction de type « inline »,
• la liaison est associée à un protocole de transmission de type SMTP,
• l'étape d'acquisition d'image comprend : une initialisation lors de laquelle on sélectionne le format d'image dans lequel on souhaite constituer des images à partir du fichier original, la détection des sauts de page dans le fichier original, pour chaque page du fichier original, la constitution d'un fichier image correspondant à la page du fichier original.
• lors de la constitution d'un fichier image pour chaque page, on réalise les opérations suivantes :
S définition du nom de fichier page,
• définition d'une adresse de mémorisation pour le fichier page dans un endroit désiré de mémorisation de l'ensemble émetteur,
•S construction d'une image bitmap dans la mémoire vive de l'ensemble émetteur, association à ce fichier image bitmap du nom de fichier page, •S compression du fichier bitmap mémorisé en mémoire vive et création dans l'endroit désiré de mémorisation d'un fichier compressé.
• l'étape de constitution de message comprend :
•S l'appel d'un serveur du réseau et l'ouverture d'une session auprès de ce serveur, pour chaque page du fichier original, l'intégration au message du contenu d'un fichier correspondant à l'image de ladite page.
• lors de l'intégration au message du contenu d'un fichier correspondant à l'image de ladite page, on réalise les opérations suivantes : ouverture du fichier compressé mémorisé dans l'endroit désiré de mémorisation, insertion de l'en-tête de ce fichier page compressé dans le message, déclaration de ce fichier compressé comme devant être ouvert automatiquement par le gestionnaire de messagerie de l'ensemble récepteur, envoi du contenu du fichier image compressé dans le corps du message.
L'invention propose également selon un second aspect un système de messagerie comprenant au moins un ensemble émetteur permettant de mettre en œuvre un procédé selon l'un des aspects ci-dessus.
D'autres aspects, buts et avantages de l'invention apparaîtront mieux à la lecture de la description suivante d'une forme de réalisation de l'invention, faite en référence aux dessins annexés sur lesquels, outre la figure 1 qui a déjà été commentée ci-dessus et dont le schéma général est également repris par l'invention :
• la figure 2 est une représentation schématique des étapes principales du procédé selon l'invention,
• la figure 3 est une représentation plus détaillée de certaines de ces étapes principales.
En référence à cette figure 2, un utilisateur émetteur procède tout d'abord à la création et à l'édition d'un fichier pour constituer un message original M, lors d'une étape 201.
Pour procéder à cette édition de message, l'utilisateur émetteur ne lance pas comme c'est le cas dans les systèmes connus l'exécution de son gestionnaire de messagerie.
Dans le cas de l'invention au contraire, l'utilisateur lance l'exécution d'une application d'édition de fichier original (traitement de texte ou autre), qui appellera comme on va le voir directement le gestionnaire de messagerie pour former un message à partir du fichier original en cours d'édition lors des étapes 202 et 203.
Ce logiciel d'édition de fichier peut également permettre l'appel d'autres applications (tableur, dessin, ...), ainsi que l'insertion de tous types d'objets graphiques dans le fichier en cours d'édition (photos, dessins, présentations...).
On nommera « fichier original » ce fichier en cours d'édition, et qui servira comme on va le voir de support au message qui sera envoyé. La Demanderesse a créé un système permettant à l'utilisateur émetteur d'actionner une commande - par exemple par l'intermédiaire d'un bouton ou d'un menu déroulant - ladite commande permettant de constituer directement un message avec l'image du fichier en cours d'édition. Plus précisément, une commande dédiée du système permet :
• d'acquérir au moins une image du fichier en cours d'édition (étape 202),
• puis de constituer avec l'image ou les images ainsi acquise(s) un message M' à l'aide du gestionnaire de messagerie de l'utilisateur émetteur (étape 203). A cet effet, la commande génère un appel automatique dudit gestionnaire de messagerie.
Il est possible de paramétrer le système selon l'invention pour que l'image ou les images acquise(s) du fichier en cours d'édition ai(en)t tout
type de format désiré (.gif, .jpeg ou autre), ledit format devant être compatible avec une transmission 7 bits selon un protocole SMTP sans dégradation de l'image.
Lors de l'étape 203, le gestionnaire de messagerie de l'ensemble émetteur convertit l'image ou les images qui a (ont) été acquise(s) du fichier en cours d'édition en un message M' encodé sur un mode 7 bits (par exemple par un encodage de type base64).
Du fait de sa compatibilité avec le protocole SMTP évoquée ci- dessus, aucune image acquise du fichier en cours d'édition n'est altérée par cette conversion.
Les étapes 202 et 203 seront décrites plus en détail plus loin dans ce texte en référence à la figure 3.
Le message converti M' ainsi constitué contient toutes les informations contenues lors de l'acquisition d'image (étape 202) dans le fichier que l'utilisateur émetteur éditait. Ces informations comprennent tous les objets insérés dans le fichier original.
Et selon un aspect avantageux de l'invention, l'aspect visuel dudit fichier au moment de l'acquisition d'image a également été préservé intégralement. Le message M' converti est ensuite transmis de manière connue en soi par une liaison L à un ensemble récepteur desservi par un serveur de courrier associé à un gestionnaire de messagerie de l'ensemble récepteur (serveur S de la figure 1 ).
Comme on l'a dit, le message M' a un format particulièrement simple et robuste (encodage 7bits d'une image de type .gif ou .jpeg par exemple). Il en résulte que :
• quel que soit le type de serveur de courrier (correspondant au serveur S de la figure 1 ) qui dessert l'ensemble récepteur,
• et quel que soit le type de gestionnaire de messagerie de cet ensemble récepteur,
les moyens d'édition dudit ensemble récepteur permettront à l'utilisateur récepteur de visualiser l'image correspondant exactement à l'aspect du fichier original édité par l'utilisateur émetteur, lors de l'acquisition d'image. Cet utilisateur recevra ainsi un message M" qui, à son ouverture par l'utilisateur récepteur pour consultation du message, provoquera l'affichage automatique de l'image acquise, par les moyens d'édition de l'ensemble récepteur.
On remarquera que comme exposé ci-dessus, le message envoyé selon l'invention est un message unique équivalent à une image, qui s'affiche automatiquement à réception.
Ceci constitue un avantage supplémentaire, par rapport à un message qui comporterait des images sous forme de pièces jointes comme cela est connu. En effet, dans le cas connu de l'envoi de pièces jointes, bien que certains gestionnaires de messagerie ouvrent automatiquement les pièces jointes (c'est le cas de la version 5 de Outlook et de la version 4.7 de Netscape par exemple - Outlook et Netscape sont des marques déposées), ce n'est pas le cas de tous les gestionnaires de messagerie.
Ainsi, dans la configuration connue où l'on envoie des pièces jointes, il est possible que lors de la réception du message et de son ouverture par l'utilisateur récepteur l'image correspondant au fichier de la pièce jointe ne s'ouvre pas, en fonction du type de gestionnaire de messagerie associé à l'ensemble récepteur.
Cet inconvénient est évité dans le cas de l'invention, ce qui est particulièrement avantageux lorsqu'il est désiré que l'utilisateur récepteur perçoive systématiquement le contenu visuel du message (cas de la diffusion d'informations commerciales ou promotionnelles par exemple).
En référence maintenant à la figure 3, on va détailler les opérations qui constituent les étapes principales 202 et 203 décrites ci-dessus, le déroulement de ces étapes étant déclenché par la commande dédiée du système évoquée ci-dessus.
Et la représentation schématique de la figure 3 est également complétée par l'insertion ci-après dans le corps du texte d'un listing
correspondant au code source d'une forme de réalisation d'un logiciel permettant de commander le déroulement de ces étapes.
L'étape principale 202 peut être décomposée en 4 étapes élémentaires 2021 à 2024. L'étape 2021 est une étape d'initialisation, lors de laquelle on sélectionne en particulier le format dans lequel on souhaite constituer des images à partir du fichier original.
Ce choix est effectué par l'intermédiaire d'un choix de codée. Dans le cas du listing inséré ci-dessous, le codée choisi est de type jpeg. En 2022, on procède ensuite à la détection des sauts de page dans le fichier original. On précise que les sauts de page peuvent avoir été constitués automatiquement par l'application à partir de laquelle le fichier original est édité, ou encore inséré par l'utilisateur émetteur en des endroits désirés. Après détection des sauts de page, le logiciel paramètre le nombre de pages (nb pages), qui correspondra au nombre d'images qui constitueront le message M' à transmettre.
On procède ensuite en 2023 à la création dans une zone de mémoire d'un tableau pour recevoir les adresses de mémorisation de chacun des fichiers correspondant à l'image d'une page du message M'.
On nommera chacun des ces fichiers « fichier page ».
Dans le cas où un tel tableau existe déjà suite à l'envoi d'un message précédent, le système effectue la remise à zéro de ce tableau, c'est-à-dire qu'il le vide des adresses qu'il contient. En 2024, on effectue une boucle sur le nombre de pages nb pages, en effectuant pour chaque page la succession des opérations suivantes :
• définition du nom de fichier page. Ce nom est calculé en incrémentant un indice correspondant au numéro de la page. Dans l'exemple de code source inséré ci-dessous, l'extension associée au nom de la page est en .jpg, correspondant au codée choisi lors de l'étape 2021 d'initialisation,
• définition d'une adresse de mémorisation pour le fichier page. Cette adresse pointe vers un espace de mémoire prédéfini correspondant à
un endroit désiré de mémorisation de l'ensemble émetteur. Cet espace de mémorisation peut par exemple être inclus dans un dossier de préférences de l'application,
• construction d'une image bitmap (par l'instruction « WR Construire Aperçu » dans l'exemple de code source présenté ci-dessous), et association à ce fichier image bitmap du nom de fichier page. A ce stade, le fichier bitmap de l'image de la page et son nom associé sont mémorisés en mémoire vive,
• envoi d'une instruction de supprimer dans l'espace de mémorisation prédéfini tout fichier ayant le même nom que le nom du fichier page défini ci-dessus,
• compression du fichier bitmap mémorisé en mémoire vive et création à l'adresse définie ci-dessus d'un « fichier page compressé » correspondant à l'image de la page, compressé de manière à ne pas occuper plus de 60 Kilooctets environ.
La boucle de l'étape 2024 est répétée pour toutes les pages du fichier original, de manière à mémoriser dans l'espace de mémoire prédéfini un fichier page compressé pour chaque page.
L'étape principale 203 peut quant à elle être décomposée en une étape élémentaire 2031 , suivie selon l'option choisie d'une étape 2032a ou
2032b.
L'étape 2031 comporte les opérations suivantes :
• appel du gestionnaire de messagerie de l'ensemble émetteur et d'un serveur SMTP auquel l'ensemble émetteur est relié, • déclaration auprès de ce serveur SMTP de l'ensemble émetteur. A cet effet, l'ensemble émetteur fournit au serveur SMTP son adresse IP,
• réception d'un numéro de session SMTP,
• création de l'en-tête du message M'.
L'option 2032a est sélectionnée si l'utilisateur émetteur a sélectionné pour l'envoi de son message le mode texte ; ceci correspond à une
utilisation très simplifiée du système selon l'invention qui ne prend pas en compte la possibilité de créer des images à partir du fichier original.
Cette option n'est pas utilisée dans le cadre de l'invention et ne sera pas détaillée dans ce texte. L'option 2032b correspond quant à elle au cas sélectionné par défaut lors de l'activation de la commande d'exécution des étapes principales 202 et 203 par l'utilisateur.
Cette option par défaut dans laquelle le fichier original est visualisé sous la forme d'une ou plusieurs images, est désignée dans l'exemple de code source inséré ci-dessous par la ligne « Mode Softlink PB ».
Cette étape 2032b comprend l'exécution d'une boucle pour toutes les pages, en effectuant pour chaque page les opérations suivantes :
• ouverture du fichier page compressé mémorisé dans l'espace de mémoire prédéfini, • insertion de l'en-tête de ce fichier page compressé dans le message M',
• déclaration de ce fichier compressé comme devant être ouvert automatiquement par le gestionnaire de messagerie récepteur. Cette disposition permet de différencier le message d'un message comprenant une image en pièce jointe. Elle est autorisée par l'utilisation de l'instruction « inline », qui a été définie par la société Qualcomm en juin 1995 dans le document « request for comments : 1806 ». On précise que la liste des « request for comments » (ou RFC), qui constituent des normes de programmation, est accessible à l'adresse ftp://ftp.isi.edu/in-notes/rfc-index.txt et que la dernière version des RFC peut être consultée à l'adresse: http://www.rfc-editor.org/ ,
• envoi du contenu du fichier image compressé dans le corps du message. On remarquera à cet égard que l'invention se démarque nettement de l'enseignement de US 6092104, qui ne divulgue que la possibilité d'attacher des fichiers images à un message de transmission : dans le cas de la présente invention, le fichier image compressé est réellement intégré dans l'entité « Message », de sorte
que le contenu dudit fichier image compressé est automatiquement affiché sur le poste du récepteur à réception dudit message.
Ces opérations sont répétées pour chaque image acquise pour le fichier original, de sorte que le message M' comprend la totalité de ces images, déclarée de manière à s'ouvrir directement lorsque l'utilisateur/récepteur ouvrira le message M" reçu.
L'extrait donné en annexe d'un code source illustre l'enchaînement des étapes décrit ci-dessus. On précise que cet exemple n'est donné qu'à titre illustratif, et ne représente nullement une limitation de l'invention. Cet exemple a été réalisé en utilisant les langages suivants (une adresse Internet est jointe ci-dessous pour accès aux spécifications de ces différents langages) :
• 4D version 6.5.7
• 4D Write 6.5.5 (spécifications sur le site http://www.4D.fr)
• QPix version 2.1.1
(spécifications sur le site http://www.escape.gr )
• ITK version 2.0.
(spécifications sur le site http://www.internet-toolkit.com/ ) Et on précise que l'exemple en annexe est donné afin d'illustrer la structure générale du logiciel permettant de mettre en œuvre le procédé selon l'invention.
Dans cet exemple, il est fait appel à une logique et à des fonctions développées spécifiquement, dont suit ci-dessous une description générale :
Variables Structurées et concept de propriétés "prp" :
Le mode de programmation retenu est l'utilisation d'un espace-mémoire dans lequel on stocke à la volée des informations requises au bon fonctionnement de l'application. L'ensemble des méthodes liées à ce concept est préfixé des trois lettres « prp ».
Comme dans tout système de mouvementation d'information nous retenons deux familles de méthodes : celles d'entrée "prp_set" et celle de sortie "prp_get".
Méthodes liées aux propriétés "prp" : [liste_propriétés]<- prp_set ([liste_propriétés];"propriété alpha";{valeur alpha de la propriété}) ; prp_set_long ([liste_propriétés];"propriété numérique entière";{valeur numérique entière de la propriété}) ; prp_set_time ([liste_propriétés];"propriété temps";{valeur temps de la propriété}) ; c prp_set_bool ([liste_propriétés];"propriété booléenne";{valeur booléenne de la propriété}) {valeur alpha} <- prp_get ([liste_propriétés];"propriété alpha")
{valeur numérique entière} prp_get_long ([liste_propriétés];"propriété numérique entière")
{valeur booléenne} prp_get_bool ([liste_propriétés];"propriété booléenne").
prp_disable ([liste_propriétés];"propriété booléenne") fixe à « faUX » la propriété, alors que
prp_enable ([liste_propriétés];"propriété booléenne") fixe à « Vrai » la propriété
Méthodes liées à l'interface utilisateur :
• BarberShop : Affiche une fenêtre montrant une animation ou la durée du temps d'exécution du traitement est indéfinie,
• pr_progression : Affiche une fenêtre montrant une animation ou la durée du temps d'exécution du traitement est connue,
• dlog_intl_alert : Affiche une fenêtre de message destinée à informer l'utilisateur.
Méthodes liées à la communication avec le serveur de messagerie :
• ITK_HELO_ : ouvre une session avec le serveur SMTP et identifie le compte,
• ITK_BYE_BYE_: ferme la session avec le serveur SMTP,
• ITK_CREATE_ : crée des entités de réception sur le serveur SMTP pour les destinataires du message,
• ITK_RELEASE_ : libère les entités de réception du serveur SMTP,
• ITK_CREATE_STD_ : génère les en-têtes standards de l'en-tête du message: "from: / to:/ subject:/ etc.",
• ITK_SEND_X_: envoi une série d'en-têtes personnalisées dans l'en-tête du mail exemple "X-gestionnaire de messagerie:",
• ITK_ADD_X_: permet d'envoyer une en-tête de description d'un fragment du contenu du message,
• ITK_START_ : informe le serveur SMTP que l'on sort de l'écriture de l'en-tête du message pour passer en mode contenu ITK_SEND_: envoie une partie du contenu du message,
• ITK_ADD_: envoie les éventuels fichiers joints au message,
• ITK_SEND_DATA_: envoie un fichier encodé au format base 64,
• ITK_SMTP_ERROR_: Affiche une fenêtre de message destinée à informer l'utilisateur qu'une erreur s'est produite pendant la communication avec le serveur de messagerie.
L'invention permet ainsi de transmettre de manière particulièrement simple et efficace des messages en garantissant que l'intégrité visuelle desdits messages est respectée par la transmission.
Ce résultat est obtenu sans nécessiter d'intervention sur le réseau lui-même, ou sur les ensembles récepteurs : en effet, il suffit pour mettre en œuvre l'invention d'installer sur les ensembles émetteurs une application correspondant à l'exemple ci-dessus, avec ses fonctions appelées.
Les messages reçus reproduisent exactement l'aspect graphique de l'édition d'un fichier original qui peut comporter tout élément graphique
désiré, combinant à volonté des éléments de texte, de photos, de dessin ayant chacun tout format désiré. Et l'agencement de ces éléments dans le fichier original est également conservé.
On remarquera en outre que l'invention permet de protéger la confidentialité des échanges de messages électroniques, car il est alors impossible à une personne mal intentionnée de scruter les échanges transitant par la liaison L pour détecter la présence de mots-clés, les textes étant « noyés » dans l'image transmise.
Un autre avantage de l'invention est que la transmission des messages est fiabilisée. En effet, dans le cas de la transmission de messages avec pièces jointes, il existe un danger de contamination de l'ensemble récepteur par un virus informatique à l'ouverture de la pièce jointe, en particulier si celle-ci est un fichier de type exécutable. Dans le cas de l'invention, il n'est pas nécessaire d'ouvrir une pièce jointe. Et l'invention permet également d'attester la date de transmission de certains éléments : du fait que l'image du fichier original qui est transmise est inaltérable, car le fichier source de cette image n'est pas transmis avec le message M', la réception d'un message équivaut strictement à la réception de l'image qui lui était associée. Cet aspect de l'invention peut être mis en œuvre par exemple dans des relations commerciales, pour attester de la date de réception de pièces telles qu'un bon de commande.
On notera toutefois qu'il est possible dans une variante de l'invention de joindre au message le fichier image dont le contenu est déjà transmis par le message lui-même, afin de permettre à l'utilisateur récepteur de manipuler et de traiter l'image.
Cette variante pourra être mise en œuvre par exemple dans le cas où on souhaite que les utilisateurs récepteurs puissent répondre à un questionnaire, envoyé en pièce jointe avec le message. Dans le cas où le fichier original serait de grande taille, l'acquisition d'image correspondant à l'étape 202 se fait en plusieurs images (par
exemple, chaque image correspond à une page du fichier original dans le cas où il s'agit d'un fichier de traitement de texte).
Et le message M' véhicule alors non pas une seule, mais une pluralité d'images. Ces images s'afficheront automatiquement à la suite les unes des autres lors de l'ouverture du message M" par l'utilisateur récepteur, de manière à reproduire l'aspect du fichier original.
Dans tous les cas, la compression effectuée sur le fichier page immédiatement après sa création permet de limiter la taille mémoire de l'image ou des images transmise(s) dans le message M' à une taille de l'ordre de 60 Kilooctets.
L'invention permet ainsi la transmission de messages de manière particulièrement avantageuse, sans pour autant alourdir la gestion du réseau mis en œuvre et risquer de le saturer.
ANNEXE
************************************************************************************** ** C_TEXTE ($0 ; $1)
C_P0INTEUR($2) ""pointeur sur le tableau de pièces jointes
$do essage: ≈Faux
$crlf: ≈Caractere (13) +Caractere (10)
$Guillemet:=prp_get (θPRP_PARSER; "Guillemet") $SaveError:=ITK_Send_ErrString
$Prp_Ptr:=Pointeur vers($l)
$Prp_Ptr-> : =prp_set ($Prp_Ptr->; "this" ; $1) $Prp_Ptr->:=prp_set ($Prp_Ptr->; "Master Prp";$l) ""chargerment du codée setting jpeg C_BLOB ($CodeσSetting) FIXER TAILLE BLOB ($CodecSetting; 0)
$PrefFilePath: ≈prp_gefc (OPREFERENCES; "Chemin fichier préférence") $PrefFolderPath:≈prp_ et (OPREFERENCES; "Chemin dossier préférence") $UseCodexSettings: ≈Faux
$Codec:="JPEG"
$Idx:≈Chercher dans tableau( Codec_Tpes; $Codec)
Si ($ldx>0)
$Codec : =0Codec_Types{$Idx} $resT pe: ="σodx"
$FileRef : ≈Ouvrir fichier ressources ($PrefFilePath) Si (OK=l)
LIRE RESSOURCE ($resType; OCodec_Settings_ResID{$Idx}; $CodecSetting; $FileRef) $UseCodexSettlngs:=(OK=l) & (Taille BLOB($CodecSetting) >1) FERMER FICHIER RESSOURCES ($FileRef)
Fin de si Fin de si
C TEXTE ($Buffer; $Tampon; $TexteB6 ) C_IMAGE ($image)
$zoτιe =prp__ τet_lonçτ ($Prp_Ptr->; "zone handle") Au cas ou
: (prp_g-etJbool ($Prp_Ptr->; "Mode texte")) Sinon
"construction des fichiers images $nbPages:=WR Compter ($zone; r nb pages ) TABLEAU TEXTE ($TabFilePath;0) TABLEAU TEXTE ($TabFilePath; $nbPages)
$Prp_Ptr->:=prp_disable ($Prp_Ptr->; "barber close") $BarberProc:=BarberShop ($1) Boucle ($i_page;l;$nbPages)
$doc_name: ="Page_"+Chaine ($i_page) +" . jpg"
$Prp_Ptr->:=prp_set ($Prp_Ptr->; "barber message" ; "Composition page
"+Chaine ($i_page) +"/"+Chaine ($nbPages) )
$docPath:≈$PrefFolderPath+$doc_name
$Picture:=WR Construire Aperçu ($zone; $i_page) "conversion vectorielle en bitmap
SUPPRIMER DOCUMENT ($docPath)
Au cas ou
: (Try_Catch )
: [TryJ atch (QPx_βxportPlcture ($Picture; $docPath;Majusc ( $Codec) ; $CodecSetting) ) ) TRACE dlog_intl_alert ( "Ooops" )
Sinon
$TabFilePat {$i_ρage} : =$docPath Fin de cas Fin de boucle
$Prp_Ptr->: =prp_enable ($Prp_Ptr->; "barber close") "il faut s'assurer que le barber est fermé
Tant que (prp_get_ ool ($Prp_Ptr->; "Barber running")) APPELER D Fin tant que Fin de cas
$smtp_ID : ≈ITK_HELO_SMTP (prp_get ($Prp_Ptr->; "SMTP SERVEUR") ;prp_ et ($Prp_Ptr->; "Mail From")) Si ($smtp_ID#0)
$Prp_Ptr-> : =prp_set_long ($Prp_Ptr->; "smtpID" ; $smtp_ID)
Si (ITK_CREATE_RECIPIENTS ($smtp_ID;prp_get ($Prp__Ptr->; "Mail From") ;prp_get ($Prp_Ptr->; "Mail To");prp_get ($Prp_Ptr->; "Mail Ce") ;prp_get ($Prp_Ptr->; "Mail Bec") ;prp_get_bool ($Prp_Ptr- >;"Send a copy"))) Si (ITK_CREATE_STD_HEADERS ($smtp_ID;prp_get ($Prp_Ptr->; "Mail From") ;prp_get ($Prp_Ptr- >;"Mail To");prp_get ($Prp_Ptr->; "Mail subject") ;prp_get ($Prp_Ptr->; "Mail Ce") ;prp_get_bool ($Prp_Ptr->; "Mail Read Reeept") ;prp_get ($Prp_Ptr->; "Mail Reply") ;prp_get ($Prp_Ptr->; "Mail Organization" ) ) ) on peut créer ses propres headers ITK_SEND_X_HEADERS ($smtp_ID)
Si (prp_get_bool ($Prp_Ptr->; "Mail X-Priority" ) )
ITK_ADD_X_HEADER ($smtp_ID; "X-Priority: 1") Fin de si "on envoi le contenu
Au cas ou
: (prp_gret_Jool ($Prp_Ptr->; "Mode texte"))
ITK_ADD_X_HEADER ($smtp__XD; «Content-Type: text/plaln; c arset≈ "+$Guillemet+"ISO-885S- l "+$Guillemet) ITK_ADD_X_HEADER ($smtp_ ID; " Content -trans£er-encoding: quoted-prlntable" )
$Nb: =WR Compter ($zone;wr nb caractères )
$start: =0
$OK: =Vrai
SI ( ITK_START_MESSAGE ($smtp_ID) ) Tant que ($start<$Nb) s ($OK) $stop: ≈$start+16000
$Buffer: =WR Lire texte ($zone; $start; $stop) $start : =$stop
$OK: =ITK_SEND_MESSAGE ( $smtp_ID;ITK_Text2QuOted ($Buf£er; 0) ) ~ISO-8859-l
Fin tant que Fin de si
"gestion des attachements
SI (Nombre de parametres>l)
ITK_ADD_ATTACHEMEm'S ( $smtp_ID; $Boundary; $2 ) Fin de si
Sinon "nous sommes dans le mode Softlin PB
$OK:≈Vrai
$Boundary:=Chaine(ITK_Date2Secs (Date du jour (*) ;Heure courante(*) ) ) ITK_ADD_X_βEADER ($smtp_ID; "Content-Type: multipart/mixed; boundary="+$Guillemet+$Boundary+$Guillemet) $Boundary:=("-"*2) +$Boundary
Si (XTK_START_MESSAGE ($smtp_ID) )
ITK_ADD_X_HEADER ($smtp_ID; $Boundary) ITK_ADD_X_HEADER ($smtp_ID; "Content-Type: text/plain; charset≈"+$Guillemet+"ISO-
8859-l"+$Guillemet)
ITK_ADD_X_HEADER ($smtp_ID; "Content-transfer-encoding: quoted-printable") ITK_ADD_X_ EADER ($Smtp_ID)
$Prp_Ptr->:=prp_set_long ($Prp_Ptr->; "progression min";0)
($Prp_Ptr->; "progression current";0)
$Prp_Ptr->:≈prpMSet_loιιg ($Prp_Ptr->; "progression max";100) $Prp_Ptr->:=prp_disaJble ($Prp_Ptr->; "progression autoelose") $progression_proe : =pr_j>rogression ($1) Boucle ($i_page;l;$nbPages) $Prp_Ptr- :≈prp_set_lon ($Prp_Ptr->; "progression min"; 0)
$Prp_Ptr->:=prp_set_longr ($Prp_Ptr->; "progression current";0) $Prp_Ptr->:=prp_set ($Prp_Ptr->; "progression message"; "Envoi de Mail page "+Chaine($i_page) +"/"+Chaine($nbPages) )
$Prp_Ptr-> : =prp_set_long ($Prp_Ptr->; "progression max";Taille document ($TabFilePath{$i_page}) )
$doc_name:="Page_"+Chaine($i_page)+" .jpg" $docRe :=0uvrir document ($TabFilePath{$i_page}) Si (OK≈l)
ITK_ADD_X_HEADER ($smtp_ID; $Boundar ) ITK_ADD_X_ EADER (§smtp_ID; "Content-Type: image/jpeg;Name
≈"+$Guillemet+$doc_name+$Guillemet+"; ")
ITK_ADD_X_HEADER ($smtp_ID; "Content-transfer-encoding: base64") ITK_ADD X_HEADER ($smtp_ID; "Content-Disposition: inline; filename="+$Guillemet+$doc_name+$Guillemet) ITK_ADD_X_HEADER ($smtp_ID)
$Prp_Ptr-> : -prp_set_tlme ($Prp_Ptr->; "doeRef'; $docRef)
$Prp_Ptr-> : =ITK_SEND_DATA_FII,E ($Prp_Ptr->)
FERMER DOCUMEN ($dθcRef)
SUPPRIMER DOCUMEN ($TabFilePath{$i_page})
$OK: =prp_ls_σk ($Prp_Ptr->) Si (Non($OK))
ITK_SMTP_ERROR_DLOG Fin de si Fin de si
Fin de boucle
$Prp_Ptr-> : =prp_ enable ($Prp_Ptr->; "progression autoclose")
Repeter
APPELER 4D Jusque (Statut du process($progression proc) ≈Détruit )
"gestion des attachements
Si (Nombre de parametres>l) ITK_ADD_ATTACHEMENTS ($smtp_ID; $Boundary; $2)
Fin de si
"Fermeture des parts du mail ITK__ADD_X tEADER ($smtp_ID,- $Boundary+" -- ")
Fin de si Fin de cas $doMessage : =$OK Fin de si
ITK_RELEASE_RECIPIENTS ($smtp_ID) ITK_BYE_BYE_SMTP ($smtp_ID) Sinon
ITK_BYE_BYE_SMTP ($smtp_ID) Fin de si
$0 : =prp_sefc_bool ($Prp_Ptr->; "OK" ; $doMessage) Fin de si ITK_Send_ErrString: =$SaveError
**************************************************************************************