WO2002057969A1 - Procede de creation et d'envoi de messages electroniques et systeme de messagerie associe - Google Patents

Procede de creation et d'envoi de messages electroniques et systeme de messagerie associe Download PDF

Info

Publication number
WO2002057969A1
WO2002057969A1 PCT/FR2002/000247 FR0200247W WO02057969A1 WO 2002057969 A1 WO2002057969 A1 WO 2002057969A1 FR 0200247 W FR0200247 W FR 0200247W WO 02057969 A1 WO02057969 A1 WO 02057969A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
file
image
page
prp
Prior art date
Application number
PCT/FR2002/000247
Other languages
English (en)
Inventor
Dominique Delahaye
Original Assignee
Pierre Bonnerre Soft Link
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pierre Bonnerre Soft Link filed Critical Pierre Bonnerre Soft Link
Publication of WO2002057969A1 publication Critical patent/WO2002057969A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06Message adaptation to terminal or network requirements
    • H04L51/066Format adaptation, e.g. format conversion or compression
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/107Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the present invention relates to a method for creating and sending electronic messages, and to an associated system.
  • E-mail systems are widely used today, for both personal and professional purposes. 5 They can be implemented in private networks (such as
  • Intranet or public (Internet network - World Wide Web for example).
  • Electronic messaging systems are a means of communication that allows information to be exchanged quickly.
  • Figure 1 schematically shows the means for transmitting an electronic message via a network. It shows a transmitter assembly 10 connected by a link L of the network to a
  • the transmitter assembly 10 associated with a transmitter user comprises means 11 for editing an original message M as well as means 12 for preparing the transmission of this message.
  • the transmitter assembly can be a computer, or any other type of device that can be connected to a network.
  • the means 11 can for example comprise various word processing and graphic processing software residing on a computer of the sending user.
  • the means 12 include a messaging program, and
  • the link L can implement any transmission means known per se, wired or not. As part of message transmission on the World network
  • message transmissions are usually done using the SMTP protocol (Simple Mail Transfer Protocol), the message data being encoded in a 7-bit mode.
  • SMTP Simple Mail Transfer Protocol
  • the link L is associated with a mail server S to which the receiver unit 20 is connected (as well as generally a plurality of other receiver units).
  • This server S operates according to a message distribution protocol, such as the POP protocol (Post Office Protocol) which makes it possible to manage the distribution of the converted messages M 'transmitted by the link L.
  • POP protocol Post Office Protocol
  • POP2 or POP3 which allow you to transmit messages not only in text mode, but also in the form of html (hypertext mark-up language) pages, an aspect to which we will return in this text.
  • the means described above make it possible to route a message M 'to the receiver assembly, in 7-bit encoded form.
  • This encoded message is received by a message manager 22 of the receiver unit 20, then transmitted by this message manager to editing means 21 of the receiver unit intended to reconstruct a message M ", which also corresponds to the message M sent by the transmitter.
  • the editing means 21 comprise an interface such as a screen, the interface generally being associated with software making it possible to edit the message M "in a form identical - or at least similar - to that which the original message had. correspondent M.
  • the first messaging systems made it possible to transmit messages which conveyed information in text mode, but whose formatting options were non-existent, or extremely limited.
  • Such a possibility is advantageous in many cases.
  • An example is the dissemination of commercial and / or promotional messages, in which it is thus possible to include the visual characteristics of a product or brand (logo, writing according to a very specific font, etc. .).
  • a widespread solution for creating original messages comprising a desired aspect thus consists in creating the original message M in the form of an html page. It is understood that for certain applications of the type of those mentioned above, it is important to maintain the visual integrity of the message transmitted.
  • the editing means of the receiving unit do not have the same graphic possibilities as the editing means of the sending unit, it is possible that certain elements or graphic options of the original message M are degraded in the message M "displayed by the receiving user. This will be the case when, for example, a font used to create the original message M (including in the form of an html page) is not available in the receiver assembly 20.
  • the editing means 22 of this receiver assembly will then generally automatically search for a “similar” font, according to criteria such as the spacing between successive characters, and use the “similar” font thus identified. in the receiver assembly 20 to edit the message M ".
  • Another known solution for creating original messages having a desired appearance consists in constituting image files of an original message having a desired appearance, said image files then being sent as attached parts of a transmission message, sent to a selected user. .
  • Document US 6092104 discloses an example of such a solution.
  • the mail server of the receiving assembly which is associated with the user receiving the transmission message, can here again compromise the correct display of the attachments on the recipient's station. It is indeed possible that the reception of the transmission message is not accompanied by the automatic opening of the attachments, so that the recipient receiving such a transmission message does not have direct access to the images.
  • An object of the invention is to allow messages to be transmitted via a messaging system having the general structure shown above, while ensuring that the visual integrity of the message is preserved.
  • the invention proposes, according to a first aspect, a method for creating and sending electronic messages from a transmitter assembly to a receiver assembly, the two assemblies being connected by a link of a network, each assembly being associated with a respective messaging manager, characterized in that the method comprises carrying out the following steps by the transmitter assembly:
  • the image acquisition step comprises: an initialization during which the image format in which one wishes to constitute images from the original file is selected, the detection of page breaks in the original file, for each page of the original file, the constitution of an image file corresponding to the page of the original file.
  • the invention also proposes, according to a second aspect, a messaging system comprising at least one transmitter assembly making it possible to implement a method according to one of the above aspects.
  • FIG. 2 is a schematic representation of the main steps of the method according to the invention, • Figure 3 is a more detailed representation of some of these main steps.
  • a sender user first of all creates and edits a file to constitute an original message M, during a step 201.
  • the user launches the execution of an original file editing application (word processor or other), which will call, as we will see directly, the messaging manager to form a message from the original file being edited in steps 202 and 203.
  • an original file editing application word processor or other
  • This file editing software can also allow the call of other applications (spreadsheet, drawing, %), as well as the insertion of all types of graphic objects in the file being edited (photos, drawings, presentations ).
  • the command generates an automatic call from said messaging manager.
  • the acquired image or images of the file being edited have all type of format desired (.gif, .jpeg or other), said format having to be compatible with a 7-bit transmission according to an SMTP protocol without image degradation.
  • the messaging manager of the sender assembly converts the image or images that have been acquired from the file being edited into a message M 'encoded in a mode 7 bits (for example by base64 encoding).
  • Steps 202 and 203 will be described in more detail later in this text with reference to FIG. 3.
  • the converted message M 'thus formed contains all the information contained during the image acquisition (step 202) in the file that the sending user was editing. This information includes all the objects inserted in the original file.
  • the visual appearance of said file at the time of image acquisition has also been fully preserved.
  • the converted message M ' is then transmitted in a manner known per se by a link L to a receiver assembly served by a mail server associated with a message manager of the receiver assembly (server S of FIG. 1).
  • the message M has a particularly simple and robust format (7-bit encoding of a .gif or .jpeg type image for example). It follows that :
  • the means for editing said receiver assembly will allow the receiving user to view the image corresponding exactly to the appearance of the original file edited by the sending user, during image acquisition. This user will thus receive a message M "which, when opened by the receiving user for consultation of the message, will cause the automatic display of the acquired image, by the editing means of the receiving assembly.
  • the message sent according to the invention is a single message equivalent to an image, which is automatically displayed on reception.
  • Figure 3 is also supplemented by the insertion below in the body of the text of a listing corresponding to the source code of an embodiment of software making it possible to control the progress of these steps.
  • Step 2021 is an initialization step, during which the format in which one wishes to constitute images from the original file is selected.
  • This address points to a predefined memory space corresponding to a desired location for storing the transmitter assembly.
  • This storage space can for example be included in a preferences folder of the application,
  • step 2024 is repeated for all the pages of the original file, so as to store in the predefined memory space a compressed page file for each page.
  • the main step 203 can be broken down into an elementary step 2031, followed according to the chosen option by a step 2032a or
  • Step 2031 includes the following operations:
  • Option 2032a is selected if the sending user has selected text mode for sending his message; this corresponds to a very simplified use of the system according to the invention which does not take into account the possibility of creating images from the original file.
  • the option 2032b corresponds to the case selected by default during the activation of the command to execute the main steps 202 and 203 by the user.
  • This step 2032b comprises the execution of a loop for all the pages, by performing the following operations for each page:
  • the selected programming mode is the use of a memory space in which information required for the proper functioning of the application is stored on the fly. All the methods linked to this concept are prefixed with the three letters "prp”. As in any information movement system we retain two families of methods: those of input "prp_set” and that of output "prp_get”.
  • prp_disable [list_properties]; "boolean property" sets the property to "fALSE", while
  • prp_enable [list_properties]; "boolean property" sets the property to "True”
  • pr_progression Displays a window showing an animation where the duration of the processing execution time is known
  • ITK_HELO_ opens a session with the SMTP server and identifies the account
  • ITK_BYE_BYE_ closes the session with the SMTP server
  • ITK_CREATE_ creates receiving entities on the SMTP server for the recipients of the message
  • ITK_RELEASE_ releases the receiving entities from the SMTP server
  • ITK_CREATE_STD_ generates the standard headers of the message header: "from: / to: / subject: / etc.”
  • ITK_SEND_X_ send a series of personalized headers in the header of the example mail "X-mail manager:"
  • ITK_ADD_X_ allows to send a description header of a fragment of the message content
  • ITK_START_ informs the SMTP server that we have left the writing of the message header to go into content mode ITK_SEND_: sends part of the content of the message
  • ITK_SEND_DATA_ sends a file encoded in base 64 format
  • ITK_SMTP_ERROR_ Displays a message window intended to inform the user that an error has occurred during communication with the mail server.
  • the invention thus makes it possible to transmit messages in a particularly simple and efficient manner while ensuring that the visual integrity of said messages is respected by the transmission.
  • the messages received reproduce exactly the graphic aspect of the edition of an original file which can include any graphic element desired, combining at will elements of text, photos, drawing each having any desired format. And the arrangement of these elements in the original file is also preserved.
  • the invention makes it possible to protect the confidentiality of the exchanges of electronic messages, since it is then impossible for a malicious person to scan the exchanges passing through the link L to detect the presence of keywords, the texts being "Drowned" in the transmitted image.
  • Another advantage of the invention is that the transmission of messages is made reliable. In fact, in the case of the transmission of messages with attachments, there is a danger of contamination of the receiver assembly by a computer virus when the attachment is opened, in particular if it is a file of type executable. In the case of the invention, it is not necessary to open an attachment. And the invention also makes it possible to attest the date of transmission of certain elements: the fact that the image of the original file which is transmitted is unalterable, since the source file of this image is not transmitted with the message M ', receiving a message is strictly equivalent to receiving the image associated with it.
  • This aspect of the invention can be implemented for example in commercial relations, to attest to the date of receipt of parts such as an order form.
  • the image acquisition corresponding to step 202 is done in several images (for example example, each image corresponds to a page of the original file in the case where it is a word processing file).
  • the message M 'then conveys not one, but a plurality of images. These images will be displayed automatically one after the other when the message M "is opened by the receiving user, so as to reproduce the appearance of the original file.
  • the compression performed on the page file immediately after its creation makes it possible to limit the memory size of the image or images transmitted in the message M 'to a size of the order of 60 kilobytes.
  • the invention thus allows the transmission of messages in a particularly advantageous manner, without weighing down the management of the network implemented and risking saturating it.
  • Prp_Ptr->: prp_set ($ Prp_Ptr->; “this”; $ 1)
  • $ Prp_Ptr ->: prp_set ($ Prp_Ptr->; "Master Prp”; $ l) "" loading the coded setting jpeg C_BLOB ($ Code ⁇ Setting) SET BLOB SIZE ($ CodecSetting; 0)
  • PrefFilePath ⁇ prp_gefc (OPREFERENCES; "Preference file path") $ PrefFolderPath: ⁇ prp_ and (OPREFERENCES; "Preference file path”) $ UseCodexSettings: ⁇ False
  • Prp_Ptr ->: prp_set ($ Prp_Ptr->;"barbermessage”;"Composition page "+ String ($ i_page) +" / "+ String ($ nbPages))
  • Prp_Ptr->: prp_set_long ($ Prp_Ptr->; "smtpID"; $ smtp_ID)
  • 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 ")
  • ITK_ADD_X_HEADER ($ smtp_ID; $ Boundary) ITK_ADD_X_HEADER ($ smtp_ID; "Content-Type: text / plain; charset ⁇ ” + $ Guillemet + "ISO-
  • ITK_ADD_X_HEADER ($ smtp_ID; "Content-transfer-encoding: quoted-printable")
  • ITK_ADD_X_ EADER ($ Smtp_ID)
  • Prp_Ptr ->: prp_set_long ($ Prp_Ptr->;"minprogress”; 0) ($ Prp_Ptr->;"progressioncurrent”; 0)
  • Prp_Ptr->: prp_set_long ($ Prp_Ptr->; "max progression”; Document size ($ TabFilePath ⁇ $ i_page ⁇ ))
  • $ doc_name: "Page _” + String ($ i_page) + ".jpg”
  • $ docRe: Open document ($ TabFilePath ⁇ $ i_page ⁇ ) If (OK ⁇ l)
  • ITK_ADD_X_HEADER ($ smtp_ID; $ Boundar)
  • ITK_ADD_X_ EADER ( ⁇ smtp_ID; "Content-Type: image / jpeg; Name
  • ITK_ADD_X_HEADER ($ smtp_ID; "Content-transfer-encoding: base64")
  • ITK_ADD_X_HEADER ($ smtp_ID)
  • ITK_RELEASE_RECIPIENTS ($ smtp_ID)
  • ITK_BYE_BYE_SMTP ($ smtp_ID)

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Data Mining & Analysis (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne 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. L'invention concerne également selon un deuxième aspect un système de messagerie destiné à la mise en oeuvre d'un procédé selon le procédé ci-dessous.

Description

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)
Figure imgf000023_0001
($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
**************************************************************************************

Claims

REVENDICATIONS
1. Procédé de création et d'envoi de messages électroniques (M') d'un ensemble émetteur (10) à un ensemble récepteur (20), les deux ensembles étant reliés par une liaison (L) d'un réseau, chaque ensemble étant associé à un gestionnaire de messagerie respectif (12, 22), 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 (202) d'au moins une image du fichier original en cours d'édition,
• constitution (203) du message (M') 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.
2. Procédé selon la revendication 1 , caractérisé en ce que l'intégration de chaque image au message se fait par l'intermédiaire d'une instruction de type « inline ».
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la liaison (L) est associée à un protocole de transmission de type SMTP.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que 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.
5. Procédé selon la revendication 4, caractérisé en ce que lors de la constitution d'un fichier image pour chaque page, on réalise les opérations suivantes :
• 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,
• construction d'une image bitmap dans la mémoire vive de l'ensemble émetteur,
• association à ce fichier image bitmap du nom de fichier page,
• 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é.
6. Procédé selon la revendication 4 ou 5, caractérisé en ce que l'étape de constitution de message comprend :
• 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 (M') du contenu d'un fichier correspondant à l'image de ladite page.
7. Procédé selon l'une des revendications 5 et 6, caractérisé en ce que lors de l'intégration au message (M') 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 (M'), • 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.
8. Système de messagerie comprenant au moins un ensemble émetteur (10) permettant de mettre en œuvre un procédé selon l'une des revendications précédentes.
PCT/FR2002/000247 2001-01-22 2002-01-22 Procede de creation et d'envoi de messages electroniques et systeme de messagerie associe WO2002057969A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0100802A FR2819965B1 (fr) 2001-01-22 2001-01-22 Procede de creation et d'envoi de messages electroniques et systeme de messagerie associe
FR01/00802 2001-01-22

Publications (1)

Publication Number Publication Date
WO2002057969A1 true WO2002057969A1 (fr) 2002-07-25

Family

ID=8859076

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/000247 WO2002057969A1 (fr) 2001-01-22 2002-01-22 Procede de creation et d'envoi de messages electroniques et systeme de messagerie associe

Country Status (2)

Country Link
FR (1) FR2819965B1 (fr)
WO (1) WO2002057969A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1544761A1 (fr) * 2003-12-17 2005-06-22 Axel Dr. Glanz Procédé et dispositif de génération et d'expédition d'une image graphique d'un document généré de manière électronique

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0801492A1 (fr) * 1996-04-12 1997-10-15 Matsushita Electric Industrial Co., Ltd. Système de courrier électronique
US6092104A (en) * 1998-07-22 2000-07-18 Circle Computer Resources, Inc. Method for transmitting a facsimile from a desktop computer by using electronic mail

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0801492A1 (fr) * 1996-04-12 1997-10-15 Matsushita Electric Industrial Co., Ltd. Système de courrier électronique
US6092104A (en) * 1998-07-22 2000-07-18 Circle Computer Resources, Inc. Method for transmitting a facsimile from a desktop computer by using electronic mail

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LASERVAULT UNIVERSAL SERVER ADDED FEATURES / BUG FIXES, 13 April 1999 (1999-04-13) - 29 March 2001 (2001-03-29), XP002182409, Retrieved from the Internet <URL:http://laservault.com/support/whatlvus.html> [retrieved on 20011109] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1544761A1 (fr) * 2003-12-17 2005-06-22 Axel Dr. Glanz Procédé et dispositif de génération et d'expédition d'une image graphique d'un document généré de manière électronique

Also Published As

Publication number Publication date
FR2819965A1 (fr) 2002-07-26
FR2819965B1 (fr) 2003-06-20

Similar Documents

Publication Publication Date Title
CA2567315C (fr) Protocole de messagerie pour traiter des messages avec des pieces jointes
RU2387088C2 (ru) Система и способ для обмена сообщениями, наделенными мультимедийными возможностями, с функцией публикации-и-отправки
US20040068545A1 (en) Displaying and working with email attachments
US20070255792A1 (en) Method and apparatus for an email gateway
US20010032246A1 (en) Method and system for creating and sending a video e-mail
WO2008104727A1 (fr) Procede d&#39;insertion d&#39;un contenu multimedia dans une communication informatisee par messagerie instantanee
US20110264751A1 (en) System and method for a video emailing service
US7853659B2 (en) Method for presenting personalized, voice printed messages from online digital devices to hosted services
KR20020004417A (ko) 비디오 메일 서비스 방법 및 시스템
EP2336967B1 (fr) Messagerie personnalisée sur encarts web.
WO2002057969A1 (fr) Procede de creation et d&#39;envoi de messages electroniques et systeme de messagerie associe
FR2866455A1 (fr) Procede de communication de messages multimedias entre des terminaux distants avec un agent de programmation
FR2866456A1 (fr) Procede et systeme pour fournir une application multimedia sur un terminal avec un agent de programmation
EP1501248B1 (fr) Système et procédé de messagerie électronique
CN101589588A (zh) 用于电子邮件网关的方法和装置
KR100353258B1 (ko) 전자 메일 서비스 장치 및 서비스 방법
EP1494153B1 (fr) Procédé de lancement d&#39;un opérateur de traitement d&#39;objets contenus dans un message multimédia et terminal de télécommunication associé
EP1057315A1 (fr) Systeme de consultation d&#39;un serveur de courrier electronique
KR100241358B1 (ko) 인터넷 메시지의 작성과 송수신 방법 및 그 장치
EP3476110A1 (fr) Procédé et dispositif de traitement d&#39;un objet multimédia
FR3096486A1 (fr) Aide à l’appréhension d’émotions suscitées lors de l’échange de messages textuels
Turner et al. A comprehensive architecture for continuous media e-mail on the Internet
Rhodes et al. Building and Parsing E-Mail
FR2866454A1 (fr) Procede pour gerer une communication de donnees numeriques entre une pluralite de terminaux avec des agents de programmation
WO2007144533A1 (fr) Procécé et systèm e de transm i ssi on de m essages électron i ques à consultati on li m i tée

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP