FR3069075A1 - Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees - Google Patents

Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees Download PDF

Info

Publication number
FR3069075A1
FR3069075A1 FR1756717A FR1756717A FR3069075A1 FR 3069075 A1 FR3069075 A1 FR 3069075A1 FR 1756717 A FR1756717 A FR 1756717A FR 1756717 A FR1756717 A FR 1756717A FR 3069075 A1 FR3069075 A1 FR 3069075A1
Authority
FR
France
Prior art keywords
file
processing device
message
data
keys
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
FR1756717A
Other languages
English (en)
Other versions
FR3069075B1 (fr
Inventor
Eduardo Rafael Lopez Ruiz
Nicolas Guillon
Paul Krion
Jurgen Oesterle
Martin Stammler
Martin Kuhn
Sebastian Bildner
Thomas Stark
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
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
Priority to FR1756717A priority Critical patent/FR3069075B1/fr
Application filed by Amadeus SAS filed Critical Amadeus SAS
Priority to NZ760613A priority patent/NZ760613B2/en
Priority to CN201880053503.1A priority patent/CN110999264B/zh
Priority to PCT/EP2018/068373 priority patent/WO2019011804A1/fr
Priority to AU2018299826A priority patent/AU2018299826B2/en
Priority to US16/629,464 priority patent/US11436192B2/en
Priority to EP18734843.8A priority patent/EP3652917B1/fr
Publication of FR3069075A1 publication Critical patent/FR3069075A1/fr
Application granted granted Critical
Publication of FR3069075B1 publication Critical patent/FR3069075B1/fr
Priority to US17/872,061 priority patent/US11736587B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1865—Transactional file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/174—Form filling; Merging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/08—Annexed information, e.g. attachments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V30/00—Character recognition; Recognising digital ink; Document-oriented image-based pattern recognition
    • G06V30/10—Character recognition

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Strategic Management (AREA)
  • Databases & Information Systems (AREA)
  • Accounting & Taxation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Human Computer Interaction (AREA)
  • Operations Research (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Technology Law (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Les modes de réalisation de l'invention fournissent un système pour intégrer du contenu de message dans un dispositif de traitement cible (2), ledit dispositif de traitement de données cible (2) étant configuré pour traiter une donnée d'entrée ayant une structure de donnée prédéfinie, le système comprenant un serveur de messagerie (11) configuré pour recevoir un message provenant d'un dispositif client de messagerie (14) qui exécute une application de messagerie (15), le message comprenant le contenu du message. dans lequel le système comprend par ailleurs un dispositif orchestrateur (18) configuré pour intégrer au moins une partie du contenu du message dans un dispositif de traitement de données cible (2), le dispositif orchestrateur (18) étant par ailleurs configuré pour : - recevoir la partie du contenu de message du serveur de messagerie (1) ; et - transmettre un fichier déterminé de la partie de contenu de message vers un dispositif de traitement de fichier (19), le dispositif de traitement de fichier étant configuré pour transformer chaque fichier reçu (190) en un fichier de description (191) comprenant un ensemble de clés prédéfinies, aux moins certaines des clés étant associées à une ou plusieurs valeurs, le dispositif orchestrateur (18) étant configuré pour déterminer un fichier d'entrée (190) ayant la structure de donnée prédéfinie à partir du fichier de description (191) et pour transmettre le fichier d'entrée déterminé (182) vers le dispositif de traitement de données cible (2) pour traitement du fichier d'entrée déterminé par le dispositif de traitement cible.

Description

SYSTÈME ET PROCÉDÉ POUR INTÉGRER DU CONTENU
DE MESSAGE DANS UN DISPOSITIF CIBLE DE TRAITEMENT DE DONNÉES
CONTEXTE
L’invention concerne de façon générale des systèmes de messagerie, et en particulier des procédés, des systèmes et des produits-programmes d’ordinateur pour intégrer du contenu de message dans un dispositif de traitement de données cible.
Dans les systèmes de messagerie conventionnelle, un utilisateur peut avoir besoin de saisir des données non structurées concernant un élément commun, par exemple des factures numériques ou électroniques concernant des frais, vers un dispositif de traitement de données cible relatif à un domaine d’application dédié, tel qu'un système de rapport de frais ; le dispositif de traitement de données cible traite ensuite les données saisies par l’utilisateur et si les données saisies et les reçus sont en conformité, le système de rapport de frais génère un rapport de frais pour un ou plusieurs reçus fournis par un utilisateur pour traitement.
Dans certains cas, l’utilisateur peut se connecter directement au dispositif de traitement de données cible via une interface dédiée pour remplir manuellement un formulaire pour chaque opération ou transaction (p. ex. un voyage d’affaires), dans lequel il doit entrer l’information contenue dans des reçus ou des factures.
Ce type d’interaction est fastidieux, chronophage et source d’erreurs (erreurs typographiques, etc.) pour l’utilisateur. Par ailleurs, elles peuvent générer des informations erronées ce qui oblige l’utilisateur à vérifier le formulaire ou même les données saisies à nouveau. De plus, lorsque ces interactions sont manuelles, elles sont aussi limitées en matière de quantité ou de richesse d’information collectée.
Par conséquent, il existe un besoin pour des systèmes, procédés et produitsprogrammes d’ordinateur améliorés permettant d’intégrer un contenu dans un dispositif de traitement de données cible.
RÉSUMÉ
Dans le but de traiter ces problèmes et d’autres problèmes, un système pour intégrer du contenu de message dans un dispositif cible de traitement est fourni, le dispositif de traitement de données cible étant configuré pour traiter des données entrées ayant une structure de donnée prédéfinie, le système comprenant un serveur de messagerie configuré pour recevoir un message d’un dispositif client de messagerie qui exécute une application de messagerie, le message comprenant le contenu du message. Le système comprend par ailleurs un dispositif orchestrateur configuré pour intégrer au moins une partie du contenu du message dans un dispositif de traitement de données cible, le dispositif orchestrateur étant par ailleurs configuré pour :
- recevoir la partie du contenu de message du serveur de messagerie ; et
- transmettre un fichier déterminé à partir de la partie de contenu de message vers un dispositif de traitement de fichier, le dispositif de traitement de fichier étant configuré pour transformer chaque fichier reçu en un fichier de description comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, le dispositif orchestrateur étant configuré pour déterminer un fichier d’entrée ayant la structure de donnée prédéfinie à partir du fichier de description et pour transmettre le fichier d’entrée déterminé au dispositif de traitement de données cible.
Dans un mode de réalisation, le dispositif orchestrateur est connecté au serveur de messagerie selon un premier protocole de communication, et/ou à l’application de messagerie selon un second protocole, et/ou au dispositif de traitement de données cible selon un troisième protocole de communication.
L’application de messagerie peut comprendre une interface d’application et une extension d’application configurée pour générer un rendu de fichier d’entrée déterminé à partir du fichier de description fourni par le dispositif de traitement de fichier dans une zone dédiée de l’interface d’application.
Le dispositif de traitement de fichier peut être configuré pour mapper un ou plusieurs éléments de donnée de ladite partie du contenu de message au moins sous forme de clés d’un ensemble prédéfini de clés, le dispositif de traitement de fichier étant configuré pour générer le fichier de description de la partie du contenu de message comprenant ledit ensemble de clés prédéfinies, ladite une ou plusieurs valeurs associées aux clés du fichier de description étant déterminées à partir des éléments de données qui y sont mappés.
Le dispositif de traitement de fichier peut être par ailleurs configuré pour déterminer des ensembles de données de positionnement à partir du fichier reçu du dispositif orchestrateur, chaque ensemble de données de positionnement identifiant la position d’un élément de donnée du fichier mappant une clé de l’ensemble prédéfini de clés, chaque ensemble de données de positionnement étant inclus dans le fichier de description associé à la clé mappée à l’élément de donnée.
Chaque ensemble de données de positionnement peut comprendre les coordonnées de positionnement dans un référentiel donné.
Dans un mode de réalisation, l’interface d’application peut être une interface d’application graphique, l’extension d’application étant configurée pour rendre le fichier de description dans une zone dédiée de l’interface application.
Le dispositif de traitement de fichier peut être par ailleurs configuré pour déterminer une notation pour chaque valeur associée à une clé donnée de l’ensemble prédéfini de clés et pour inclure la notation déterminée pour la valeur associée à la clé donnée dans le fichier de description.
L’extension d’application peut par ailleurs être configurée pour afficher une image de la partie du contenu de message dans la zone dédiée et pour générer l’affichage d’un ou de plusieurs éléments sélectionnables de mise en évidence pour chaque élément de donnée de la partie de contenu du message en mappant une clé, chaque élément de mise en évidence pour un élément de donnée donné étant affiché sur une position dans l’image affichée qui est déterminée à partir de l’ensemble des données de positionnement identifiant la position de l’élément de donnée.
Le dispositif orchestrateur peut être configuré pour utiliser un identifiant de message associé au message pour chaque échange entre le dispositif orchestrateur et le serveur de messagerie, et/ou l’extension d’application, et/ou le dispositif de traitement de fichier et/ou le dispositif cible.
Par ailleurs, un procédé est fourni pour intégrer du contenu de message dans un dispositif de traitement cible, le dispositif de traitement de données cible étant configuré pour traiter une donnée entrée ayant une structure de donnée prédéfinie, le procédé comprenant la réception d’un message d’un dispositif client de messagerie qui exécute une application de messagerie, le message comprenant le contenu du message. Le procédé peut comprendre l’intégration d’au moins une partie du contenu du message dans ledit dispositif de traitement de données cible, le procédé étant par ailleurs configuré pour déterminer un fichier déterminé à partir de la partie de contenu de message et pour transformer le fichier en un fichier de description comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, le procédé comprenant la dérivation d’un fichier d’entrée ayant la structure de donnée prédéfinie à partir dudit fichier de description et transmettant ledit fichier d’entrée déterminé au dispositif de traitement de données cible pour traitement du fichier d’entrée déterminé par le dispositif de traitement cible.
Un produit-programme d’ordinateur est également fourni, il comprend :
un support non transitoire de stockage lisible par ordinateur; et des instructions stockées sur le support de stockage non transitoire, lisible par ordinateur qui, lorsqu’il est exécuté par un processeur, amène le processeur à intégrer du contenu de message dans un dispositif de traitement de données cible, le dispositif de traitement de données cible étant configuré pour traiter la donnée d’entrée ayant une structure de donnée prédéfinie, le processeur étant par ailleurs amené à :
- recevoir un message en provenance d’un dispositif client de messagerie qui exécute une application de messagerie, le message comprenant un contenu de message ;
- intégrer au moins une partie du contenu de message dans le dispositif de traitement de données cible, le processeur étant par ailleurs amené à déterminer un fichier déterminé à partir de la partie de contenu de message et à transformer le fichier en un fichier de description comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs,
- déterminer un fichier d’entrée ayant la structure de donnée prédéfinie à partir du fichier de description et transmettre le fichier déterminé au dispositif de traitement de données cible pour un traitement du fichier d’entrée déterminé par le dispositif de traitement cible.
BRÈVE DESCRIPTION DES DESSINS
Les dessins, qui font partie intégrante de cette spécification, illustrent des modes variés de réalisation de l’invention et, avec la description générale de l’invention ci-dessus et la description détaillée des modes de réalisation donnée ci-après, servent à expliquer les modes de réalisation de l’invention.
- La Figure 1 est une vue schématique d’un exemple d’environnement d’exploitation incluant un système pour intégrer au moins un fichier dans un dispositif de traitement de données cible ;
- La Figure 2 illustre un exemple d’interface d’application selon un mode de réalisation ;
- La Figure 3 illustre de façon schématique un exemple de structure de message électronique ;
- La Figure 4 est une vue schématique d’un dispositif de traitement de fichiers, selon certains modes de réalisation ;
- La Figure 5 est une vue schématique d’un moteur d’extraction de données du dispositif de traitement de fichiers, selon certains modes de réalisation ;
- La Figure 6 représente un exemple de vue de l’interface d’application, selon certains modes de réalisation ;
- La Figure 7 est un organigramme décrivant le procédé d’intégration d'au moins une partie de contenu de message dans un dispositif de traitement de données cible, selon certains modes de réalisation ;
- La Figure 8 est un organigramme décrivant le processus d’initialisation œuvre par l’extension d’application selon certains modes de réalisation ;
- La Figure 9 est un organigramme décrivant le processus d’intégration d’un fichier joint dans un dispositif de traitement cible, selon certains modes de réalisation ;
- La Figure 10 est un organigramme décrivant le processus implémenté par le dispositif de traitement de fichiers, selon certains modes de réalisation ;
- La Figure 11 est une vue d’un exemple de fichier de description au format Json ;
- La Figure 12 est un organigramme décrivant le processus d’affinage d’un fichier de description dans certains modes de réalisation ; et
- La Figure 13 est un diagramme d’un dispositif ou système informatique.
DESCRIPTION DÉTAILLÉE
La Figure 1 est une vue schématique d’un exemple d’environnement d’exploitation incluant un système 100 pour intégrer au moins un fichier dans un dispositif de traitement de données cible 2. Le système 100 peut comprendre un serveur de messagerie 11 configuré pour recevoir un message électronique 12 (tel qu’un « courriel », un message instantané également connu sous le nom de chat ou flux de conversation en ligne) provenant d’un dispositif client de messagerie 14 qui exécute une application de messagerie 15. Le message électronique peut comprendre un contenu de message sous forme de données de message incluses dans le corps du message, et/ou un ou plusieurs fichiers joints au message (également désignés «pièces jointes» ou «fichiers joints»). Le contenu du message peut aussi concerner une ou plusieurs opérations (également désignées comme «transactions»). L’application peut par exemple être Microsoft Outlook et le serveur de messagerie 11 peut par exemple être Microsoft Exchange Server (Microsoft Outlook et Microsoft Exchange Server sont des marques déposées de l’entreprise Microsoft).
Le dispositif de traitement de données cible 2 peut être configuré pour traiter un fichier de données saisies ayant une structure de donnée prédéfinie et étant relatif à des opérations cibles, conformément à un processus dédié.
Dans un exemple d’application de l’invention, le dispositif de traitement de données cible 2 peut être un dispositif de traitement de frais ou un outil (également désigné comme dispositif de rapport de frais) utilisé par une entreprise ou une entité pour traiter les rapports de frais engagés par les salariés de l’entreprise ou de l’entité, ou par un particulier pour gérer ses frais personnels. Dans un contexte d’entreprise, un tel dispositif de traitement de frais 2 peut être configuré pour recevoir un fichier de description qui identifie une opération de frais (p. ex. des frais de voyage) afin de générer un rapport de frais permettant de rembourser l’utilisateur si les données saisies relatives aux frais sont en conformité avec des règles prédéfinies. Tous Chacun des frais pouvant être associé à un relevé de frais représentant l’ensemble des frais engagés par une entreprise ou pour le compte d’une entreprise pour une transaction donnée. Le dispositif de traitement de frais 2 peut être localisé à l’intérieur (p. ex. une application logicielle de bureau préinstallée sur le dispositif de l’utilisateur) ou à l’extérieur de chaque dispositif client 14, et/ou distribué entre de multiples ordinateurs (p. ex. sous forme d’une application logicielle serveur-client, telle qu’une application web). Dans un tel exemple d’application, les fichiers joints peuvent comprendre des pièces jointes correspondant à des reçus relatifs à un ou plusieurs frais, les pièces jointes étant par exemple une photo ou une copie scannée d’un reçu, une facture électronique en format PDF envoyée par un hôtel, un restaurant ou une société de taxis qui correspond au service facturé dans le reçu.
Le serveur de messagerie 11 peut être configuré pour recevoir des messages électroniques, faire tampon avec les messages reçus et envoyer des messages vers un dispositif de destination.
Chaque dispositif client 14 (également désigné comme «dispositif d’utilisateur») peut être un dispositif informatique personnel, une tablette informatique, un terminal client léger, un smartphone et/ou un autre dispositif informatique. Chaque client 14 peut héberger des navigateurs web et/ou un logiciel d’applications personnalisées (p. ex. un système client), et peut inclure une interface utilisateur client.
De façon générale, le dispositif clients 14 peut être tout système informatique approprié configuré pour exécuter l’application de messagerie 15 associée à l’interface d’application 150 via laquelle un utilisateur peut envoyer ou recevoir des messages électroniques.
Chaque message électronique 12 peut être associé à un identifiant de message unique qui identifie de façon unique le message.
L’application de messagerie 15 peut comprendre un gestionnaire d’interface 151 pour transmettre les données d’application dans l’interface d’application 150.
Le serveur de messagerie 12 peut être configuré pour stocker chaque message électronique dans une base de données avec les fichiers joints, si le contenu du message comprend des pièces jointes.
Le terme « pièce jointe de message » tel qu’il est utilisé dans les présentes (également désigné dans les présentes comme «pièce jointe de courriel», un « fichier joint » ou tout simplement « une pièce jointe ») fait référence à un fichier électronique ou à un document compris dans un courriel, le fichier électronique étant représenté par un élément de représentation cliquable, tel qu’une vignette associée à un nom de fichier. Chaque fichier joint 121 a un format de fichier, par exemple un format jpeg, gif, pdf, Word, Html. Un format de fichier peut être « structuré » ou « non structuré ». Les pièces jointes du message peuvent inclure des photos ou des images ayant des formats différents. Une pièce jointe d’un message peut autrement inclure un fichier qui est dans le corps du message, tel qu’une image dans un courriel ou une autre reproduction du fichier en question.
Le système 100 peut comprendre un dispositif orchestrateur 18 configuré pour intégrer le contenu du message sélectionné reçu par l’application de messagerie 15 dans le dispositif de traitement de données cible 2. Le contenu du message peut être tout contenu reçu dans tout type de messages pris en charge par l’application tels qu’un contenu de courriel, un message instantané, un flux. En prenant l’exemple d’un courriel, le contenu peut être inclus dans le corps du courriel ou dans un fichier joint.
Pour faciliter la compréhension de certains modes de réalisation de l’invention, la description qui suit sera faite en référence à l’intégration de fichiers joints dans un dispositif de traitement de données cible, mais les hommes de métier comprendront aisément que de façon générale l’invention s’applique à un contenu de message reçu par une application de messagerie 15. Cependant, les termes « pièce jointe » ou « fichier joint » doivent être interprétés comme comprenant tout contenu de message inclus.
Les fichiers joints peuvent être sélectionnés ou filtrés par le dispositif orchestrateur 18 en fonction de plusieurs critères relatifs au fichier, tels que le nom du fichier, l’extension du fichier, la taille du fichier.
L’application de messagerie 15 peut comprendre une extension d’application exécutable 152 (une extension d’application peut aussi être désignée comme un «plug-in», « add-in » ou « un composant logiciel d’extension ») configurée pour ajouter une caractéristique d’intégration de donnée dynamique 15. En particulier, l’extension d’application 152 peut être 4 configurée pour gérer une zone dédiée de l’interface d’application 150 et pour interagir avec le dispositif orchestrateur 18. L’extension d’application 152 peut par ailleurs être configurée pour générer une restitution de données reçues du dispositif orchestrateur 18.
L’application d’interface 150 et en particulier la zone dédiée de l’interface application gérée par l’extension d’application 152 peut comprendre différents types d’éléments graphiques, tels que des fenêtres, des champs d’entrée de texte, des icônes, des éléments sélectionnâmes, des éléments de contrôle graphique tels que des menus déroulants ou des boîtes de liste, des boutons d’activation, etc.
Le système 100 peut par ailleurs comprendre un dispositif de traitement de fichier 19 (également désigné comme «dispositif de transformation de fichier») configuré pour convertir ou transformer un fichier d’entrée 190 dans un format non structuré en un fichier de description 191 ayant la structure de donnée prédéfinie prise en charge par le dispositif de traitement de données cible 2 et comprenant un ensemble prédéfini de clés, au moins certaines de ces clés étant associées à une ou plusieurs valeurs.
Dans une application de l’invention pour les rapports ou la gestion de frais, l’ensemble des clés peut inclure des clés qui sont communes à tous les reçus (également désignées comme « clés obligatoires ») tels que :
- le type de reçu ;
- la date du reçu ;
- le montant du reçu ;
- l’identification du vendeur (nom de la société qui facture tel que le nom d’un hôtel, le nom d’une société de taxis, etc.).
L’ensemble des clés peut par ailleurs inclure des clés qui dépendent d’un sous-type de reçu (p. ex. un reçu de taxi, un reçu d’hôtel, un reçu de restaurant) tel que :
- l’itinéraire d’un taxi (origine/destination) pour un reçu de taxi ;
- le nombre de nuits pour un reçu d’hôtel ;
- les services en supplément pour un hôtel : petit-déjeuner, dîner, etc.
Le dispositif orchestrateur 18 peut être configuré pour :
- recevoir les fichiers sélectionnés stockés par le serveur de messagerie 11 ou provenant directement du dispositif client de messagerie 14 (l’utilisateur peut par exemple faire suivre un courriel comprenant un reçu en pièce jointe à un composant du dispositif orchestrateur) ; et
- transmettre un ensemble de fichiers déterminés à partir d’au moins certains fichiers parmi les fichiers sélectionnés au dispositif de traitement de fichier 19.
Le dispositif orchestrateur 18 peut être configuré pour transmettre un fichier de description 182 déterminé à partir du fichier de description 191 au dispositif de traitement de données cible 2. Dans un mode de réalisation préféré, le fichier de description 191 peut être affiné antérieurement par le dispositif orchestrateur 18 en réponse à des saisies reçues de l’utilisateur via la zone dédiée de l’interface application gérée par l’extension d’application 152.
En particulier, l’extension d’application 152 peut être configurée pour générer un rendu du fichier de description déterminé à partir du fichier de description 191 fourni par le dispositif de traitement de fichier en utilisant le gestionnaire d’interface 151.
Le dispositif de traitement de données cible 2 peut ensuite traiter le fichier de description 182, reçu du dispositif orchestrateur 18 et initier un processus dédié dépendant du champ d’application du dispositif de traitement de données cible.
Dans certains modes de réalisation, chaque fichier 190 saisi dans le dispositif de traitement de fichier 19 par le dispositif orchestrateur 18 correspondant à un fichier joint d’origine 121, peut être associé à un identifiant d’utilisateur et/ou à un contexte (par exemple, une information de voyage, une information d’entreprise, une information de lieu pour un reçu de voyage, dans l’exemple d’implémentation d’un rapport de frais de l’invention).
Dans une application de l’invention pour la génération de rapport de frais ou de gestion de frais, le système 100 selon des modes de réalisation de l’invention permet une acquisition fiable des reçus relatifs à des frais sans que l’utilisateur soit obligé de saisir manuellement les données dans un formulaire via une interface directe avec le système de traitement de frais 2. Le système de traitement de frais peut donc acquérir, vérifier et effectuer un rapprochement pour chaque reçu avec un compte d’utilisateur permettant de rembourser l’utilisateur qui a fait la dépense. Le fait de simplifier, en augmentant la fiabilité et le taux d’acquisition des données de frais par le système de traitement de frais 2, peut améliorer le délai de remboursement pour l’utilisateur.
Par ailleurs, selon des modes de réalisation de l’invention, le dispositif client 14 peut intégrer différents frais relatifs à un ou plusieurs relevés de dépenses dans le dispositif de traitement de frais 2 sans que l’utilisateur ait besoin d’interfacer directement avec le dispositif de traitement de frais ou de remplir un formulaire dédié dans l’interface du dispositif de traitement de frais.
Dans certains modes de réalisation, le dispositif orchestrateur 18 peut être connecté au serveur de messagerie 11 selon un premier protocole de communication, à l’application de messagerie 150 selon un second protocole, au dispositif de traitement de fichier cible 19 selon un troisième protocole de communication et au dispositif de traitement de données cible 2 selon un quatrième protocole de communication
Dans un mode de réalisation, les premier, second, troisième et quatrième protocoles de communication peuvent être les mêmes. Autrement, au moins une partie du premier, second, troisième et quatrième protocole de communication peut être différente.
L’extension d’application de messagerie 152 peut être lancée automatiquement lorsque l’utilisateur lance l’application de messagerie 15. Autrement, l’extension d’application de messagerie 152 peut être lancée de façon dynamique en réponse à une ou plusieurs conditions relatives aux fichiers joints présents dans un courriel, tels que par exemple, si un courriel comprend au moins un fichier joint, ou si le courriel comprend au moins un fichiers joints ayant des noms de fichiers spécifiques, ou des extensions de fichier spécifiques, ou des conditions relatives à l’émetteur, par rapport à la formulation de l’objet d’un courriel, ou d’autres conditions qui peuvent être déterminées par apprentissage automatique avec d’autres courriels reçus précédemment.
Dans un autre mode de réalisation, l’extension d’application 152 peut être lancée de façon statique en réponse à l’activation d’un élément d’activation dédié, tel qu’un bouton, par un clic de l’utilisateur. Un tel élément d’activation peut être affiché dans l’interface d’application 15, par exemple directement dans le corps du courriel, ou dans la barre d’outils.
L'activation de l’extension d’application de messagerie 152 peut déclencher une sélection d’un sous-ensemble des fichiers joints en fonction d’une ou plusieurs conditions, telles que des conditions relatives au format de la pièce jointe. L’activation de l’extension d’application de messagerie 152 peut par ailleurs causer l’affichage d’une vignette de chaque fichier sélectionné dans une zone dédiée de l’interface de l’application.
Dans un autre mode de réalisation, l’utilisateur peut sélectionner directement les fichiers joints par une opération de glisser-déposer pour les amener dans la zone dédiée en cliquant sur un bouton de sélection associé à chaque fichier joint. L’extension d’application peut ensuite générer une vignette actionnable par un clic pour les pièces jointes sélectionnées dans la surface dédiée. Dans certains modes de réalisation, l’extension d’application peut par ailleurs afficher une vue entière de chaque fichier joint (p. ex. un reçu) en cours d’intégration dans le dispositif de traitement de données cible 2 sous forme d’une image. Dans certains modes de réalisation, le fichier joint affiché qui était initialement affiché visuellement dans son intégralité peut être agrandi ou diminué avec le zoom par l’utilisateur afin d’améliorer la vue du reçu pour l’utilisateur.
Dans certains modes de réalisation, le dispositif de traitement de fichier 19 peut faire partie du dispositif orchestrateur 18. Cependant, la description qui suit de certains modes de réalisation de l’invention sera faite par référence à un dispositif séparé de traitement de fichier 19.
Le serveur de messagerie 11 peut communiquer avec un ou plusieurs dispositifs client 14 via un réseau de communication 60.
Le dispositif orchestrateur 18 peut être hébergé dans le même système informatique que le dispositif de traitement de fichier 19 et/ou le dispositif de traitement de données cible 2, et/ou le serveur de messagerie 11. Autrement, le dispositif orchestrateur 18, le dispositif de traitement de fichier 19 et/ou le dispositif de traitement de données cible 2, et/ou le serveur de messagerie 11 peuvent être hébergés dans des systèmes informatiques différents et communiquer via un ou plusieurs réseaux de communication.
Chaque réseau de communication utilisé pour permettre la communication entre deux dispositifs du système 100 peut inclure un ou plusieurs réseaux privés et/ou publics (p. ex. Internet) qui permettent l’échange de données, par exemple de l’Internet, d’un réseau de zone locale (LAN), d’un réseau de zone étendue (WAN), d’un réseau cellulaire voix/données, d’une ou de plusieurs connexions par bus à haute vitesse et/ou d’autres types de réseaux de communication. Chaque réseau de communication tel que le réseau 100 peut utiliser des technologies de communication standards et/ou des protocoles tels que 4 G, Ethernet, 802.11, TCP/IP (Protocole de contrôle de transmission/Protocole Internet), HTTP (Protocole de transport hypertexte), FTP (Protocole de transfert de fichier), etc. Les données peuvent être échangées sur chaque réseau selon des technologies d’échange de données différentes et/ou des formats tels que le langage de balisage hypertexte (HTML), le modèle JSON et le langage de balisage étendu (XML).
Dans une opération conventionnelle :
- en mode de transmission, le dispositif client de messagerie 11 peut demander au serveur de messagerie 11 de transmettre un message 12 à un ou plusieurs destinataires identifiés dans les éléments de désignation de destinataires 122 correspondant aux dispositifs clients destinataires, à l’intérieur du même réseau ou sur un autre réseau accessible.
- en mode réception, le dispositif client 14 peut recevoir un message 12 provenant d’un autre dispositif client directement en mode « pousser » (push) ou indirectement via la réception d’une notification informant le serveur 12 de la réception d’un nouveau message, le dispositif client étant ensuite configuré pour « tirer » (pull) le message du serveur 11.
Un jeton de sécurité peut être utilisé pour récupérer les fichiers et valider la communication/les échanges.
Faisant référence à la figure 2, un exemple d’interface d’application 150 est représentée avec le dispositif de traitement cible 2 envisagé dans un dispositif de rapport de frais, conformément à un exemple de mode de réalisation. Selon cet exemple de mode de réalisation, l’activation de l’extension d’application de messagerie 152 peut déclencher un affichage dans une zone d’interface dédiée 5 située dans une partie de l’interface d’application 150. La zone d’interface 150 peut comprendre la boîte de réception de messages dans une portion 1500 de la zone d’interface incluant le courriel actuel qui comprend des pièces jointes. Dans le mode de réalisation exemplaire illustré par la figure 2, la zone dédiée 5 peut être divisée en trois parties comprenant par exemple :
- une première partie 50 (« partie de vue de l’image »),
- une seconde partie 51 (« vue des vignettes »), et
- une troisième partie 52 (« partie de vue du formulaire de vérification »).
La première partie 50 peut être fournie pour afficher une vue sous forme d’image de chaque pièce jointe qui peut être une vue entière et qui peut être déplacée, agrandie ou diminuée par l’utilisateur, pendant le traitement de cette pièce jointe par le dispositif orchestrateur 18. La seconde partie 51 peut inclure une vignette des pièces jointes pertinentes (des images de courriel). La troisième partie 52 peut être fournie pour afficher un formulaire de vérification déterminé à partir du fichier de description 191 renvoyé par le dispositif de traitement de fichier 19. Cela permet à l’utilisateur de comparer les données du formulaire tel qu’il a été extrait par le système de traitement de fichier avec le fichier joint d’origine correspondant 121 affiché dans la partie 50.
L’homme de métier comprendra aisément que le formulaire ne se limite pas aux champs du formulaire indiqués dans l’exemple de la figure 2, mais peut inclure d’autres champs qui peuvent être extraits ou déduits (par exemple le champ « pays » peut être déduit d’un élément de donnée « adresse » ou « devise »).
Les fichiers affichés dans la zone dédiée 5 peuvent être traités de façon séquentielle par le dispositif orchestrateur 18. Dans ce mode de réalisation, le traitement d’un fichier joint 121 par le dispositif orchestrateur 18 peut être déclenché par l’utilisateur. Dans une application plus générale de l’invention, un quelconque contenu d’un message pourrait être traité de façon similaire.
La partie 50 de vue de l’image peut par exemple inclure un élément de zoom 501 pour permettre à l’utilisateur de zoomer ou de déplacer un fichier joint affiché. Dans un autre mode de réalisation, l’extension d’application 152 peut inclure des cases à cocher dans la seconde partie 52 de la zone dédiée 5 à côté de chaque fichier joint individuel, l’utilisateur pouvant sélectionner une pièce jointe pour intégration dans le dispositif de traitement de données cible 2 en utilisant la case à cocher. Dans un autre mode de réalisation, les fichiers joints peuvent être traités automatiquement selon un ordre arbitraire ou des critères prédéfinis.
Dans un autre mode de réalisation, les fichiers sélectionnés (p. ex. les reçus) peuvent être traités parallèlement par le dispositif orchestrateur 18 et/ou le dispositif de traitement de fichier 19. Pour faciliter la compréhension de l’invention, la description suivante sera faite en référence à un traitement séquentiel des fichiers sélectionnés à titre d’illustration.
Dans certains modes de réalisation, la partie 52 de vue du formulaire 52 peut par ailleurs inclure un bouton de validation 520 qui peut être sélectionné par l’utilisateur pour valider le formulaire.
La figure 3 montre de façon schématique un exemple de structure de message électronique 12 envoyé à partir du dispositif client de messagerie 14 au serveur de messagerie 11.
Comme on le voit, un message électronique 12 peut comprendre une donnée brute 120, des éléments de désignation de destinataire 122 identifiant un ou plusieurs destinataires, des pièces jointes de messages 121, un identifiant de message 123 identifiant de façon unique le message, des attributs de message 124 représentant les attributs du message tel que l’attribut d’expiration d’un message.
La figure 4 est une vue schématique d’un dispositif de traitement de fichier selon certains modes de réalisation.
Le dispositif de traitement de fichier19 peut comprendre :
- un moteur d’extraction de données 162 configuré pour extraire des caractères dans le fichier non structuré 190 (p. ex. une image de reçu correspondant par exemple à une image scannée ou à une photo d’un reçu) en utilisant au moins un algorithme d’extraction tel qu’un algorithme de lecteur de caractères optiques OCR (Optical Character Reader); le moteur d’extraction de données 192 peut donc extraire les données du fichier joint reçu comme entrée dans un mode de réalisation et fournir des données numériques qui peuvent être stockées dans une mémoire 193 (mémoire de données extraites) ;
- un mappeur194 configuré pour mapper aux moins certaines clés d’un ensemble prédéfini de clés 196 à un ou plusieurs éléments de données numériques saisies, dans le fichier non structuré 190 reçus comme des entrées par le dispositif de traitement de fichier 190 ; le mappeur 194 fournit donc un ensemble de clés, chacune étant associée à une ou plusieurs valeurs correspondant aux éléments de données qui y sont mappés.
- un générateur de fichiers de description 198 configuré pour générer un fichier de description 191 à partir du fichier d’entrée 190, avec le fichier de description comprenant l’ensemble de clés prédéfinies 196, chaque clé étant associée à zéro, une ou plusieurs valeurs déterminées à partir des éléments de données du fichier d’entrée 190 mappés à la clé.
Dans un mode de réalisation, l’ensemble de clés 196 devant être mappé aux éléments de données fichier joint peut être filtrée précédemment selon le type de fichiers joints ou reçus du dispositif orchestrateur 18, le dispositif orchestrateur 18 ayant précédemment récupéré l’ensemble de clés du dispositif de traitement cible 2 en fonction du type de fichier joint détecté. Dans une application de gestion/rapport de frais de l’invention, en considérant les fichiers joints de sous-reçus, un reçu peut avoir plusieurs sous-types tels que le sous-type taxi, le sous-type hôtel, le sous-type restaurant, chaque reçu d’un sous-type étant associé à un ensemble prédéfini de clés (par exemple un reçu de sous-type taxi peut être associé à un ensemble de clés qui incluent la date, le montant, l’itinéraire [origine/destination], le nom de la société de taxi, etc.).
Le fichier de description peut avoir tout format faisant usage de texte pour transmettre des objets de donnée qui consistent en des paires valeur attribut et éventuellement de types de donnée de réseau ou autre valeur pouvant être sérialisés tels que la notation d’objet JavaScript ou JSON.
Tel qu’il est utilisé dans les présentes, un «fichier une description » fait référence à un document qui utilise du texte pour transmettre des objets de donnée qui consistent en des paires valeur-attribut.
Dans un mode de réalisation, le dispositif de traitement de fichier 19 peut comprendre par ailleurs une unité de détermination de données de positionnement (PDDU) configurée pour déterminer l’ensemble des données de positionnement à partir du fichier d’entrée 190. L’ensemble des données de positionnement peut être déterminé par le moteur d’extraction de données 192 et utilisé par le mappeur 194 pour identifier la position d’un élément de donnée mappé à une clé de l’ensemble prédéfini de clés 196 dans une image représentant le fichier joint 190. Chaque ensemble de données de positionnement qui identifie la position un élément de donnée du fichier joint peut être mappé à une clé dans le fichier de description 191 (fichier JSON par exemple) associé à la clé.
Dans un mode de réalisation, chaque ensemble de données de positionnement peut comprendre des coordonnées de positionnement (x, y) dans un référentiel donné, tel qu’un référentiel 2D (X, Y) défini par le fichier non structuré d’origine.
Dans un mode de réalisation, le dispositif de traitement de fichier 19 peut comprendre une unité 197 de détermination de notation configurée pour déterminer une notation pour les valeurs candidates mappées à certaines clés par le mappeur 194. Par conséquent, pour une clé donnée associée à plusieurs valeurs candidates, une notation peut être attribuée à chaque valeur. Le dispositif de traitement de fichier 19 peut être par ailleurs configuré pour inclure la notation déterminée pour chaque valeur associée à une clé donnée dans le fichier de description 191. Autrement, le dispositif de traitement de fichier 19 peut présenter la valeur candidate selon un ordre de pertinence en fonction de la notation.
Dans certains modes de réalisation, la notation peut être déterminée pour les clés qui sont considérées comme étant obligatoires afin de déclencher un traitement par le dispositif de traitement de données cible 2. Par exemple, dans une application de l’invention pour la gestion/le rapport de frais, le fichier joint d’un type de reçu est exigé afin d’obtenir au moins une date clé et un montant clé.
La Figure 5 montre une représentation schématique du moteur d’extraction de donnée 192 du dispositif de traitement de fichier 19 selon un exemple d’application de l’invention pour la gestion ou le rapport de frais.
Chaque fichier joint reçu par le dispositif de traitement de fichier 19 peut donc être un reçu. Dans certains modes de réalisation, le dispositif de traitement de fichier 19 peut recevoir tous les fichiers joints ou autrement inclus par un utilisateur dans un courriel, traiter chaque fichier et déclencher une erreur si un fichier n’appartient pas à un type de reçu. Dans un autre mode de réalisation, chaque fichier joint peut être traité dans une phase initiale de traitement pour vérifier s’il a un format de reçu et/ou détecter le type de reçu et/ou récupérer les clés associées au type de reçu.
Le moteur d’extraction de donnée 192 peut comprendre un convertisseur 1921 configuré pour évaluer initialement un ou plusieurs attributs du fichier joint requis pour appliquer l’OCR et/optimiser la performance de l’extraction de donnée. Les valeurs de ces attributs peuvent être vérifiées et/ou normalisées si leurs valeurs ne sont pas optimales par exemple :
- en effectuant une rotation de l’image ; ou
- en vérifiant et corrigeant la résolution de l’image (points par pouce) dans le cas où la résolution indiquée par la caméra est plus basse que la véritable résolution.
Le moteur d’extraction de données 192 peut par ailleurs comprendre un classificateur de fichiers 1922 configuré pour identifier le type d’un fichier joint (p.ex. facture électronique, reçu, etc.) afin d’optimiser l’extraction de donnée à partir du fichier joint. Ces types de documents peuvent fournir des informations sur la présentation du fichier joint et identifier le type d’information qui doit être extraite.
Le classificateur de fichiers 1922 peut être configuré pour identifier le type de fichier joint (p. ex. taxi, hôtel, etc.) en comparant le fichier joint à un autre ensemble connu de documents de référence similaire (p. ex. texte TAXI). Un document est considéré comme étant similaire à un fichier joint s’il comprend un ensemble d’attributs qui sont comparables aux attributs du fichier joint. Ces documents de référence peuvent être déterminés à partir de rapprochements passés, fixés par une saisie d’utilisateur et/ou n’ayant pas été invalidés par un seuil d’utilisateurs.
Le classificateur de fichiers 1922 peut être configuré pour convertir l’image représentant l’image du fichier joint dans un vecteur de caractéristiques en utilisant des transformations et des filtres pour fournir une entrée normalisée. Dans certains modes de réalisation, cela peut créer une image beaucoup plus petite en matière de taille de fichier et/ou de dimension, dont l’échelle peut être réduite, avec des contours intensifiés, monochromes et une luminosité équilibrée.
Le classificateur de fichiers 1922 peut extrapoler le type de fichier sur la base du vecteur de caractéristiques ainsi obtenu. Dans un mode de réalisation, une approche basée sur l’apprentissage automatique peut être utilisée pour inférer une plusieurs propriétés du fichier joint à partir du vecteur de caractéristiques, par exemple le nombre de colonnes, le ratio de la page, la localisation du corps principal du texte, la localisation de l’en-tête et ainsi de suite.
Dans un mode de réalisation, si le fichier d’entrée 190 est reçu en format image, le moteur d’extraction de donnée 192 peut comprendre un scanner OCR 1924 configuré pour effectuer une numérisation OCR afin de produire un texte à partir du fichier joint et extraire des mots. Autrement, toute technique d’extraction de donnée peut être utilisée en fonction du format du fichier d’entrée 190 (par exemple HTML et fichier texte PDF).
Le moteur d’extraction de données 192 peut comprendre un classificateur de langage 1925 configuré pour utiliser la donnée extraite (par exemple extraites par le scanner OCR 1924) afin de générer des trigrammes représentant des groupes de trois lettres qui se chevauchent. La répétition et l’existence de ces trigrammes peuvent être utilisées pour déterminer la ou les langue(s) avec un certain niveau de confiance (par exemple le trigramme « LAN » et plus présent en espagnol qu’en anglais). Le moteur d’extraction de données 192 peut par ailleurs utiliser des données contextuelles pour améliorer la fiabilité de l’extraction de données ou déterminer certaines valeurs clés sans avoir besoin de les déterminer à partir de la numérisation OCR (p. ex. la localisation connue de l’utilisateur, les itinéraires de voyage, les coordonnées GPS à partir de photographies, etc.). Dans des modes de réalisation où les fichiers joints comprennent plusieurs langues, la langue prédominante peut être sélectionnée : un niveau de prédominance peut être attribué à chaque langue en fonction du niveau d’utilisation de la langue à travers le fichier. Les langues ayant un niveau de dominance en dessous d’un certain seuil peuvent être ignorées (par exemple, si le fichier joint est un reçu comprenant un nom de restaurant en français alors que le reçu est en allemand, l’allemand serait la langue prédominante). En identifiant les langues d’un document, le classificateur de langues 1925 permet au moteur d’extraction de donnée 192 de mieux identifier le texte et la langue lui appartenant, en utilisant un algorithme d’extraction tel qu’un algorithme OCR. Cela écarte le besoin de numérisation pour détecter toutes les langues possibles et permet l’utilisation de dictionnaires spécifiques à une langue.
Le classificateur de langues 1925 peut par ailleurs utiliser la langue de localisation des données qui peut être fournie par les algorithmes d’extraction (algorithme OCR par exemple) pour chaque langue détectée en identifiant la localisation ou la région du fichier joint dans laquelle la langue détectée est utilisée (p. ex. l’indication que la ligne du haut est en bulgare alors que la ligne du bas est en anglais).
Cela permet de mieux interpréter le contenu du fichier joint en utilisant un algorithme d’extraction (algorithme OCR).
Dans un autre mode de réalisation, au lieu d’utiliser le classificateur de langue 1925, le moteur d’extraction de données peut être configuré pour traduire le texte dans la langue prise en charge par les algorithmes d’extraction.
Le moteur d’extraction de données 192 peut par ailleurs comprendre un extracteur d’information 1926 utilisant un algorithme d’extraction pour extraire les caractères dans le fichier joint 121, par exemple un algorithme OCR. L’extracteur d’information 1926 peut par ailleurs extraire les ensembles de données de positionnement (p. ex. les coordonnées) à partir du fichier joint 121.
L’homme de métier comprendra aisément que l’invention ne se limite pas à l’utilisation des extracteurs d’information OCR, en fonction du type de fichier d’entrée 190 reçu par le dispositif de traitement de fichier 19. En particulier, dans un certain mode de réalisation le dispositif de traitement de fichier 19 peut recevoir un fichier d’entrée 190 dans un quelconque format incluant un texte autochtone pour lequel il n’y a pas besoin d’OCR. La description suivante de certains modes de réalisation de l’invention sera faite en référence aux algorithmes d’extraction OCR à titre d’illustration uniquement, l’extracteur d’information 1926 étant alors désigné comme l’extracteur d’information OCR.
L’extracteur d’information OCR 1926 peut être configuré pour sérialiser les données OCR de la façon suivante.
L’extracteur d’information OCR 1926 peut d’abord lire le résultat de la numérisation OCR 1924 caractère par caractère avec des coordonnées et du formatage. L’extracteur d’information OCR peut comprendre un « concaténateur » 21 pour transformer ces caractères dans un format cible. Le format cible peut par exemple être une chaîne devant alimenter les grammaires utilisées pour l’analyse du document et/ou un index de mappage des caractères à leurs coordonnées et une information de formatage. La « concaténation » initiale peut suivre l’ordre « naturel » de lecture du texte. Cependant, des concaténations additionnelles peuvent être fournies pour permettre la reconnaissance de phrases qui ne suivent pas nécessairement cet ordre initial. Par exemple, dans une présentation de document sur deux colonnes, la concaténation peut d’abord renvoyer le texte dans la colonne de gauche, puis le texte dans la colonne de droite. Cependant, à la réception des pièces jointes, les éléments de ligne peuvent être traités dans une colonne à gauche et les prix dans la colonne de droite. Par conséquent, une concaténation de lignes renvoyant des lignes qui couvrent toute la largeur du document peut être apportée.
Des informations importantes concernant la mise en page du document peuvent être encodées comme caractères spéciaux dans la chaîne renvoyée pour faciliter l’interprétation de la chaîne. Des marqueurs pour « le début de la zone de texte », des « ruptures de ligne », des « fins de paragraphe», des «sauts de page», et ainsi de suite peuvent être inclus. Par conséquent, l’information concernant la structure à 2 dimensions du document peut être mise à disposition pour les grammaires et expressions régulières alors que ce ne serait possible autrement que pour des flux de caractères à 1 dimension.
L’extracteur d’information OCR 1926 peut par ailleurs être configuré pour extraire les valeurs candidates en utilisant des grammaires et des expressions régulières. Des grammaires libres de tout contexte et des expressions régulières peuvent ensuite être utilisées pour rechercher une information pertinente dans le texte. Les grammaires peuvent par exemple être basées sur le contexte de grammaire Unitex (http://unitexgramlab.org/). La chaîne peut être lue pour produire un résultat XML pour les correspondances. Ce résultat XML peut ensuite être lu et transformé en représentation d'objets. En utilisant l’index fourni par le « Concaténateur», chaque objet peut faire l’objet d’une attribution de données de positionnement telles que des données de coordonnées dans un référentiel donné.
Cela permet de déterminer les valeurs candidates pour un traitement ultérieur et d’enrichir les informations sur les valeurs candidates sur la base du contexte. Par exemple, tous les montants peuvent être extraits (sous-chaînes du document qui pourraient être des montants, par ex., « 12.00 »). Si cette chaîne est suivie de « € », il s’agit alors de la devise d’un montant qui peut être signalé comme étant l’Euro. S’il est précédé du mot « Gesamtbetrag », il peut être marqué comme étant un bon candidat pour le montant total. Les grammaires peuvent être écrites de telle façon qu’elles correspondent à la chaîne minimale de caractères constituant le montant, mais également le texte pertinent précédent ou suivant, le cas échéant.
L’extracteur d’information OCR 1926 peut en plus effectuer des vérifications de plausibilités et/ou des tests de validation. Par exemple, les IBANS ont une vérification de somme intégrée qui peut être utilisée pour filtrer les fausses correspondances ou les correspondances OCR comportant des erreurs.
Dans une application de l’invention pour un rapport de frais, l’extracteur d’information OCR 1926 peut par ailleurs être configuré pour effectuer une extraction d’adresse en recherchant des « ancres » qui représentent la combinaison du code postal et de la ville (p.ex. «81593 München»). Les correspondances pour ces ancres permettent de restreindre la zone de recherche pour les grammaires plus complexes recherchant des adresses complètes. Ces correspondances d’ancres peuvent aussi avoir des applications supplémentaires, par exemple pour déterminer le pays/la ville du document sans tenir compte de l’adresse détaillée.
Pour mapper certaines clés particulières obligatoires du reçu, un certain traitement peut être mis en œuvre par le dispositif de traitement de fichier 19.
Par exemple, l’extracteur d’information OCR 1926 peut être encore configuré pour effectuer une validation du montant détecté (correspondant à une clé de montant) dans un fichier joint (un reçu) en utilisant des arbres de sommation. Dans certains cas, les montants pertinents d’un reçu donné peuvent ne pas être listés seuls, mais ensemble avec d'autres montants qui contribuent aux valeurs cibles. Par exemple, le montant brut peut être la somme des montants nets et des montants de TVA. Des combinaisons de valeurs possibles peuvent être additionnées pour aboutir à des valeurs plus élevées également trouvées dans le document et un ensemble de règles peut être appliqué pour essayer de trouver des relations entre ces éléments.
Ces règles peuvent attribuer des rôles aux montants correspondants, par exemple : net, brut, total, en espèces, etc.
La validation de montant peut être utilisée en combinaison avec d’autres stratégies d’extraction ou dans un contexte particulier tel que pour des reçus similaires. La validation de montant peut apporter un paramètre additionnel pour une estimation de confiance. Elle peut être indépendante des autres stratégies d’extraction et peut ne pas tenir compte des propriétés utilisées par ces stratégies d’extraction, telles que la localisation sur le document, la taille de police, etc.
Le processus de validation de montant peut commencer par l’ensemble complet de montants candidats A extraits d’un fichier joint reçu par le dispositif de traitement de fichier 19. Ensuite, un algorithme de sous-ensemble de sommes peut être appliqué produisant pour chaque montant a dans A toutes les combinaisons d’autres montants dans A qui s’additionnent au montant a. Les combinaisons peuvent être transformées en arbres de sommation. La valeur de chaque nœud dans ces arbres de sommation peut être la somme des valeurs de ses enfants directs. Des règles peuvent ensuite être appliquées qui tiennent compte de la structure de l’arbre, des valeurs des montants et des balises d’itérations précédentes. Les règles peuvent être appliquées à ces arbres en multiples itérations, permettant l’accès aux résultats d’itérations précédentes. Certaines règles peuvent utiliser une certaine information contextuelle par exemple le pays et le taux d’imposition. Les règles peuvent affecter des balises marquant le rôle des candidats. Par exemple, un montant (1,19 €) est la somme de deux autres montants trouvés dans le document (1,00 € et 0,19 €). La connaissance du pays où le reçu a été émis (l’Allemagne) et du taux de TVA (taxe sur la valeur ajoutée) dans ce pays (19 %) permet de marquer ces trois montants comme brut, net et montant de TVA, respectivement. II peut y avoir d’autres montants dans la pièce jointe (p. ex. 0,70 €, 0,20 € et 0,10 €) pouvant être additionnés pour obtenir le montant brut. On peut ensuite supposer que ces autres montants sont les éléments du reçu.
II n’est pas nécessaire que les balises résultantes soient correctes, puisqu’elles sont utilisées comme une caractéristique parmi d’autres par le service de notation qui suit.
Pour noter les valeurs candidates des montants correspondants à la clé de montant obligatoire d’un reçu, l’unité de détermination de notation 197 du dispositif de traitement de fichier peut attribuer une probabilité à chaque montant correspondant à la probabilité que ce montant représente le « montant total » du reçu en utilisant un composant de notation de montant. Le composant de notation 197 peut utiliser des propriétés pour chaque montant extrait basé sur les résultats précédents. Chaque propriété d’un montant peut être «vraie» ou «fausse», en fonction de certaines conditions et des résultats de validation. Par exemple, cette propriété peut être « un montant brut » ou « avoir de multiples occurrences dans le document » ou « avoir une taille de police plus large». Des poids peuvent ensuite être attribués à ces valeurs en fonction de la fréquence de ladite propriété (ou de ladite combinaison de certaines propriétés) qui a été observée pour le total, la TVA ou les montants nets. En utilisant ces poids, la notation de confiance peut être calculée.
Vu que ces poids sont basés sur des observations dans le passé, ils peuvent être générés en utilisant des données historiques ou des exemples créés manuellement.
Le moteur d'extraction 192 peut par ailleurs être configuré pour effectuer une identification du vendeur permettant d’identifier le vendeur émetteur du reçu correspondant au fichier joint actuel afin de mapper les valeurs candidates à la clé d’identification du vendeur. Plutôt que de reconnaître le vendeur directement à partir du fichier joint, le moteur d’extraction 192 peut être configuré pour extraire l’information afin d’inférer l’identité des vendeurs, par exemple les numéros de téléphone/télécopie, les numéros d’immatriculation des sociétés, les identifiants de TVA, les URLs et ainsi de suite. Avec une base de données appropriée, de telles informations peuvent être utilisées pour inférer l’identité du vendeur. Dans certains modes de réalisation, ladite une ou plusieurs identités de vendeur candidat (valeurs candidates pour la clé d’identité du vendeur) qui sont déterminées peuvent être pondérées selon le type d’information utilisé pour l’inférence, il est supposé que l’identité du vendeur ayant la notation la plus élevée est l’identité du vendeur.
Le fichier de description 191 ainsi généré par le dispositif de traitement de fichier 19 peut être renvoyé directement au dispositif de traitement de données cible 2.
Autrement, dans un mode de réalisation préféré, le fichier de description 191 peut être renvoyé au dispositif orchestrateur 18 pour être affiné. Le dispositif orchestrateur 18 peut transmettre un fichier de description 181 correspondant au fichier de description lui-même 191, ou au fichier de description déterminé à partir du fichier de description 191, à l’application 15 montrée dans la Figure 1.
À titre d’exemple uniquement, la spécification suivante sera faite en référence à ce mode de réalisation où le fichier de description est renvoyé au dispositif orchestrateur 18 pour affinement.
Lorsque le fichier de description 181 est renvoyé à l’application 15 via le dispositif orchestrateur, l’extension d’application 152 peut être configurée pour rendre le fichier de description extrait 180 dans la surface dédiée 5 de l’interface d’application 150, par exemple dans la seconde partie 52 en utilisant un formulaire de vérification comprenant un ensemble de champs, chaque champ correspondant à une des clés du fichier de description 181 et chaque champ ayant une des valeurs affectées à la clé dans le fichier de description 181 ou pas de valeur si aucune valeur candidate n’a été trouvée par le dispositif de traitement de fichier 19. La valeur attribuée à un champ correspondant à une clé du fichier de description 181 peut être initialement la valeur qui a été attribuée à la notation la plus élevée pour la clé dans le fichier de description. L’utilisateur peut ensuite corriger la valeur manuellement ou en utilisant des outils visuels. Cela permet d’affiner des fichiers de description en interagissant avec le dispositif client 14 pour augmenter la fiabilité du fichier de description 181 par rapport au fichier joint d’origine 121.
La Figure 6 représente une vue de l’interface application 150 en réponse à la réception du fichier de description 181 en provenance du dispositif orchestrateur 18, selon certains modes de réalisation.
Dans un mode de réalisation, l’extension d’application 152 peut par ailleurs être configurée pour générer un affichage d’un élément sélectionnable pouvant être mis en évidence ou de la case 53 pour chaque valeur candidate différente trouvée pour une clé (p. ex. la clé de montant) de chaque fichier joint traité 121 (p. ex.) à partir du fichier de description 181 afin de faciliter la vérification du formulaire par l’utilisateur. Chaque case 53 mise en évidence peut être affichée à une position du fichier 121 déterminée à partir d’un ensemble de données de positionnement qui identifient la position de la valeur candidate dans le fichier de description 181.
Les cases 53 mises en évidence peuvent avoir des formes différentes telles que des rectangles et/ou être associées à une couleur de code en fonction de la valeur de notation attribuée à la valeur candidate afin de mettre en avant la pertinence de la valeur candidate telle qu’elle a été évaluée par le dispositif de traitement de fichier 19. Par exemple, un code de couleur verte peut être utilisé pour mettre en avant les valeurs qui ont été sélectionnées pour compléter le formulaire (notation la plus élevée) et la couleur rouge peut être utilisée pour mettre en avant les autres valeurs candidates. Si l’utilisateur clique sur un élément mis en évidence en rouge, la valeur correspondante peut être utilisée pour actualiser la forme, et l'élément mise en évidence peut devenir vert alors que l’élément mis en évidence qui était vert peut devenir rouge.
Autrement, des événements visuels différents peuvent être utilisés pour mettre en évidence la pertinence d’une valeur candidate clé du fichier de description 181 à partir de la notation attribuée à la valeur. Dans un exemple de mode de réalisation, une traduction superposée peut par ailleurs être affichée sur l’image pour les reçus qui ne sont pas dans la langue maternelle de l’utilisateur.
L’utilisateur peut cliquer sur une des cases de mise en évidence associées à une valeur candidate pour une clé afin de la sélectionner plutôt que sur celle qui est associée à la notation la plus élevée dans le fichier de description, ou au contraire pour confirmer la valeur candidate associée à la notation la plus élevée. Cela peut entraîner une actualisation du formulaire de vérification affiché dans la troisième partie 52 de la zone dédiée 5 de l’interface d’application 150 et/ou à une actualisation de la notation de la valeur candidate qui peut impliquer un changement de couleur des cases de mise en évidence 53 utilisées pour les valeurs candidates déterminées pour la clé envisagée en fonction du code de couleur.
Dans certaines implémentations, l’extension d’application 152 peut comprendre un traceur de progrès pour permettre à un utilisateur de suivre le progrès du traitement du fichier sélectionné (non illustré). Ledit traçage peut être stocké dans le contexte de l’application. Si l’utilisateur interrompt son activité et par la suite revient à l’extension d’application 152, l’utilisateur peut reprendre son activité ou être informé si des pièces jointes ont été soumises.
L’utilisateur peut itérer le processus pour chaque clé et faire des corrections si nécessaire. Lorsque l’utilisateur a terminé le processus de vérification, l’utilisateur peut sélectionner le bouton de validation 520 fourni en association avec le formulaire pour déclencher l’envoi du formulaire au dispositif orchestrateur 18.
Le dispositif orchestrateur 18 peut transmettre un fichier affiné de description 182 (tel qu’un formulaire) au dispositif de traitement de données cible déterminé à partir d’une version actualisée du fichier de description intermédiaire 181 dans lequel les valeurs corrigées par l’utilisateur ont été mises à jour. Dans un mode de réalisation, le fichier de description affiné 182 peut comprendre une seule valeur par clé, la valeur attribuée à une clé étant soit la valeur corrigée pour cette clé par l’utilisateur (manuellement par une saisie directe ou par la sélection par exemple d’une valeur mise en évidence) ou la valeur ayant la notation la plus élevée, si l’utilisateur n’a pas corrigé la valeur confirmée activement cette valeur.
Dans un mode de réalisation, le dispositif orchestrateur 18 peut par ailleurs transmettre un fichier de description 183 au dispositif de traitement de fichier 19 déterminé à partir d’une version actualisée du fichier de description intermédiaire 181 ou d’un signal pour informer le dispositif 19 qu’aucune actualisation n’a été effectuée. Le fichier de description 183 transmis au dispositif de traitement de fichier 19 peut être le même fichier de description que le fichier de description 182 transmis au dispositif de traitement de données cible 2 ou inclure des informations supplémentaires. Cela permet de collecter des données pour l’apprentissage automatique par le dispositif de traitement de fichier 19 ou pour l’intégration subséquente de fichiers joints et en particulier pour le mappage subséquent et les opérations de notation effectuées par le dispositif de traitement de fichier 19 pour chaque intégration subséquente de fichiers joints.
La Figure 7 est un organigramme décrivant le procédé d’intégration d’au moins une partie du contenu de message reçu dans un dispositif de traitement de données cible 2, selon certains modes de réalisation.
À l’étape 700, un message électronique 12 est reçu à partir d’un dispositif client de messagerie 14 exécutant l’application de messagerie 15, le message électronique 12 comprenant un contenu de message sous forme d’un ou de plusieurs fichiers joints 121 au message 12. Le contenu de message (p. ex. les fichiers) peut être relatif à une opération ou à une transaction donnée, telle qu’une même dépense pour l’implémentation d’un rapport de frais de l’invention. La description suivante de certains modes de réalisation du procédé sera faite en référence au contenu de message représenté par les fichiers joints d’un courriel, à titre d’illustration uniquement.
Chaque fichier 121 a un format de fichier donné tel que PDF, GIF, JPEG, etc. Chaque message électronique peut être associé à un identifiant de message 123.
À l’étape 702, le message 12 peut être stocké dans une base de données avec les fichiers.
À l’étape 705, chaque fichier attaché 121 du message 12 peut être converti ou transformé en un fichier de description 191, tel qu’un fichier JSON, comprenant un ensemble de clés dont au moins certaines des clés sont associées à une ou plusieurs valeurs, tel qu’un fichier JSON.
À l’étape 706, un fichier saisi extrait 182 déterminé à partir du fichier de description 191 peut être transmis au dispositif de traitement de données cible 2.
La figure 8 est un organigramme décrivant le processus d’initialisation effectué par l’extension d’application 152 et le dispositif orchestrateur 18, selon certains modes de réalisation.
À l’étape 800, un courriel comprenant un ou plusieurs fichiers joints 121 peut être reçu, chaque fichier joint ayant un format prédéfini (p. ex. un fichier JPEG, GIF, PDF, HTML).
À l’étape 802, l’extension d’application 152 peut être activée, par exemple en réponse à la sélection d’un bouton d’activation dans l’interface d’application 150. Autrement, elle peut être activée de façon dynamique ou automatique sur la base d’un courriel ou des attributs de pièces jointes (émetteur, objets, fichiers de format, taille de fichier...).
À l’étape 804, l’application de messagerie 15 du dispositif client peut se connecter au serveur de messagerie 11 afin de requérir la charge de l’extension 152.
À l’étape 806, une initialisation peut être affichée dans une fenêtre ouverte ou une trame-i ouverte dans une zone dédiée 5 de l’interface application 150. La vue d’initialisation peut par exemple comprendre une vignette pour chaque fichier joint sélectionné dans la partie 51, une vue d’un premier fichier joint dans la partie 50 et un formulaire d’initialisation dans la partie 52 de la zone dédiée 5. le formulaire d’initialisation dans une partie de l’interface application 150, le formulaire d’initialisation comprenant un ensemble de champs tels que par exemple les champs d’une application pour un rapport de frais : « date », « pays », « adresse », « sous-type de reçu », « prix total », « devise ». Dans un mode de réalisation, les champs du formulaire d’initialisation peuvent être générés de façon dynamique comme une fonction de données d’initialisation comprenant un ensemble de clés extraites à partir du dispositif de traitement de données cible 2 par le dispositif orchestrateur 18 et/ou à partir du sous-type de reçu correspondant au fichier joint actuel 121 (celui qui est affiché dans la partie 50). Autrement, le formulaire d’initialisation peut être un formulaire par défaut défini par le dispositif de traitement cible 2.
Dans un mode de réalisation, le dispositif orchestrateur 18 peut se connecter à une étape initiale du traitement au dispositif de traitement de données cible 2 pour récupérer une liste des sous-types de fichiers joints pris en charge par le dispositif de traitement de données cible 2 et/ou des transactions en cours relatives à l’utilisateur afin d’adapter les champs du formulaire de façon dynamique. Par exemple, si le dispositif de traitement de données cible 2 est un outil de rapport de frais, le dispositif orchestrateur peut comprendre la récupération de la liste des sous-types de reçus pris en charge (ou nécessaires ou configurés selon le besoin) par l’outil de rapport de frais et/ou l’ensemble des relevés de frais en cours de l’utilisateur.
À l’étape 808, le dispositif orchestrateur 18 peut se connecter au serveur de messagerie 11. Dans d’autres modes de réalisation, l’orchestrateur 18 peut être connecté automatiquement au serveur messagerie sans nécessiter la mise en œuvre de l’étape spécifique 808.
À l’étape 809 le serveur de messagerie 11 peut transmettre au moins un sousensemble des fichiers joints 121 au dispositif orchestrateur 18. Dans un mode de réalisation, le serveur de messagerie 11 peut seulement transmettre au dispositif orchestrateur les fichiers ayant un format non structuré parmi les fichiers joints 121. Dans un autre mode de réalisation, le serveur de messagerie 11 peut transmettre au dispositif orchestrateur 18 tous les fichiers joints 121, les fichiers joints étant ensuite filtrés par le dispositif orchestrateur 18 pour filtrer uniquement un sous-ensemble de fichiers joints selon des critères prédéfinis, les critères de filtrage comprenant au moins le filtrage des fichiers joints ayant un format non structuré parmi les fichiers joints 121.
Dans une application de rapport de frais de l'invention, chaque fichier joint d’un sousensemble peut être un reçu (p. ex. une photo ou le résultat d’une numérisation) tel qu’un reçu de taxi ou d’hôtel ou un reçu pour des dépenses non liées au voyage (p. ex. un ordinateur, un dîner avec des clients, un lot de photocopies).
À l’étape 810 le dispositif orchestrateur 18 peut convertir chaque fichier joint dans un format cible par exemple pour fournir un fichier joint dont la taille est la plus petite et/ou des poids pour optimiser leur affichage par l’application. Par exemple, un fichier joint au format PDF peut être converti en fichier JPEG.
À l’étape 811, le dispositif orchestrateur 18 peut envoyer chaque fichier joint dans un ce format cible à l’application de messagerie 15 fonctionnant sur le dispositif client 14.
L’extension d’application 152 peut ensuite afficher une vue d’initialisation dans la zone dédiée 5 de l’interface application 150, la vue d’initialisation comprenant un affichage de chaque fichier joint reçu par le dispositif orchestrateur 18 sous forme de vignette dans la partie 51 de la zone dédiée, chaque vignette étant une image sur laquelle on peut cliquer.
La vue d’initialisation peut par exemple comprendre une vignette pour chaque fichier joint sélectionné dans la partie 51, une vue d’un des fichiers joints dans la partie 50 et un formulaire d’initialisation dans la partie droite de la zone dédiée. Le formulaire d’initialisation peut comprendre un ensemble de champs tels que par exemple les champs d’une application de rapport de frais : « date », « pays », « sous-type de reçu », « prix total », « devise ». Dans un mode de réalisation, les champs du formulaire d’initialisation peuvent être générés de façon dynamique comme une fonction de données d’initialisation comprenant un ensemble de clés extraites à partir du dispositif de traitement de données cible 2 par le dispositif orchestrateur 18 et/ou à partir du sous-type de reçu correspondant au fichier joint actuel 121 tel qu’il est affiché dans la partie 52 de la zone dédiée 5. Autrement, le formulaire d’initialisation peut être un formulaire par défaut défini par le dispositif de traitement cible 2. Le fichier joint affiché dans la partie gauche peut être sélectionné au hasard par l’extension d’application 2 ou correspondre à la première vignette affichée dans la partie du milieu de l’interface d’application ou correspondre à une vignette sélectionnée par l’utilisateur dans la partie 51 de la zone dédiée 5 (lorsqu’il clique dessus).
Le traitement du fichier joint affiché dans la partie 50 par le dispositif orchestrateur 18 peut être déclenché automatiquement.
La Figure 9 est un organigramme décrivant le processus d’intégration d’un fichier joint 121 dans le dispositif de traitement cible 2 mis en œuvre par le dispositif orchestrateur 18 conformément à certains modes de réalisation.
À l’étape 900 le traitement du fichier joint actuel est demandé par l’application, par exemple en réponse à la sélection d’un fichier dans la partie 51 de la zone dédiée ou automatiquement par une sélection d’un fichier par l’extension d’application 152 ou par le dispositif orchestrateur 18.
À l’étape 902, pour le fichier joint actuel, le dispositif orchestrateur 18 peut demander le fichier joint correspondant au serveur de messagerie 11 si le dispositif orchestrateur 18 ne l’a pas stocké précédemment.
À l’étape 904, le dispositif orchestrateur 18 reçoit l'image correspondante.
À l’étape 905, le dispositif orchestrateur 18 transfère le fichier joint au dispositif de traitement de fichier 19. Dans des modes de réalisation, plutôt que de transmettre le fichier joint tel qu’il est récupéré à partir du serveur de messagerie 11 ou à partir d’une mémoire conservée par le dispositif orchestrateur 18, le dispositif orchestrateur 18 peut antérieurement appliquer un prétraitement pour récupérer l’image et adapter son format ou sa qualité.
La Figure 10 est un organigramme décrivant le processus mis en œuvre par le dispositif de traitement de fichier selon certains modes de réalisation.
À l’étape 1000, un fichier joint dans un format pris en charge par le dispositif de traitement de fichier est reçu en provenance du dispositif orchestrateur 18 (p. ex. pdf, format d’image). Dans des modes de réalisation, le fichier joint 190 peut être préalablement traité pour optimiser son traitement.
À l’étape 1001, au moins un algorithme d’extraction, OCR par exemple, est appliqué au fichier joint pour extraire des caractères et/ou les données de positionnement du fichier 190.
Aux étapes 1002 à 1005, les données extraites du fichier joint sont analysées et structurées en un fichier de description conforme à une structure de donnée prédéfinie comprenant un ensemble de clés.
Spécifiquement, l’étape 1002 peut comprendre l’analyse des données extraites pour mapper chaque clé d’un ensemble prédéfini de clés à un ou plusieurs éléments de donnée des données extraites à partir du fichier joint reçu, chaque élément de donnée mappé représentant une valeur candidate pour une clé.
L’étape 1003 peut comprendre le calcul d’une notation pour chaque valeur candidate attribuée à une clé.
Dans des modes de réalisation, l’étape de mappage et/ou l’étape de notation peuvent être réalisées en utilisant l’apprentissage automatique des données.
Dans un mode de réalisation, l’étape 1004 peut comprendre le calcul d’un ensemble de données de positionnement pour chaque valeur candidate déterminée pour une ou plusieurs clés, l’ensemble de données de positionnement déterminé pour une valeur candidate représentant la position de la valeur candidate dans le fichier joint. Les données de positionnement déterminées pour un élément de donnée donné peuvent inclure les coordonnées dans un référentiel donné défini par rapport au fichier non modifiable.
À l’étape 1005, le fichier de description tel qu’il est généré peut être renvoyé au dispositif orchestrateur 18.
La Figure 11 est une vue d’un extrait d’un exemple de fichier de description 190 au format JSON (pseudocode).
Tel qu’il est présenté, le fichier de description 190 comprend un ensemble de clés, chacune ayant une ou plusieurs valeurs candidates déterminées par le dispositif de traitement de fichier 19, chaque valeur candidate étant associée à une notation représentant le niveau de pertinence de la valeur candidate déterminée par le dispositif de traitement de fichier. Chaque clé est par ailleurs associée à un ensemble de données de positionnement représentant la position de l’élément de donnée correspondant dans le fichier joint d’origine 121.
La Figure 12 est un organigramme décrivant le processus d’affinement d’un fichier de description selon des modes de réalisation.
À l’étape 1200, le fichier de description 191 est reçu par le dispositif orchestrateur 18 à partir du dispositif de traitement de fichier 19.
À l’étape 1202, un fichier de description 181 déterminé à partir du fichier de description 191 peut être transmis à partir du dispositif orchestrateur 18 à l’application 15 du dispositif client 14 (le fichier de description 181 peut être le fichier de description 191 lui-même, ou une version transformée du fichier de description 191). Dans certains modes de réalisation, le fichier joint correspondant 121 peut être transmis simultanément à l’application.
À l’étape 1204, un affichage du fichier de description 181 peut être généré par l’extension d’application 152 sous la forme d’un formulaire de vérification, dans la partie 52 de la zone dédiée 5. Le fichier joint correspondant 121 (p. ex. un reçu) peut être affiché sous forme d’image dans la partie 50 de la zone dédiée pour permettre une vérification par l’utilisateur s’il n’a pas été affiché pendant la phase d’initialisation. Le formulaire comprend un ensemble de champs, chaque champ correspondant à une clé du fichier de description. Si une vue initiale du formulaire était affichée au lancement de l’extension d’application 152, les champs du formulaire peuvent être mis à jour à partir du contenu du fichier de description de contenu 181 à l’étape 1204. Pour chaque champ du formulaire, la valeur candidate ayant la notation la plus élevée pour la clé correspondant au champ du formulaire dans le fichier de description 181 peut être attribuée à la valeur du champ. Dans certains modes de réalisation, les autres valeurs candidates peuvent être mises en évidence ou affichées en utilisant des éléments visuels dans la zone dédiée pour mettre en avant la pertinence de la valeur candidate en fonction de la notation déterminée pour cette valeur. Dans un mode de réalisation, les éléments visuels peuvent être les cases de mise en évidence 55 cliquables qui sont superposées directement sur l’image représentant le fichier joint dans la partie 50 de la zone dédiée 5, la position de la case de mise en évidence étant déterminée à partir de l’ensemble de données de positionnement associé à la valeur candidate dans le fichier de description 181.
À l’étape1205, l’extension d’application peut mettre à jour la valeur d’un champ donné du formulaire dans la partie 52 de la zone dédiée 5, en réponse à la sélection d’une autre valeur candidate par l’utilisateur qui utilise les éléments visuels 55, par exemple en cliquant sur une des cases de mise en évidence dans la partie RO de la zone dédiée 5 en réponse à une correction faite par l’utilisateur (par saisie textuelle) directement dans le formulaire de vérification affiché dans la partie 52 de la zone dédiée 5. L’utilisateur peut par ailleurs saisir des valeurs pour les champs vides si aucune valeur n’a été déterminée pour une clé. L’étape 1205 peut être itérée pour une ou plusieurs clés jusqu’à ce que l’utilisateur valide le formulaire par exemple en cliquant sur un bouton de validation (520). La saisie de l’utilisateur peut aussi faire l’objet des mêmes vérifications que les vérifications effectuées par le dispositif de traitement de fichier 19 pour les données extraites. Par exemple, le numéro d’IBAN saisi par l’utilisateur subira la même somme de vérification que celle effectuée par le dispositif de traitement de fichier 19.
À l’étape 1206, l’extension d’application peut se connecter au serveur de messagerie 11 pour requérir les données d’authentification, telles qu’un mot de passe et un identifiant, donnant accès au dispositif de traitement de données cible 2 dans les modes de réalisation où ces données d’authentification sont stockées dans le serveur de messagerie 11 ou dans une base de données externe. Autrement, ces données d’authentification peuvent être demandées par le dispositif orchestrateur 18 directement.
À l’étape 1208, le formulaire, éventuellement avec les données d’authentification, peut être soumis au dispositif orchestrateur 18 avec les valeurs de champ actualisées.
À l’étape 1210, le fichier de description 191 peut être mis à jour en utilisant les valeurs corrigées ou en sélectionnant la valeur ayant la notation la plus élevée pour chaque clé pour laquelle l’utilisateur n’a pas corrigé les valeurs ce qui permet d’obtenir un fichier de description affiné.
Un fichier de description 182 déterminé à partir du fichier de description affiné peut être généré par le dispositif orchestrateur 18. Le fichier de description déterminé 182 (également désigné comme « fichier de description validé ») peut être le fichier de description affiné luimême ou une version transformée du fichier de description.
Le fichier de description validé 182 peut ensuite être transmis au dispositif de traitement de données cible 2 par le dispositif orchestrateur 18 pour traitement par le dispositif de traitement de données cible 2 à l’étape 1212. L’étape 1214 peut par ailleurs comprendre la transmission du fichier joint d’origine 121 au dispositif de traitement de données cible 2 dans le format d’origine ou dans le format requis par le dispositif de traitement de données cible.
Dans un mode de réalisation, un fichier de description 183 déterminé à partir du fichier de description affiné peut par ailleurs être transmis au dispositif de traitement de fichier 19 dans un format pris en charge par le dispositif de traitement de fichier pour permettre la collection de données de méta-apprentissage par le dispositif de traitement de fichier 19 à l’étape 1216 (le fichier de description 183 peut comprendre le même contenu que le fichier de description 182 avec le même format ou un autre format, ou comprendre des données supplémentaires). Ces données de méta apprentissage peuvent être utilisées par le dispositif de traitement de fichier 19 pour la prochaine transformation de fichiers joints. Les données de métaapprentissage peuvent être utilisées pour déterminer les valeurs candidates. Par exemple, si le reçu est un reçu de taxi et une des clés est le prix du reçu pour un itinéraire donné d’un lieu A à un lieu B, la donnée de méta-apprentissage collectée peut comprendre le prix moyen pour cet itinéraire.
Un tel retour collecté auprès de l’utilisateur peut être utilisé par le dispositif de traitement de fichier 19 pour déterminer l’exactitude des extractions de données en comparant le fichier de description renvoyé par le dispositif de traitement de fichier avec le fichier de description affiné par l’utilisateur. Ces données de méta-apprentissage peuvent être stockées et utilisées pour continuer à améliorer le système. En utilisant les données de retour stockées, le dispositif de traitement de fichier 19 peut être reformé de façon continue. Par exemple, afin de perfectionner le composant « notation de la clé de montant» de l’unité de notation 197, les retours provenant du stockage des résultats combinés aux résultats intermédiaires qui sont utilisés pour générer les propriétés de montant dans le composant de notation de montant, peuvent être collectés. Le composant de notation des montants peut être relancé et ses résultats peuvent être comparés avec les données de retour d’information. S’il y a des différences, les poids utilisés dans le composant de notation de montant peuvent être mis à jour.
Dans une application de gestion de rapport de frais, le dispositif de traitement de données cible 2 (outil de gestion/rapport de frais) peut par conséquent gérer les reçus pour soumettre une demande de remboursement pour l’utilisateur, après vérification de la validité des frais (par exemple s’ils sont associés à un voyage existant) et/ou son unicité (par exemple, si deux utilisateurs ont soumis le même reçu). Dans un mode de réalisation, ce dispositif de traitement de données cible 2 peut envoyer un retour à l’utilisateur via le dispositif orchestrateur pour indiquer par exemple que des frais correspondant à un reçu traité est en cours de traitement et/ou une demande de remboursement a été déclenchée et/ou que le reçu transmis a déclenché une erreur de validité d’unicité.
On notera que même si certains aspects techniques de l’invention ont été décrits en combinaison, ils peuvent cependant être utilisés séparément dans certaines applications. En particulier alors que le dispositif de traitement de fichier a été décrit en lien avec l’utilisation d’une application de messagerie, l’homme de métier comprendra aisément que dans certains modes de réalisation le dispositif de traitement de fichier 19 peut être utilisé indépendamment pour convertir un fichier d’entrée non structuré tel qu’une image ou un fichier PDF en un fichier de description structuré.
Les modes de réalisation de l’invention peuvent être mis en œuvre sur un système informatique comprenant un ou plusieurs ordinateurs ou serveurs en réseau.
Faisant référence maintenant à la figure 13, le dispositif client 14, le serveur de messagerie 11, le dispositif orchestrateur 18, le dispositif de traitement de fichier 19 et le dispositif de traitement cible peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, désignés collectivement comme un ordinateur, tel que l’ordinateur 30. L’ordinateur 30 peut inclure un processeur 32, une mémoire 34, un dispositif de mémoire de stockage de masse 36, une interface entrée/sortie (I/O) 38, et une interface homme-machine (HMI) 39. L’ordinateur 30 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources extérieures 42 par l’intermédiaire du réseau 6 et/ou de l’interface I/O 38. Les ressources externes peuvent inclure mais sans s’y limiter, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée qui peut être utilisée avec l’ordinateur 30.
Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : microprocesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basés sur des instructions de fonctionnement enregistrées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment mais sans s’y limiter, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l’antémémoire (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de stockage de masse 36 peut inclure des dispositifs de stockage de données tels qu’un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l’état solide volatile ou non volatile ou tout autre dispositif capable de stocker des informations. Une base de données 44 peut résider sur le dispositif de mémoire de stockage de masse 36, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes.
Le processeur 32 peut fonctionner sous le contrôle d’un système d’exploitation 46 qui réside dans la mémoire 34. Le système d’exploitation 46 peut gérer les ressources informatiques de sorte que le code de programme de l’ordinateur, intégré sous forme d’un ou plusieurs logiciels d’application, tels que l’application 48 qui réside dans la mémoire 34, puisse disposer d’instructions exécutées par le processeur 32. Dans un mode de réalisation alternatif, le processeur 32 peut exécuter directement l’application 48 ; dans ce cas le système d’exploitation 46 peut être omis. Une ou plusieurs structures de donnée 49 peuvent également résider dans la mémoire 34, et peuvent être utilisées par le processeur 32, le système d’exploitation 46, ou l’application 48 pour stocker ou manipuler des données.
L’interface I/O 38 peut fournir une interface machine qui couple le processeur 32 de façon fonctionnelle avec d’autres dispositifs et systèmes, tels que le réseau 6 et/ou la ressource externe 42. L’application 48 peut ainsi collaborer avec le réseau 6 et/ou avec la ressource externe 42 en communiquant par l’intermédiaire de l'interface I/O 38 pour fournir les divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l’invention. L’application 48 peut aussi comporter un code de programme qui est exécuté par une ou plusieurs ressources externes 42, ou repose autrement sur les fonctions et/ou signaux fournis par d’autres composants de système ou de réseau externes à l’ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l’invention peuvent inclure des applications situées à l’extérieur de l’ordinateur 30, distribuées à des ordinateurs multiples ou à d’autres ressources externes 42 ou fournies par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel qu’un service informatique en nuage, par l’intermédiaire du réseau 6.
Le ΗΜΙ 39 (tel que le HMI 30 dans l’implémentation de la figure 1 du dispositif client
3) peut être couplé de façon fonctionnelle au processeur 32 de l’ordinateur 30 d’une façon connue pour permettre à un utilisateur de l’ordinateur 30 d’interagir directement avec l’ordinateur 30. Le HMI 39 peut inclure des affichages vidéo et/ou alphanumériques, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des informations à l’utilisateur. Le HMI 39 peut aussi inclure des dispositifs d’entrée et des contrôles tels qu’un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d’accepter des commandes ou des saisies de l’utilisateur, et de transmettre les entrées saisies au processeur 32.
La base de données 44 peut résider sur le dispositif de mémoire de de stockage de masse 36, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. La base de données 44 peut inclure des données et accommoder les structures de données associées qui stockent et organisent les données. En particulier, la base de données 44 peut être aménagée avec toute organisation ou structure de base de données, notamment mais sans s’y limiter, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, une base de données orientée objet ou des combinaisons de celles-là. Un système de gestion de base de données sous forme de logiciel informatique d’application qui s’exécute sous la forme d’instructions sur le processeur 32 peut être utilisé pour accéder aux informations ou aux données stockées dans des fichiers de la base de données 44 en réponse à une interrogation, lorsqu’une interrogation peut être déterminée de façon dynamique et exécutée par le système d’exploitation 46, les autres applications 48, ou un ou plusieurs modules. Bien que des modes de réalisation de l’invention puissent être décrits dans les présentes en utilisant une terminologie de base de données relationnelle, hiérarchique, de réseau, orientée objet ou autre terminologie dans des cas spécifiques, les hommes de métier comprendront que les modes de réalisation de l’invention peuvent utiliser tout modèle approprié de gestion de base de données, et ne sont pas limités à tout type particulier de base de données.
Le code de programme qui met en œuvre un quelconque des modes de réalisation décrits dans les présentes peut être distribué individuellement ou collectivement comme un produit-programme, sous une variété de formes. En particulier, le code de programme peut être distribué en utilisant des supports lisibles par ordinateur qui peuvent inclure des supports de stockage et des supports de communication lisibles par ordinateur. Les supports de stockage lisibles par ordinateur, étant intrinsèquement non transitoires, peuvent inclure des supports tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage des informations, tels que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou d’autres données. Les supports de stockage lisibles par ordinateur peuvent aussi inclure des mémoires RAM, ROM, une mémoire à lecture exclusivement, programmable et effaçable (EPROM), une mémoire à lecture exclusivement, programmable et effaçable électriquement (EEPROM), une mémoire flash, ou toute technologie de support solide de mémoire, un disque compact portable doté d’une mémoire à lecture seule (CD-ROM) ou tout autre stockage optique, des cassettes magnétiques, des bandes d’enregistrement magnétique ou d’autres dispositifs de stockage magnétique, ou tout autre support pouvant être utilisé pour stocker l’information désirée et apte à être lu par un ordinateur. Les supports de communication peuvent mettre en œuvre des instructions lisibles par ordinateur, des structures de donnée, ou d’autres modules de programme. À titre d’exemple, mais sans restriction, un support de communication peut inclure des supports filaires tels qu’un réseau filaire ou à connexion filaire directe et des supports sans fil tel que des supports acoustiques, RF, infrarouge ou autres supports sans fil. Des combinaisons de tout ce qui a été décrit ci-dessus peuvent aussi être incluses dans la gamme des supports lisibles par ordinateur.
Les procédés décrits dans les présentes peuvent être mis en œuvre par des instructions de programmes informatiques fournis par le processeur de tout type d’ordinateur pour produire une machine avec un processeur qui exécute des instructions afin d’implémenter les fonctions/actions spécifiées dans les présentes. Ces instructions de programmes informatiques peuvent aussi être stockées sur un support lisible par ordinateur qui peut instruire un ordinateur pour fonctionner de façon particulière. Dans ce but, les instructions de programmes informatiques peuvent être chargées sur un ordinateur pour entraîner la mise en œuvre d’une série d’étapes opérationnelles et produire ainsi un processus mis en oeuvre par ordinateur, de sorte que les instructions exécutées fournissent les processus pour mettre en œuvre des fonctions/actions spécifiées dans les présentes.
De plus, le code de programme décrit dans les présentes peut être identifié sur la base de l’application ou du composant logiciel dans lequel le code de programme est implémenté dans un mode de réalisation spécifique de l’invention. Cependant, on notera que toute nomenclature d’un programme particulier qui suit est utilisée uniquement par commodité ; ainsi l’invention ne peut être limitée à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. On comprendra par ailleurs que les applications et caractéristiques variées et dispositifs révélés dans les présentes peuvent aussi être utilisés seuls ou dans toute combinaison. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sousprogrammes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d’affecter les fonctionnalités d’un programme parmi diverses couches de logiciels qui résident dans un système informatique typique [par ex., les systèmes d’exploitation, les bibliothèques, les interfaces d’application de programme (API), les applications, les petites applications (applets), etc.], et/ou entre une ou plusieurs plateformes de matériel, on notera que l’invention n’est pas limitée à l’organisation spécifique et à l’affectation des fonctionnalités de programme décrites dans les présentes.
Bien que les modes de réalisation de l’invention soient illustrés par une description de divers exemples et bien que ces modes de réalisation soient décrits de façon très détaillée dans les présentes, il n'est pas de l’intention du demandeur de restreindre ou de se limiter à ces détails, de quelque façon que ce soit, la portée des revendications en annexe. Des avantages supplémentaires et des modifications supplémentaires apparaîtront aisément aux hommes de métier. L’invention sous un angle plus large n’est donc pas limitée aux détails spécifiques, aux procédés et aux appareils représentatifs, et aux illustrations montrées et décrites à titre d’exemple.

Claims (12)

1. Un système d’intégration de contenu d’un message dans un dispositif de traitement cible (2), ledit dispositif de traitement cible (2) étant configuré pour traiter une donnée de saisie ayant une structure de donnée prédéfinie, le système comprenant un serveur de messagerie (11) configuré pour recevoir un message provenant d’un dispositif client de messagerie (14) qui exécute une application de messagerie (15) ledit message comprenant un contenu de message, dans lequel le système comprend par ailleurs un dispositif de traitement de fichier (19) et un dispositif orchestrateur (18) configuré pour intégrer au moins une partie du contenu du message dans le dispositif de traitement de données cible (2), ledit dispositif orchestrateur (18) étant par ailleurs configuré pour :
- recevoir la partie du contenu de message du serveur de messagerie (1) ; et
- transmettre un fichier déterminé à partir de ladite partie du contenu du message vers un dispositif de traitement de fichier (19), ledit dispositif de traitement de fichier étant configuré pour transformer chaque fichier reçu (190) en un fichier de description (191) comprenant un ensemble de clés prédéfinies, aux moins certaines des clés étant associées à une ou plusieurs valeurs, le dispositif orchestrateur (18) étant configuré pour déterminer un fichier d’entrée (190) ayant la structure de donnée prédéfinie à partir dudit fichier de description (191) et pour transmettre le fichier d’entrée déterminé (182) vers le dispositif de traitement de données cible (2) pour traitement du fichier d’entrée déterminé par le dispositif de traitement cible.
2. Le système selon la revendication 1, dans lequel le dispositif orchestrateur (18) est connecté au serveur de messagerie (11) selon un premier protocole de communication, à l’application de messagerie (150) selon un second protocole, et au dispositif de traitement de données cible (2) selon un troisième protocole de communication.
3. Le système selon la revendication 2, dans lequel l’application de messagerie (15) comprend une interface d’application (150) et une extension d’application (152) configurée pour générer une restitution d’un fichier d’entrée déterminé du fichier de description (191) fourni par le dispositif de traitement de fichier (19) dans une zone dédiée (5) de l’interface d’application (150).
4. Le système selon l’une quelconque des revendications précédentes, dans lequel le dispositif de traitement de fichier (19) est configuré pour mapper un ou plusieurs éléments de donnée de ladite partie du contenu du message à au moins certaines clés d’un ensemble prédéfini de clés, le dispositif de traitement de fichier étant configuré pour générer ledit fichier de description à partir de ladite partie du contenu du message, ladite description de fichier comprenant ledit ensemble de clés prédéfinies, ladite une ou plusieurs valeurs associées auxdites clés du fichier de description déterminé à partir des éléments de donnée qui y sont mappés.
5. Le système selon la revendication 4, dans lequel le dispositif de traitement de fichier (19) est par ailleurs configuré pour déterminer des ensembles de données de positionnement à partir dudit fichier reçu du dispositif orchestrateur (18), chaque ensemble de données de positionnement identifiant la position d’un élément de donnée du fichier en mappant une clé dudit ensemble de clés prédéfinies, chaque ensemble de données de positionnement étant inclus dans ledit fichier de description qui est associé à la clé mappée à l’élément de donnée.
6. Le système selon la revendication 5, dans lequel chaque ensemble de données de positionnement comprend des coordonnées de positionnement dans un référentiel donné.
7. Le système selon l’une quelconque des revendications précédentes 3 à 6, dans lequel ladite interface d’application (150) est une application de l’interface graphique, ladite extension d’application (152) étant configurée pour rendre le fichier de description dans une zone dédiée de ladite interface d’application (150).
8. Le système selon l’une quelconque des revendications précédentes 4 à 7, dans lequel le dispositif de traitement de fichier (19) est par ailleurs configuré pour déterminer une notation pour chaque valeur associée à une clé donnée dudit ensemble prédéfini de clés, le dispositif de traitement de fichier étant par ailleurs configuré pour inclure la notation déterminée pour la valeur associée à ladite clé donnée dans le fichier de description.
9. Le système selon la revendication 8, dans lequel ladite extension d’application (152) est par ailleurs configurée pour afficher une image de la partie de contenu du message dans ladite zone dédiée et pour générer l’affichage d’un ou de plusieurs éléments sélectionnâmes de mise en évidence des éléments pour chaque élément de donnée de la partie de contenu du message en mappant une clé, chaque élément de mise en évidence pour un élément de donnée donné étant affiché sur une position dans l’image affichée qui est déterminée à partir de l’ensemble des données de positionnement identifiant la position dudit élément de donnée.
10. Le système selon l’une quelconque des revendications précédentes, dans lequel le dispositif orchestrateur (18) est configuré pour utiliser un identifiant de message associé au message pour chaque échange entre le dispositif orchestrateur (18) et le serveur de messagerie (11), et/ou l’extension d’application (152), et/ou le dispositif de traitement de fichier (19) et/ou le dispositif de traitement de données cible (2).
11. Un procédé pour intégrer du contenu de message dans un dispositif de traitement cible (2), ledit dispositif de traitement de données cible (2) étant configuré pour traiter une donnée d’entrée ayant une structure de donnée prédéfinie, le procédé comprenant la réception d’un message provenant d’un dispositif client de messagerie (14) qui exécute une application de messagerie (15), ledit message comprenant le contenu du message ;
dans lequel le procédé comprend l’intégration d’au moins une partie de contenu du message dans ledit dispositif de traitement de données cible (2), ledit procédé étant par ailleurs configuré pour déterminer un fichier déterminé à partir de ladite partie de contenu du message et pour transformer ledit fichier (190) en un fichier de description (191) comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, le procédé comprenant la dérivation d’un fichier d’entrée (190) ayant ladite structure de donnée prédéfinie à partir dudit fichier de description (191) et transmettre ledit fichier d’entrée déterminé (182) au dispositif de traitement de données cible (2) pour traitement du fichier d’entrée déterminé par le dispositif de traitement cible.
12. Un produit-programme d’ordinateur comprenant :
un support non transitoire de stockage lisible par ordinateur ; et des instructions stockées sur un support de stockage non transitoire, lisible par ordinateur qui, lorsqu’il est exécuté par un processeur, amène le processeur à intégrer du contenu de message dans un dispositif de traitement de données cible (2), ledit dispositif de traitement de données cible (2) étant configuré pour traiter la donnée d’entrée ayant une structure de donnée prédéfinie, le processeur étant par ailleurs amené à :
- recevoir un message en provenance d’un dispositif client de messagerie (14) qui exécute une application de messagerie (15), ledit message comprenant un contenu de message ;
- intégrer au moins une partie du contenu de message dans ledit dispositif de traitement de données cible (2), le processeur étant par ailleurs amené à déterminer un fichier déterminé à partir de ladite partie de contenu de message et à transformer ledit fichier (190) en un fichier de description (191) comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs,
- déterminer un fichier d’entrée (190) ayant ladite structure de données prédéfinie à partir dudit fichier de description (191) et transmettre ledit fichier d’entrée déterminé (182) au dispositif de 5 traitement de données cible (2) pour traitement du fichier d’entrée déterminé par le dispositif de traitement cible.
FR1756717A 2017-07-13 2017-07-13 Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees Active FR3069075B1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR1756717A FR3069075B1 (fr) 2017-07-13 2017-07-13 Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees
CN201880053503.1A CN110999264B (zh) 2017-07-13 2018-07-06 用于将消息内容集成到目标数据处理设备中的系统和方法
PCT/EP2018/068373 WO2019011804A1 (fr) 2017-07-13 2018-07-06 Système et procédé d'intégration d'un contenu de message dans un dispositif de traitement de données cible
AU2018299826A AU2018299826B2 (en) 2017-07-13 2018-07-06 System and method for integrating message content into a target data processing device
NZ760613A NZ760613B2 (en) 2017-07-13 2018-07-06 System and method for integrating message content into a target data processing device
US16/629,464 US11436192B2 (en) 2017-07-13 2018-07-06 System and method for integrating message content into a target data processing device
EP18734843.8A EP3652917B1 (fr) 2017-07-13 2018-07-06 Système et procédé d'intégration d'un contenu de message dans un dispositif de traitement de données cible
US17/872,061 US11736587B2 (en) 2017-07-13 2022-07-25 System and method for integrating message content into a target data processing device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1756717 2017-07-13
FR1756717A FR3069075B1 (fr) 2017-07-13 2017-07-13 Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees

Publications (2)

Publication Number Publication Date
FR3069075A1 true FR3069075A1 (fr) 2019-01-18
FR3069075B1 FR3069075B1 (fr) 2021-02-19

Family

ID=60923555

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1756717A Active FR3069075B1 (fr) 2017-07-13 2017-07-13 Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees

Country Status (6)

Country Link
US (2) US11436192B2 (fr)
EP (1) EP3652917B1 (fr)
CN (1) CN110999264B (fr)
AU (1) AU2018299826B2 (fr)
FR (1) FR3069075B1 (fr)
WO (1) WO2019011804A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110138992A (zh) * 2018-02-08 2019-08-16 精工爱普生株式会社 收据处理装置、程序的存储介质以及报告的制作方法
US11543943B2 (en) * 2019-04-30 2023-01-03 Open Text Sa Ulc Systems and methods for on-image navigation and direct image-to-data storage table data capture
FR3099605B1 (fr) * 2019-08-02 2021-12-17 Amadeus Sas Dispositif, système et procédé pour traiter des images qui incluent des montants
US11461534B2 (en) * 2019-12-31 2022-10-04 Tech Footing, Llc System for dynamically generating content for professional reports based on continuously updated historical data
CN112134785B (zh) * 2020-09-14 2021-11-02 上海纽盾科技股份有限公司 网络安全等级保护中的信息处理方法、客户端及系统
CN114418551A (zh) * 2022-01-29 2022-04-29 北京字跳网络技术有限公司 一种票据处理方法、装置、电子设备和存储介质
CN114895987B (zh) * 2022-07-08 2022-09-30 英诺达(成都)电子科技有限公司 消息处理方法、装置、设备及计算机存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060089907A1 (en) * 2004-10-22 2006-04-27 Klaus Kohlmaier Invoice verification process
EP2634735A1 (fr) * 2012-03-01 2013-09-04 Ricoh Company, Ltd. Système de notes de frais avec traitement d'image avec réception
WO2014022919A1 (fr) * 2012-08-10 2014-02-13 Transaxy Inc. Système pour entrer des données dans un système de traitement de données
US20140288981A1 (en) * 2013-03-20 2014-09-25 Concur Technologies, Inc. Methods and systems for travel-based interactions

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8094976B2 (en) * 2007-10-03 2012-01-10 Esker, Inc. One-screen reconciliation of business document image data, optical character recognition extracted data, and enterprise resource planning data
US9244698B2 (en) * 2010-09-14 2016-01-26 Microsoft Technology Licensing, Llc Download bar user interface control
US9602453B2 (en) * 2011-02-10 2017-03-21 International Business Machines Corporation Smart attachment to electronic messages
US20120278728A1 (en) * 2011-04-29 2012-11-01 Sling Media Inc. Download monitoring in a media distribution system
US8990112B2 (en) * 2012-03-01 2015-03-24 Ricoh Company, Ltd. Expense report system with receipt image processing
US10332213B2 (en) * 2012-03-01 2019-06-25 Ricoh Company, Ltd. Expense report system with receipt image processing by delegates
US9165068B2 (en) * 2012-08-03 2015-10-20 Adobe Systems Incorporated Techniques for cloud-based similarity searches
US11126720B2 (en) * 2012-09-26 2021-09-21 Bluvector, Inc. System and method for automated machine-learning, zero-day malware detection
FR3021790B1 (fr) * 2014-05-30 2022-10-14 Amadeus Sas Procede et systeme d'echange de contenu
RU2613734C1 (ru) * 2015-10-22 2017-03-21 Общество с ограниченной ответственностью "Аби Девелопмент" Захват видео в сценарии ввода данных
US20170255974A1 (en) * 2016-03-02 2017-09-07 Paypal, Inc. Context aware transaction management system
GB2555192B (en) * 2016-08-02 2021-11-24 Invincea Inc Methods and apparatus for detecting and identifying malware by mapping feature data into a semantic space

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060089907A1 (en) * 2004-10-22 2006-04-27 Klaus Kohlmaier Invoice verification process
EP2634735A1 (fr) * 2012-03-01 2013-09-04 Ricoh Company, Ltd. Système de notes de frais avec traitement d'image avec réception
WO2014022919A1 (fr) * 2012-08-10 2014-02-13 Transaxy Inc. Système pour entrer des données dans un système de traitement de données
US20140288981A1 (en) * 2013-03-20 2014-09-25 Concur Technologies, Inc. Methods and systems for travel-based interactions

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ADITHYA KAVULURU: "Fyle Extension on Outlook", YOU TUBE, 26 December 2016 (2016-12-26), pages 1, XP054978361, Retrieved from the Internet <URL:https://www.youtube.com/watch?v=BfkfMsiKoKk> [retrieved on 20180517] *
DISHA SHARMA: "Expense management startup Fyle Technologies raises $400K from Pravega, others", 14 February 2017 (2017-02-14), XP055476358, Retrieved from the Internet <URL:https://techcircle.vccircle.com/2017/02/14/expense-management-startup-fyle-technologies-raises-400k-from-pravega-others/> [retrieved on 20180517] *
MICROSOFT: "Fyle - One Click Expense Management", 22 December 2016 (2016-12-22), XP055476377, Retrieved from the Internet <URL:https://appsource.microsoft.com/en-us/product/office/WA104380673?tab=Overview> [retrieved on 20180517] *
SHADMA SKAIKH: "Expense management platform Fyle Technologies raises Rs 2.7 cr in a seed round", 14 February 2017 (2017-02-14), XP055476332, Retrieved from the Internet <URL:https://economictimes.indiatimes.com/small-biz/money/expense-management-platform-fyle-technologies-raises-rs-2-7-cr-in-a-seed-round/printarticle/57139677.cms> [retrieved on 20180517] *
YASHWANTH MADHUSUDAN: "Fyle with Outlook", 4 January 2017 (2017-01-04), XP055476341, Retrieved from the Internet <URL:https://blog.fyle.in/fyle-with-outlook-5d11c5e99f6> [retrieved on 20180517] *

Also Published As

Publication number Publication date
US11736587B2 (en) 2023-08-22
US11436192B2 (en) 2022-09-06
US20200142862A1 (en) 2020-05-07
CN110999264A (zh) 2020-04-10
US20220358091A1 (en) 2022-11-10
WO2019011804A1 (fr) 2019-01-17
CN110999264B (zh) 2022-10-11
FR3069075B1 (fr) 2021-02-19
AU2018299826A1 (en) 2020-01-30
EP3652917A1 (fr) 2020-05-20
NZ760613A (en) 2021-11-26
AU2018299826B2 (en) 2021-10-07
EP3652917B1 (fr) 2024-05-08

Similar Documents

Publication Publication Date Title
FR3069075A1 (fr) Systeme et procede pour integrer du contenu de message dans un dispositif cible de traitement de donnees
US10108726B2 (en) Scenario-adaptive input method editor
US20190340206A1 (en) Text-to-Media Indexes on Online Social Networks
US10289727B2 (en) Incorporation of semantic attributes within social media
US8918418B2 (en) Default structured search queries on online social networks
EP3788503A1 (fr) Interfaces en langage naturel pour bases de données utilisant des agents autonomes et des thésaurus
US20170039210A1 (en) Suggested Terms for Ambiguous Search Queries
WO2018070995A1 (fr) Diversifier les résultats de recherche multimédia sur des réseaux sociaux en ligne
US20090293059A1 (en) Automatically connecting items of workflow in a computer program
US20210117613A1 (en) Augmenting textual explanations with complete discourse trees
US8838610B2 (en) Listing tune-up system
US11436446B2 (en) Image analysis enhanced related item decision
MX2015006040A (es) Modelo de gramatica para consultas de busqueda estructuradas.
KR102141245B1 (ko) 콘텐츠 창작자와 후원자 매칭을 통한 온라인 콘텐츠 투자 시스템 및 방법
US20170011068A1 (en) Extrapolative Search Techniques
WO2012028817A1 (fr) Procède de recueil de données a caractères événementiel de formulaires électroniques
CN107644053A (zh) 通知的场境信息
WO2014105640A1 (fr) Interrogations de recherche structurées ambiguës sur des réseaux sociaux en ligne
JP2024041849A (ja) 確率的アイテムマッチングおよび検索
CN109791545A (zh) 用于包括图像的显示的资源的上下文信息
EP3306555A1 (fr) Diversification des résultats de recherche multimédia sur des réseaux sociaux en ligne
Angeli et al. Making paper labels smart for augmented wine recognition
US11922474B2 (en) Product identification assistance techniques in an electronic marketplace application
WO2018015515A1 (fr) Procedes de partage d&#39;opinion, equipements et programmes d&#39;ordinateur pour la mise en oeuvre des procedes
NZ760613B2 (en) System and method for integrating message content into a target data processing device

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20190118

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7