Brevet FR3017761A1 — publié le 20150821

Arrière-plan de l'invention L'invention se situe dans le domaine général des systèmes permettant aux entreprises de s'échanger des données applicatives. Elle concerne plus particulièrement une méthode permettant d'échanger des données sans saisie manuelle des données, ni à l'émission, ni à la réception. A ce jour, les seuls systèmes connus imposent le plus souvent que les systèmes des entreprises émettrice et réceptrice soient reliés par un réseau de communication. D'autres solutions, basées sur la reconnaissance optique, permettent également de reconnaître des caractères imprimés sur un document papier pour les enregistrer dans un système d'informations, mais de tels systèmes sont très peu évolutifs en ce qu'ils nécessitent un développement spécifique pour chaque type d'application de manière à prévoir dans le document, un format et/ou une position prédéfinie dans le document pour chacune des informations à transmettre. L'invention vise un système de communication de données qui ne présente pas ces inconvénients. Objet et résumé de l'invention Ainsi, et selon un premier aspect, l'invention concerne un procédé mis en oeuvre par un système émetteur pour envoyer des données à un 25 système récepteur. Ce procédé comporte : - une étape pour générer, en utilisant un pilote d'impression, un document imprimable ; - une étape de recherche d'une clef de recherche dans ce document imprimable ; 30 - une étape d'obtention des données à envoyer au système récepteur à partir de cette clef de recherche ; - une étape de génération d'une image codée représentative de ces données ; - une étape d'insertion de cette image codée dans le document 35 imprimable ; et - une étape d'envoi du document imprimable au système récepteur. Corrélativement, l'invention concerne aussi un système de communication comportant un pilote d'impression apte à générer un document imprimable et un moteur comportant : - des moyens pour rechercher une clef de recherche dans ledit document imprimable ; - des moyens pour obtenir des données à émettre à partir de la clef de recherche ; - des moyens pour générer une image codée représentative de ces données ; et - des moyens pour insérer l'image codée dans ledit document imprimable. Selon un deuxième aspect, l'invention vise aussi un procédé mis en oeuvre par un système récepteur pour recevoir des données émises par un système émetteur. Ce procédé comporte : - une étape de réception d'un document imprimable ; - une étape de lecture d'une image codée comprise dans le document imprimable pour obtenir les données ; et - une étape de mise de ces données et du document imprimable à disposition du système récepteur. Ainsi, et d'une façon générale, l'invention propose d'utiliser l'image codée comprise dans le document imprimable comme vecteur de transmission des données. De façon très avantageuse, du côté de l'utilisateur du système émetteur, l'utilisateur interagit avec le système au moyen d'un pilote d'impression, ce qui est particulièrement aisé. L'image codée est insérée automatiquement dans le document sans autre intervention de l'utilisateur. Au surplus, et de façon très avantageuse, les données envoyées par le système émetteur sont automatiquement sélectionnées en fonction d'une clef de recherche comprise elle-même dans le document de sorte qu'il existe un lien irréversible entre le document et le contenu de l'image codée. Le système selon l'invention offre une grande souplesse d'utilisation car il permet de véhiculer dans l'image codée tout type de données, de façon automatique, la seule limite étant que ces données soient indexées dans le système d'informations du système émetteur par la clef de recherche précitée. L'invention ne présume pas non plus de la façon dont le document est envoyé, la seule contrainte étant que le système récepteur comporte des moyens de lecture de l'image codée pour reconstituer les données envoyées par le système émetteur. Le document peut en particulier être imprimé et envoyé au format papier, la seule limite étant que la résolution de l'imprimante et du lecteur de l'image codée imprimée soit suffisante pour permettre une reconstruction des données fiable. Dans un mode particulier de réalisation, le document imprimable est au format PDF. Dans un mode particulier de réalisation, l'image codée est un QRCode (code matriciel à deux dimensions). Ce mode de réalisation de l'invention permet de véhiculer une quantité importante de données avec un codage robuste. Il est en particulièrement adapté pour communiquer des données de facturation. Selon le besoin, une entreprise peut utiliser un système d'émission seul, un système de réception seul et un système permettant l'émission de données et la réception de données. Par conséquent, l'invention vise aussi un système de communication comportant, en complément ou non des caractéristiques du premier système de communication présenté ci-dessus: - des moyens de lecture d'une image codée comprise un document imprimable pour obtenir des données reçues ; et - des moyens pour mettre les données et le document imprimable à disposition dudit système. Dans un mode particulier de réalisation, le procédé d'envoi de données selon l'invention comporte en outre : - une étape d'obtention, grâce à la clef de recherche, de données source 25 selon un format propre au système émetteur en interrogeant une base de données du système émetteur ; - une étape de codage desdites données source selon un format générique de transport pour obtenir les données envoyées au système récepteur. 30 De même, dans un mode particulier de réalisation du procédé de réception selon l'invention, dans lequel les données échangées sont conformes à un format générique de transport, ce procédé de réception comporte une étape de transcodage de ces données selon un format propre au système récepteur. 35 Corrélativement, dans un mode de réalisation, le système de communication selon l'invention comporte des moyens pour transcoder les 3 0 1 7 76 1 4 données reçues et les données à émettre selon un format propre à ce système et vice versa. Ce mode de réalisation de l'invention est très avantageux car il permet de faire communiquer des systèmes hétérogènes, c'est-à-dire avec 5 des systèmes dans lesquels les données sont mémorisées selon des formats propriétaires. L'invention permet en particulier d'échanger des informations entre deux systèmes hétérogènes, sans saisie manuelle, avec un format papier. Dans un mode particulier de réalisation, les données sont signées 10 par l'émetteur avec une clef publique du système récepteur avant de générer l'image codée (par exemple le QRCode) décryptées par le récepteur (après lecture de ce QRCode) avec une clef privée de ce système récepteur. Ce mode de réalisation permet de garantir que les données 15 communiquées par le système émetteur ne peuvent être comprises que par le système récepteur. Ce couple clef publique / clef privé peut en outre être propre au type de données. Dans un mode préféré de réalisation détaillé ci-après, l'invention est implémenté, tant au niveau du système émetteur que du système 20 récepteur sous forme modulaire. A cet effet, le système émetteur utilise un moteur de transmission générique, et le système récepteur un moteur de réception générique. Dans ce mode de réalisation, les données envoyées au système récepteur comportent préférentiellement un code représentatif du type de 25 ces données. Préférentiellement, le pilote d'impression utilisé par l'opérateur du système émetteur est sélectionné automatiquement en fonction du type de données. On peut par exemple prévoir un pilote spécifique pour envoyer des données de facturation, un pilote spécifique pour envoyer des 30 données d'identité bancaire ... Dans ce mode de réalisation, le moteur générique de transmission utilise une méthode, sélectionnée en fonction du type de données, pour rechercher la clef de recherche dans ledit document imprimable. 35 3 0 1 7 76 1 5 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout 5 caractère limitatif. Sur ces figures : - la figure 1 représente plusieurs systèmes de communication conformes à l'invention reliés par un réseau de télécommunication ; la figure 2 représente différents formats de données pouvant être utilisés dans un mode particulier de réalisation de l'invention ; 10 la figure 3 représente des tables de codage et de décodage pouvant être utilisées dans un mode particulier de réalisation de l'invention ; la figure 4 représente des pilotes d'impression pouvant être utilisés dans un mode particulier de réalisation de l'invention ; 15 - la figure 5 représente, sous forme d'organigramme, les principales étapes d'un procédé d'envoi de données conforme à un mode particulier de réalisation de l'invention ; - la figure 6 représente, sous forme d'organigramme, les principales étapes d'un procédé de réception de données conforme à un mode 20 particulier de réalisation de l'invention ; et les figures 7A et 7B représentent un exemple de document pouvant être utilisé dans un mode particulier de réalisation de l'invention avant et après insertion de l'image codée. Description détaillée d'un mode de réalisation de l'invention En référence à la figure 1, on considère, dans cet exemple une entreprise X qui souhaite pouvoir communiquer des données de facturation à une entreprise Y et des données d'informations bancaires à une entreprise Z. Dans cet exemple, l'entreprise X souhaite aussi pouvoir recevoir des données de facturation d'une entreprise W. L'entreprise X utilise un logiciel de facturation LFX qui accède à une base de données de facturation BDFX et un logiciel de gestion d'informations bancaires LGIBX qui accède à une base de données d'informations bancaires BDIBX. Dans la base de données de facturation BDFX, les données de facturation sont enregistrées selon un format FFX. 3 0 1 7 76 1 6 Dans la base de données d'informations bancaires BDIBX, les données d'informations bancaires sont enregistrées selon un format FIBX. L'entreprise Y utilise un logiciel de facturation LFY qui accède à une base de données de facturation BDFY. Dans la base de données de 5 facturation BDFY, les données de facturation sont enregistrées selon un format FFY. L'entreprise Z utilise un logiciel de gestion d'informations bancaires LGIBZ qui accède à une base de données d'informations bancaires BDIBZ. Dans la base de données d'informations bancaires BDIBZ, les données 10 d'informations bancaires sont enregistrées selon un format FIBZ. L'entreprise W utilise un logiciel de facturation LFW qui accède à une base de données de facturation BDFW. Dans la base de données de facturation BDFW, les données de facturation sont enregistrées selon un format FFW. 15 Les entreprises X et W étant susceptibles de transmettre des données, leurs systèmes de communication SX, SW comportent un moteur générique de transmission MT conforme à l'invention. Chacun des logiciels LFX, LGIBX, LFW est associé à une API (respectivement APIFX, APIGIBX, APIFW) apte à identifier, sur réception 20 d'une clef de recherche reçue du moteur de transmission MT, les données à renvoyer à ce moteur de transmission. Les entreprises X, Y et Z étant susceptibles de recevoir des données, leurs systèmes de communication SX, SY et SZ comportent un moteur générique de réception MR conforme à l'invention. 25 Par ailleurs, le système de communication d'une entreprise ayant besoin de transmettre des données d'un certain type (données de facturation ou données d'informations bancaires) comporte un pilote d'imprimante virtuel propre à ce type de données. Par conséquent, dans cet exemple, le système de communication 30 SX de l'entreprise X et le système de communication SW de l'entreprise W comportent un pilote d'imprimante virtuel PF pour transmettre des données de facturation. Le système de communication SX de l'entreprise X comporte en outre un pilote d'imprimante virtuel PIB pour transmettre des données d'informations bancaires. 35 Conformément à l'invention, chaque type de données est transporté selon un format générique de transport propre à ce type. On notera FF le 3 0 1 7 76 1 7 format générique de transport des données de facturation et FIB le format générique de transport des données d'informations bancaires. Le système de communication de chaque entreprise susceptible d'envoyer des données d'un certain type, comporte une table de codage 5 pour coder les données de ce type au format utilisé par cette entreprise conformément au format générique de transport des données de ce type. De même, le système de communication de chaque entreprise susceptible de recevoir des données d'un certain type comporte une table de décodage pour décoder les données reçues selon le format générique 10 de transport des données de ce type conformément au format utilisé par cette entreprise pour ce type de données. Par conséquent, le système SX de l'entreprise X comporte : - une table de codage TCFX pour coder les données de facturation au format FFX de l'entreprise X selon le format générique de transport de 15 données de facturation FF ; - une table de codage TCIBX pour coder les données d'information bancaires au format FIBX de l'entreprise X selon le format générique de transport de données d'information bancaire FIB ; et - une table de décodage TDFX pour décoder des données de facturation 20 reçues conformes au format générique de transport de données de facturation FF selon le format FFX de l'entreprise X. Le système SY de l'entreprise Y comporte une table de décodage TDFY pour décoder des données de facturation reçues conformes au format générique de transport de données de facturation FF selon le 25 format FFY de l'entreprise Y. Le système SZ de l'entreprise Z comporte une table de décodage TDIBZ pour décoder des données d'informations bancaires reçues conformes au format générique de transport de données d'informations bancaires FIB selon le format FIBZ de l'entreprise Z. 30 Le système SW de l'entreprise W comporte une table de codage TCFW pour coder les données de facturation au format FFW de l'entreprise W selon le format générique de transport de données de facturation FF. A titre d'exemple, en référence à la figure 2, on représente : 35 - le format générique FF de transport de données de facturation ; - le format FFX des données de facturation de l'entreprise X ; et 3 0 1 7 76 1 8 le format FFY des données de facturation de l'entreprise Y. Dans cet exemple : le format générique FF de transport de données de facturation comporte, dans cet ordre, un code EV_F correspondant au type 5 « Données de facturation » puis, dans cet exemple une série de six champs, à savoir un montant hors-taxe HT, une taxe TVA, un montant toute taxe comprise TTC, un numéro de client CLT, un code opération COP et un numéro de facture NFAC; le format FFX des données de facturation de l'entreprise X 10 comporte, dans cet ordre, un code opération COP, un montant hors-taxe HT, un montant toute taxe comprise TTC, un numéro de client CLT et un numéro de facture NFAC ; et le format FFY des données de facturation de l'entreprise Y comporte, dans cet ordre, un numéro de facture NFAC, un numéro 15 de client CLT, un montant toute taxe comprise TTC et un montant hors-taxe HT. La figure 3 représente la table de codage TCFX pour coder les données de facturation au format FFX de l'entreprise X selon le format générique FF de transport de données de facturation et la table de 20 décodage TDFY pour décoder les données de facturation reçues conformes au format générique FF de transport de données de facturation selon le format FFY de l'entreprise Y. Chacune de ces tables comporte un champ comporte le code EV_F correspondant au type « Données de facturation » puis une série de 25 champs comportant autant de champs que le format générique FF de transport de données de facturation. Dans la table de codage TCFX, le nième champ de la série comporte, le cas échéant, le rang, dans le format générique FF de transport, du nième champ du format propriétaire FFX. Ainsi, le premier 30 champ de la série de six champs de la table TCFX comporte la valeur 2 correspondant au rang dans le format FFX du 1er champ du format générique FF de transport (valeur hors taxe HT). Dans la table de décodage TDFY, le nième champ de la série comporte, le cas échéant, le rang, dans le format générique FF de 35 transport, du nième champ du format propriétaire FFY. Ainsi, le quatrième champ de la série de six champs de la table TDFY comporte la valeur 2 3 0 1 7 7 6 1 9 correspondant au rang dans le format FFY du 4ème champ du format générique FF de transport (code client CLT). La figure 4 représente schématiquement les pilotes d'imprimantes virtuelles PF et PIB. Chacun de ces pilotes comporte un module GPDF de 5 génération de document PDF et le code correspondant au type de données qu'il permet de transmettre, à savoir le code EV_F pour les données de facturation et le code EV_IB pour les données d'informations bancaires. En référence à la figure 5, nous allons maintenant décrire comment 10 un employé de l'entreprise X peut envoyer des données de facturation à l'entreprise Y. Au cours d'une étape E10, un employé de l'entreprise X utilise le logiciel de facturation LFX pour générer une facture et enregistre les données de facturation de cette facture dans la base de données BDFX au 15 format FFX au cours d'une étape E15. Au cours d'une étape E20, l'employé sélectionne le pilote d'imprimante virtuelle PF pour transmettre les données de facturation de cette facture. Le générateur de document PDF de l'imprimante virtuelle PF génère alors une facture PDF représentée à la figure 7A, cette facture 20 comportant la clef de recherche utilisée par l'API APIFX du logiciel de facturation LFX pour identifier les données bancaires à transmettre. Dans cet exemple, la clef de recherche est constituée par le numéro de facture N FAC. Au cours d'une étape E30 le pilote d'imprimante virtuelle PF appelle 25 le moteur générique de transmission MT en lui passant en paramètres le code EV_F et la facture au format PDF. Le moteur générique de transmission MT comporte un module, sélectionné en fonction du code EV_F, pour rechercher, au cours d'une étape E40, dans la facture au format PDF, la clef de recherche NFAC. 30 Le moteur générique de transmission MT envoie cette clef de recherche NFAC à l'API APIFX du logiciel de facturation LFX au cours d'une étape E50 pour que cette API identifie, dans la base de données BDFX, les données de facturation à transmettre. Le moteur générique de transmission MT reçoit ces données au 35 cours d'une étape E60. Elles sont conformes au format FFX utilisé par le logiciel de facturation LFX, déjà décrit en référence à la figure 2. Dans le 3 0 1 7 7 6 1 10 mode de réalisation décrit ici, le moteur de transmission MT vérifie que ces données reçues sont correctes. Le moteur générique de transmission MT utilise, au cours d'une étape E70, la table de codage TCFX pour transcoder les données reçues 5 au format FFX selon le format FF générique de transport. Conformément à l'invention, ce format générique de transport MT comporte le code EV_F représentatif du type « Données de facturation ». Au cours d'une étape E80, le moteur générique de transmission MT signe les données au format générique de transport FF (à savoir le code 10 EV_F et les données de facturation de l'entreprise X) avec une clef publique de l'entreprise Y propre au type « Données de facturation ». De façon connue, la signature d'un ensemble de données obtenue avec une clef publique est un mot crypté qui ne peut être décrypté que par l'entité possédant la clef privée complémentaire de cette clef publique. 15 Au cours de la même étape E80 le moteur générique de transmission MT génère un QRcode représentatif de cette signature. Au cours d'une étape E90, le moteur générique de transmission MT insère le QRCode dans le document PDF, maintenant représenté à la figure 7B. 20 Le document PDF contenant le QRCode peut être envoyé à l'entreprise Y par tous moyens (étape E100). En référence à la figure 6, nous allons maintenant décrire le traitement effectué an niveau de l'entreprise Y sur réception de ce document PDF. 25 Le document PDF est reçu par le moteur générique de réception MR de l'entreprise Y au cours d'une étape F10. Au cours d'une étape F20, le moteur générique de réception MR lit le QRCode du document PDF pour reconstruire la signature générée par le moteur générique de transmission MT à l'étape E80. 30 Cette étape de lecture du QRCode peut être effectuée au moyen d'un lecteur de QRCode si le document est reçu au format papier ou par un module du système récepteur si le QRCode est reçu au format électronique. En pratique, si le document PDF est reçu sous version électronique, ce module est en mesure de retrouver le QRCode dans le 35 document PDF. Si le document est reçu sous format papier, ce document papier est numérisé au format JPEG et le QRCode est retrouvé dans le document JPEG. Au cours d'une étape F30, le moteur générique de réception MR utilise une clef privée complémentaire de la clef publique utilisée à l'étape E80 pour décrypter la signature et obtenir les données de transport au format générique de transport ainsi que le code EV_F représentatif du type « Données de facturation ». Au cours d'une étape F40, le moteur générique de réception MR utilise la table TDFY pour transcoder les données reçues au format FF selon le format FFY utilisé par l'entreprise Y. Les données de facturation de l'entreprise X, transcodées au format de l'entreprise Y, et le document PDF comportant le QRCode sont ainsi mis à disposition de l'entreprise Y au cours d'une étape F50. Ces données peuvent alors être mémorisées dans la base de 15 données BDFY au cours d'une étape F60, soit directement soit via une API du logiciel de facturation LFY. Le document PDF peut être sauvegardé dans le système d'informations de l'entreprise Y. REVENDICATIONS1. Procédé mis en oeuvre par un système émetteur (SX) pour envoyer des données (FF) à un système récepteur (SY), ce procédé comportant : - une étape (E20) pour générer, en utilisant un pilote d'impression (PF), un document imprimable (FAC) ; 10 - une étape (E40) de recherche d'une clef de recherche (NFAC) dans ledit document imprimable (FAC) ; - une étape (E60) d'obtention desdites données à partir de ladite clef de recherche (NFAC) ; - une étape (E80) de génération d'une image codée représentative 15 desdites données ; - une étape (E90) d'insertion de ladite image codée dans ledit document imprimable (FAC) ; et - une étape (E100) d'envoi dudit document imprimable (FAC) au système récepteur (SY). 20 2. Procédé d'envoi de données selon la revendication 1, caractérisé en ce qu'il comporte : - une étape (E60) d'obtention, grâce à ladite clef de recherche (NFAC), de données source selon un format propre (FFX) au système émetteur (SX) 25 en interrogeant une base de données (BDFX) du système émetteur (SX) ; - une étape de codage desdites données source selon un format générique de transport pour obtenir lesdites données envoyées audit système récepteur (SY). 3. Procédé d'envoi de données selon la revendication 1 ou 2, caractérisé en ce que lesdites données sont signées avec une clef publique dudit système récepteur (SY). 4. Procédé d'envoi selon l'une quelconque des revendications 1 à 35 3, caractérisé en ce que lesdites données envoyées au système récepteur (SY) comportent un code (EV_F) représentatif du type desdites données. 3 0 1 7 7 6 1 13 5. Procédé d'envoi selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit pilote d'impression est sélectionné en fonction du type desdites données. 6. Procédé d'envoi selon l'une quelconque des revendications 1 à 5, caractérisé en ce que la méthode mise en oeuvre pour rechercher la clef de recherche (NFAC) dans ledit document imprimable (FAC) est sélectionnée en fonction du type desdites données. 7. Procédé mis en oeuvre par un système récepteur (SY) pour recevoir des données (FF) émises par un système émetteur (SX), ce procédé comportant : - une étape (F10) de réception d'un document imprimable (FAC) ; 15 - une étape (F20) de lecture d'une image codée comprise dans ledit document imprimable (FAC) pour obtenir lesdites données ; et - une étape (F50) de mise desdites données et dudit document imprimable à disposition dudit système récepteur. 20 8. Procédé de réception selon la revendication 7, dans lequel lesdites données sont conformes à un format générique de transport, caractérisé en ce qu'il comporte une étape (F40) de transcodage desdites données selon un format propre audit système récepteur. 25 9. Procédé de réception selon la revendication 7 ou 8, caractérisé en ce qu'il comporte une étape (F30) de décryptage, avec une clef privée dudit système récepteur (SY), d'une signature représentée par ladite image codée pour obtenir lesdites données. 30 10. Système de communication comportant un pilote d'impression (PF) apte à générer un document imprimable (FAC) et un moteur (MT) comportant : - des moyens pour rechercher une clef de recherche (NFAC) dans ledit document imprimable (FAC) ; 35 - des moyens pour obtenir des données à émettre (FF) à partir de ladite clef de recherche (NFAC) ; 3 0 1 7 7 6 1 14 - des moyens pour générer une image codée représentative desdites données ; et - des moyens pour insérer ladite image codée dans ledit document imprimable (FAC). 5 11. Système de communication comportant : - des moyens de lecture d'une image codée comprise un document imprimable (FAC) pour obtenir des données reçues ; et - des moyens pour mettre lesdites données et ledit document imprimable 10 à disposition dudit système. 12. Système de communication selon la revendication 10 comportant : - des moyens de lecture d'une image codée comprise un document 15 imprimable (FAC) pour obtenir des données reçues ; et - des moyens pour mettre lesdites données et ledit document imprimable à disposition dudit système. 13. Système de communication selon l'une quelconque des 20 revendication 10 à 12 dans lequel lesdites données reçues et/ou lesdites données à émettre sont conformes à un format générique de transport, ledit système étant caractérisé en ce qu'il comporte des moyens pour transcoder lesdites données reçues et lesdites données à émettre selon un format propre audit système et vice versa. 25