Brevet FR3092690A1 — publié le 20200814

Description Titre de l'invention : SYSTÈME ET PROCÉDÉ POUR LE TRAITEMENT DE TRANSACTIONS TRIPARTITES EN TEMPS RÉEL [000 La spécification concerne de façon générale le traitement de transaction électronique, et spécifiquement un système et un procédé pour l'intermédiation de transactions en temps réel. [0002] Diverses activités entreprises par des membres d'organisations (p. ex. les salariés d'une entité commerciale) peuvent nécessiter que les membres engagent des frais. Des exemples de ces activités incluent le voyage, l'obtention de fourniture, et autres de ce genre. Le remboursement de ces dépenses survient généralement après que les dépenses ont été non seulement engagées, mais également payées par les membres. En d'autres termes, le remboursement est généralement un processus rétroactif qui peut être mal adapté à la mise en oeuvre des politiques de dépenses, la détection de fraude potentielle et autres. Par ailleurs, les processus de remboursement sont généralement faits manuellement et peuvent donc être chronophages et se prêter aux erreurs. [0003] Un aspect de la spécification fournit un procédé d'intermédiation pour des tran- sactions comprenant, au niveau d'un serveur d'intermédiation : la réception de données de facture définissant un prix payable à un vendeur pour la fourniture d'un produit à un client ; l'extraction à partir des données de la facture, d'un identifiant de vendeur correspondant au vendeur ; la détermination, en lien avec les données de la facture, d'un identifiant de client correspondant au client; la récupération d'un identifiant de payeur correspondant au payeur associé au client ; la récupération sur la base d'au moins l'identifiant de payeur, d'une politique de transaction, en affectant une portion éligible du prix à l'identifiant du payeur et en affectant la portion restante du prix à l'identifiant du client ; et la génération et la transmission des données de paiement pour initier un paiement de la portion éligible du payeur au vendeur. [0004] Dans un mode de réalisation, la réception des données de facture comprend : la réception des données de facture provenant du dispositif informatique d'un vendeur correspondant à l'identifiant du vendeur. Dans un autre mode de réalisation, la détermination de l'identifiant du client comprend l'extraction de l'identifiant du client des données de facture. Dans un autre mode de réalisation, la détermination de l'identifiant du client comprend : l'obtention d'un identifiant de facture unique ; et la réception d'une demande d'association provenant du dispositif informatique client correspondant à l'identifiant du client, la demande d'association contenant l'identifiant de facture unique. Dans un autre mode de réalisation, l'obtention de l'identifiant de facture 2 unique comprend la génération de l'identifiant unique et la transmission de l'identifiant unique au dispositif informatique vendeur pour qu'il soit saisi par le dispositif informatique client. [0005] Dans un mode de réalisation, la réception des données de facture comprend la réception de données de facture provenant d'un dispositif informatique client correspondant à l'identifiant du client. Dans un autre mode de réalisation, l'extraction de l'identifiant du vendeur comprend l'application de la reconnaissance optique de caractères aux données de facture. Dans un autre mode de réalisation, le procédé fourni comprend par ailleurs : lorsque la portion restante est non zéro, la transmission d'une notification à un dispositif informatique client correspondant à l'identifiant du client, la notification contenant une indication de la portion restante. [0006] Dans un mode de réalisation, la génération et la transmission des données de paiement comprennent : la demande des données de paiement d'un système de paiement externe ; et la transmission des données de paiement à un dispositif informatique client correspondant à l'identifiant du client pour présentation au dispositif informatique vendeur correspondant à l'identifiant du vendeur afin d'effectuer le paiement. Dans un autre mode de réalisation, la génération et la transmission des données de paiement comprennent : l'envoi d'instructions de paiement à un système de paiement externe pour effectuer le paiement ; et l'envoi des notifications de paiement à chacun des dispositifs suivants (i) un dispositif informatique client correspondant à l'identifiant du client et (ii) un dispositif informatique vendeur correspondant à l'identifiant du vendeur. [0007] Un deuxième aspect de la spécification fournit un serveur d'intermédiation qui met en oeuvre les étapes du procédé fourni. [0008] Un troisième aspect fournit un système pour le traitement de transactions tripartites en temps réel, comprenant : (i.) un dispositif informatique vendeur associé à un vendeur et configuré pour générer des données de facture définissant un prix payable au vendeur pour la fourniture d'un produit à un client ; (ii) un serveur d'intermédiation configuré pour : recevoir les données de facture via un réseau ; extraire des données de facture, un identifiant de vendeur correspondant au vendeur ; déterminer, en association avec les données de facture un identifiant de client correspondant au client ; récupérer un identifiant de payeur correspondant à un payeur associé au client ; récupérer, sur la base d'au moins l'identifiant de payeur, une politique de transaction ; conformément à la politique de transaction récupérée, affecter une portion éligible du prix à identifiant du payeur, et affecter une portion restante du prix à l'identifiant du client ; générer et transmettre des données de paiement, via le réseau, pour initier un paiement de la portion éligible du payeur au vendeur ; et (iii) un dispositif informatique client associé au client, le dispositif informatique client étant configuré pour : recevoir 3 les données de paiement du serveur d'intermédiation via le réseau ; et pour présenter les données de paiement pour réception par le dispositif informatique vendeur afin d'exécuter le paiement de la portion éligible. [0009] Dans un mode de réalisation, le serveur d'intermédiation est par ailleurs configuré pour générer les données de paiement, pour demander un numéro de carte virtuelle (VCN) à un sous-système de paiement connecté au serveur d'intermédiation via le réseau ; et dans lequel le dispositif informatique client est configuré pour recevoir et présenter le VCN au dispositif informatique vendeur. Dans un autre mode de réalisation, le dispositif informatique vendeur est configuré pour exécuter le paiement de la portion éligible en transmettant le VCN au sous-système de paiement. Et encore dans un autre mode de réalisation, le dispositif informatique vendeur est configuré pour transmettre les données de facture au serveur d'intermédiation via le réseau. [0010] Dans un mode de réalisation, le serveur d'intermédiation est configure, en réponse à la réception des données de facture du dispositif informatique vendeur, pour obtenir un identifiant de facture unique et pour transmettre l'identifiant de facture unique au dispositif informatique vendeur pour présentation au dispositif informatique client ; dans lequel le dispositif informatique client est configuré pour saisir l'identifiant de facture unique et transmettre une requête d'association contenant l'identifiant de client et l'identifiant de facture unique au serveur d'intermédiation via le réseau ; et dans lequel le serveur d'intermédiation est configuré pour déterminer l'identifiant du client en récupérant l'identifiant du client dans la requête d'association. Dans un autre mode de réalisation, le dispositif informatique client est configuré pour saisir les données de facture et transmettre les données de facture au serveur d'intermédiation via le réseau. [0011] Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles : [0012] [fig.1] décrit un système pour l'intermédiation de transactions en temps réel ; [0013] [fiig.2] décrit certains composants internes du serveur d'intermédiation de la Fig. 1 ; [0014] [fig.3] décrit un procédé pour l'intermédiation de transactions en temps réel ; [0015] [fig.4A] décrit un exemple de la réception de données de facture au niveau du serveur d'intermédiation au bloc 305 du procédé 300 ; [0016] [fig.4B] décrit un autre exemple de la réception de données de facture au niveau du serveur d'intermédiation au bloc 305 du procédé 300 ; [0017] [fig.5] décrit un procédé de mise en oeuvre du bloc 310 du procédé de la Fig. 3 ; [0018] [fig.6] décrit une portion du système 100 pendant la mise en oeuvre du procédé de la Fig. 5 ; [0019] [fig.7] décrit un procédé pour la mise en oeuvre du bloc 330 du procédé de la Fig. 3 ; et [0020] [fig.8] décrit à titre d'exemple des données de paiement et de notification reçues par le dispositif client du système de la Fig. 1 provenant du serveur d'intermédiation. [0021] La Fig.1 décrit un système 100 pour l'intermédiation de transactions en temps réel. Les transactions exposées dans les présentes incluent typiquement la fourniture de produits (c.-à-d. des biens et/ou des services) par un vendeur à un client 108. Le vendeur 104, dans le présent exemple, est un gestionnaire d'hôtel et les produits fournis au client 108 peuvent par conséquent être des hébergements dans des chambres d'hôtel. Comme les hommes de métier le remarqueront, une grande variété de vendeurs peuvent cependant fournir une grande variété de produits au client 108. Comme il sera également apparent, bien qu'un seul vendeur 104 et un seul client 108 soient illustrés dans la Fig. 1, la fonctionnalité du système 100 détaillé dans les présentes peut s'appliquer à un quelconque nombre de vendeurs 104 et de clients 108 adéquats. [0022] Les produits fournis au client 108 par le vendeur 104, tels que les séjours d'hôtel sus- mentionnés, ont des prix associés payables au vendeur 104 en échange des produits. Cependant, le paiement de ces prix au vendeur 104 n'est pas nécessairement fait par le client 108 bien que le client 108 soit le bénéficiaire des produits. Spécifiquement, dans l'exemple illustré de la Fig. 1, le client 108 est associé à une entité de payeur 112. L'entité payeur 112 (également désignée simplement comme le payeur 112 dans les présentes) peut être une organisation ou un individu et l'association entre le payeur 112 et le client 108 n'est pas particulièrement limitée. Dans la discussion ci-dessous, à titre d'illustration, le payeur 112 est supposé être une entreprise employant le client 108. Une grande variété d'autres associations entre payeurs 112 et clients 108 sont aussi visées. En général, en raison de l'association (quelle que soit la nature spécifique de l'association) entre le payeur 112 et le client 108, il peut être nécessaire pour au moins certains des paiements pour des produits fournis par le vendeur 104 au client 108 d'être effectués par le payeur 112 plutôt que par le client 108. [0023] Dans ce but, le système 100 inclut divers composants permettant au paiement d'être effectué par le payeur 112 (c.-à-d. d'un compte, p. ex. dans une institution financière, contrôlé par le payeur 112) au vendeur 104 en réponse à la fourniture des produits par le vendeur 104 au client 108. On notera particulièrement que le système 100 permet que ces paiements soient effectués via l'intermédiation d'une transaction principale (c.-à-d. la transaction pendant laquelle le vendeur 104 reçoit un paiement) entre le vendeur 104 et le client 108. En d'autres termes, les mécanismes discutés dans les présentes ne concernent pas le remboursement rétroactif au client 108 pour des paiements faits par le client 108 au vendeur 104, via des transactions secondaires (c.-à-d. des transactions par lesquelles le client 108 reçoit un paiement) survenant après la transaction principale. Pour cette raison, la fonctionnalité d'intermédiation discutée dans les, fait référence à une intermédiation en temps réel, c.-à-d. intermédiaire au cours de la transaction principale. [0024] Pour implémenter l'intermédiation de transactions en temps réel, le système 100 inclut une pluralité de dispositifs informatiques interconnectés via un réseau 116. Lc réseau 116 inclut une quelconque combinaison de réseaux locaux et de zone étendue appropriés (p. ex. incluant Internet), implémentés par une quelconque combinaison appropriée de réseaux filaires et/ou sans fil. En particulier, le système 100 inclut un serveur d'intermédiation 118 (également dénommé simplement dans les présentes comme le serveur 118), configuré comme on le verra ci-dessous, pour recevoir des données de facturc définissant une transaction principale. Le serveur d'intermédiation 118 est par ailleurs configuré pour affecter des portions de paiement (c.-à-d. un prix pour le produit(s) impliqué(s) dans la transaction) définies par les données de facture entre le client 108 et le payeur 112. Le serveur d'intermédiation 118 est par ailleurs configuré pour générer et transmettre des données de paiement à d'autres dispositifs du système 100 pour effectuer le paiement d'une quelconque portion affectée au payeur 112, du payeur 112 au vendeur 104. [0025] Pour implémenter la fonctionnalité susmentionnée, le serveur d'intermédiation 118 stocke un dépôt 120 contenant les données de factures reçues ainsi que les données associées générées et utilisées au cours de l'intermédiation de transactions. Le serveur d'intermédiation 118 stocke également un dépôt de profils 122 contenant les règles et autres paramètres utilisés à la fois pour mettre en oeuvre l'affectation de portions de paiement entre le payeur 112 et le client 108 et pour effectuer des paiements du payeur 112 au vendeur 104. [0026] Le système 100 inclut aussi un dispositif informatique vendeur 124 géré par le vendeur 104. Le dispositif vendeur 124 peut être implémenté par un quelconque ou par une quelconque combinaison de serveurs, ordinateurs de bureau, dispositif informatique mobile, ou d'autres. En général, le dispositif vendeur 124 génère les données de facture spécifiant un prix payable au vendeur 104 pour un ou plusieurs produits fournis par le vendeur 104 au client 108. Dans certains modes de réalisation, le dispositif vendeur 124 peut aussi transmettre les données de facture à d'autres dispositifs informatiques dans le système 100, et peut aussi recevoir des notifications, des données de paiement et autres provenant d'autres dispositifs. [0027] En outre, le système inclut un dispositif informatique client 128 géré par le client 108. Le dispositif client 128 peut être un ordinateur de bureau, un dispositif informatique mobile tel qu'un smartphone, un ordinateur portable, une tablette et autres de ce genre. Le dispositif client 128 est configuré pour échanger des données avec un ou plusieurs serveurs d'intermédiation 118 et le dispositif vendeur 124. Par exemple, dans certains modes de réalisation le dispositif client 128 est configuré pour obtenir des données de facture et fournir les données de facture au serveur 6 d'intermédiation 118 afin d'initier l'intermédiation d'une transaction. Le dispositif client 128 peut aussi être configuré pour recevoir des notifications et/ou des données de paiement provenant du serveur d'intermédiation 118. [0028] Par ailleurs, le système 100 inclut un dispositif informatique payeur 132 géré par le payeur 112. Le dispositif payeur 132 peut être implémenté par un quelconque ou par une quelconque combinaison de serveurs, ordinateurs de bureau, dispositif informatique mobile, ou d'autres. Le dispositif payeur 132 peut être configuré pour recevoir des notifications provenant du serveur d'intermédiation 118 et peut aussi être configuré pour fournir des données au serveur d'intermédiation 118 afin qu'elles soient stockées dans ('dépôt de profils 122 (p. ex. au cours du déploiement du système 100). Par exemple, le dispositif payeur 132 peut maintenir et actualiser périodiquement les données de politique de transaction définissant comment les paiements sont affectés entre le payeur 112 et le client 108. Le dispositif payeur 132 peut fournir ces données de politique au serveur d'intermédiation 118 ou peut répondre aux demandes concernant des décisions en matière de politique provenant du serveur d'intermédiation 118. Le dispositif payeur 132 peut aussi maintenir un dépôt des dépenses ou autres, contenant des enregistrements qui définissent les paiements effectués par le payeur 112 pour les produits fournis au client 108 et autres. Ces enregistrements peuvent être mis à jour en réponse à des notifications reçues par le dispositif payeur 132 en provenance du serveur d'intermédiation 118. [0029] Le système 100 inclut aussi un sous-système de paiement 136, incluant un plusieurs dispositifs informatiques (p. ex. des serveurs et autres) gérés par une ou plusieurs institutions financières, réseaux de paiement, et autres. En général, le sous-système de paiement 136 conserve les comptes financiers associés à chaque payeur 112 et vendeur 104 (et facultativement, au client 108). Le sous-système de paiement 136 est configuré pour recevoir des instructions de paiement et effectuer des paiements (c.-à-d. transférer des fonds entre les comptes susmentionnés). Le sous-système de paiement 136 peut aussi être configuré pour générer des données de paiement, telles que des numéros de cartes de crédit virtuelles et autres de ce genre, pour usage par d'autres composants du système 100 avant d'effectuer le paiement. [0030] Faisant maintenant référence à la Fig. 2, avant d'exposer en détail les fonctionnalités du système 100, certains composants du serveur d'intermédiation 118 vont maintenant être décrits de façon plus détaillée. [0031] Le serveur d'intermédiation 118 inclut au moins un processeur 200, tel qu'une unité de traitement centrale (CPU), et autres de ce genre. Le processeur 200 est relié à une mémoire 204 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire [RAM], 7 mémoires à lecture seule [ROM], mémoires programmables à lecture seule effaçables électriquement [EEPROM], mémoires flash, stockage informatique magnétique, et autres de ce genre). Le processeur 200 et la mémoire 204 sont généralement compris d'un ou de plusieurs circuits intégrés (lCs). [0032] Le serveur 118 inclut aussi une interface de communications 208 interconnectée avec le processeur 200. L'interface de communications 208 permet au serveur 118 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 116. L'interface de communications 208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d'interface de réseau [NICs], des unités de radio, et ainsi de suite) pour communiquer via le réseau 116. Les composants spécifiques de l'interface de communications 208 sont sélectionnés en fonction de la nature du réseau 116. Le serveur 118 peut aussi inclure des dispositifs d'entrée et de sortie (non illustrés) connectés au processeur 200, tels que des claviers, des souris, des écrans, et autres de ce genre. [0033] Les composants du serveur 118 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le serveur 118 inclut une pluralité de processeurs qui peuvent partager la mémoire 204 et l'interface de communications 208, ou (p. ex. lorsqu'elles sont distribuées géographiquement, mais logiquement associées les unes aux autres) chacune ayant des interfaces de communications et des mémoires correspondantes distinctes. [0034] La mémoire 204 stocke les dépôts 120 et 122 mentionnés ci-dessus en lien avec la Fig. 1, la mémoire 204 stocke aussi une pluralité d'instructions de programmation lisibles par ordinateur, exécutables par le processeur 200 sous forme d'applications variées. Les applications stockées dans la mémoire 204 incluent une application orchestratrice 212, une application notificatrice 216, et une application analytique 220. Les hommes de métier comprendront que le processeur 200 exécute les instructions des applications 212, 216 et 220 (ainsi que toutes autres applications pertinentes stockées dans la mémoire 204) afin de mettre en oeuvre des actions diverses définies par les instructions contenues dans les présentes. Dans la description ci-dessous, le processeur 200 et, de façon plus générale, le serveur 118 sont censés être configurés pour mettre en oeuvre ces actions. On comprendra qu'ils sont configurés ainsi via l'exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204. [0035] L'exécution de l'application orchestratrice 212, comme on le verra ci-dessous, configure le serveur intermédiaire 118 pour recevoir des données de facture dans le but de les stocker dans l'dépôt 120 et pour servir d'intermédiaire dans le cadre d'une transaction afin d'effectuer un paiement correspondant aux données de facture, sur la base des contenus dans l'dépôt 122 (et facultativement les données récupérées des dispositifs informatiques extérieurs au serveur 118). Les fonctions techniques spécifiques 8 mises en oeuvre par le serveur 118 pour implémenter la fonctionnalité ci-dessus seront exposées de façon plus détaillée ci-dessous. [0036] L'application orchestratrice 212 peut aussi implémenter une ou plusieurs interfaces de programmation d'applications (APIs) exposées à d'autres dispositifs informatiques via le réseau 116 pour envoyer et recevoir diverses données liées aux transactions intermédiécs par le serveur 118. Le dispositif vendeur 124, le dispositif client 128 et le dispositif payeur 132 comme le verront maintenant les hommes de métier peuvent être configurés pour transmettre des données au serveur 118 conformément aux APIs susmentionnées. [0037] L'exécution de l'application notificatricc 216 configure le serveur 118 pour générer et transmettre des notifications (messages courricls, messages textes, messages d'application formatés conformément à une plusieurs APIs, ou autre de cc genre) à un ou plusieurs dispositifs vendeurs 124, au dispositif client 128 et au dispositif payeur 132. Les notifications transmises via l'exécution de l'application 216 sont générées en réponse à certaines actions effectuées via l'exécution de l'application 212. Dans d'autres exemples, la fonctionnalité implémentée par l'application 216 peut être implémentée par un dispositif informatique séparé dans le système 100 auquel le serveur 118 transmet des demandes de notifications pour traitement. [0038] L'application analytique 220, lorsqu'elle est exécutée par le processeur 200 configure le serveur 118 pour analyser les données de facture obtenues par le serveur 118. En particulier, le serveur 118 peut être configuré pour analyser des données de factures non structurées (p. ex. des images de reçus imprimés) afin d'en extraire les informations pertinentes pour un traitement ultérieur. L'application analytique 220 peut aussi être exécutée pour analyser les données de facture qui, bien qu'elles ne soient pas en format d'image, ne sont pas conformes à un schéma prédéterminé comme on le verra ci-dessous. Par exemple, les données de facture peuvent être reçues en fichiers PDF contenant un texte lisible par ordinateur plutôt que sous forme d'images. Le texte peut néanmoins ne pas être présenté dans un schéma prédéfini et peut donc encore nécessiter une analyse. Ces données de facture sont aussi qualifiées dans les présentes comme étant non structurées. Dans certains modes de réalisation, la fonctionnalité implémentée par l'application 220 peut être implémentée par un dispositif informatique séparé dans le système 100 auquel le serveur 118 transmet des demandes d'analyse et à partir duquel le serveur 118 reçoit des données de facture extraites. [0039] Faisant maintenant référence à la FIG. 3, certains aspects d'exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la Fig. 3 illustre un procédé 300 d'intermédiation de transactions en temps réel. Le procédé 300 sera décrit conjointement avec sa mise en oeuvre dans le système 100. En particulier, les blocs du procédé 300 sont mis en oeuvre par le serveur d'intermédiation 118 via l'exécution de 9 l'application orchestratrice 212, l'application notificatricc 216 et l'application analytique 220 par le processeur 200. [0040] Au bloc 305, le serveur 118 est configuré pour recevoir des données de facture dé- finissant une transaction principale. C'est-à-dire que les données de factures reçues au bloc 305 définissent un prix payable au vendeur 104 pour la fourniture d'un ou de plusieurs produits au client 108 (bien que comme il le sera évident dans l'exposé ci-dessous, les données de facture n'identifient pas nécessairement le client 108). Plusieurs mécanismes sont envisagés pour la réception de données de facture au bloc 305 dont des exemples sont illustrés dans les FIGS. 4A et 4B. [0041] Faisant d'abord référence à la Fig. 4A, les données de facture peuvent être reçues au bloc 305 du dispositif vendeur 124 via le réseau 116. Par exemple, en réponse à la génération des données de facture (p. ex. lorsque le client 108 quitte l'hôtel 104), le dispositif vendeur 124 peut être configuré pour transmettre les données de facture au serveur 118. La Fig. 4A illustre à titre d'exemple des données de facture 400 sous forme de données structurées. C'est-à-dire que les données de facture 400 contiennent divers attributs dans des champs lisibles par ordinateur (p. ex. nom/paire de valeurs) conformément à un quelconque schéma approprié prédéfini. Un exemple du format utilisé par les données de facture est le schéma de «facture» défini par shema.org (p. ex. voir http://schema.org/Invoice), bien qu'une grande variété d'autres schémas puissent aussi être utilisés. Les données de facture structurées peuvent être reçues dans un quelconque des formats de fichiers variés incluant le langage de balisage extensible (XML), JavaScript object notation (JSON), et autres de ce genre. [0042] La transmission de données de facture du dispositif de vendeur 124 au serveur 118 exige typiquement une intégration entre le dispositif vendeur 124 et le serveur 118. Par exemple, il peut être exigé du vendeur 104 qu'il configure le dispositif vendeur 124 pour interfonctionner avec le serveur 118 (p. ex. via les APIs susmentionnées), et qu'il génère des données de facture dans le format prédéfini. Cette intégration peut faire défaut à certains vendeurs et les données de facture peuvent donc être également reçues au niveau du serveur 118 en provenance du dispositif client 128 plutôt que du dispositif vendeur 124. [0043] La Fig. 4B illustre la réception de données de facture 404 en provenance du dispositif client 128. Les données de facture 404 peuvent, par exemple, être une image (dans un quelconque format de fichier, p. ex. PDF, JPEG ou autres) d'une facture imprimée générée par le dispositif vendeur 124 ou un périphérique connecté à ce dernier, et qui est saisie par une caméra du dispositif client 128. Les données de facture 404 sont donc considérées comme données non structurées, comme des attributs spécifiques des données de facture, bien qu'elles soient représentées visuellement par l'image, elles ne sont pas explicitement délimitées selon un format lisible par ordinateur. [0044] En d'autres termes, les données de facture peuvent être reçues au bloc 305 soit du dispositif vendeur 124, soit du dispositif clients 128. Par ailleurs, les données de facture peuvent être reçues comme données structurées (comme illustrées p. ex. dans la Fig. 4A) ou comme données non structurées (comme illustrées p. ex. dans la FIG. 4B). Bien que la réception des données de facture structurées soit illustrée dans la Fig. 4A comme étant associée au dispositif vendeur 124, dans d'autres exemples les données de facture structurées peuvent aussi être reçues du dispositif client 128. Par exemple, le dispositif client 128 peut aussi être configuré pour générer une interface graphique pour la réception d'entrées (p. ex. du client 108) consistant de données de facture structurées. En outre, dans certains modes de réalisation les données de facture non structurées (p. ex. une image telle qu'illustrée dans la Fig. 4B) peuvent être reçues du dispositif vendeur 124. Dans d'autres modes de réalisation, les données de factures reçues au bloc 305 peuvent inclure à la fois une image comme dans la Fig. 4B et des données structurées comme dans la Fig. 4A. [0045] Lors de la réception des données de facture, le serveur 118 est configuré pour stocker les données de facture dans I'dépôt 120. Le serveur 118 peut aussi générer un identifiant unique correspondant aux données de facture et stocker l'identifiant dans l'dépôt associé aux données de facture. [0046] Pour que le serveur 118 serve d'intermédiaire dans une transaction, les identités de chaque vendeur 104, client 108 et payeur 112 doivent être connues du serveur 118. Au bloc 310, le serveur 118 est donc configuré pour extraire un identifiant de vendeur (c.-à-d. du vendeur 104) des données de facture et pour déterminer un identifiant de client (c.-à-d. du client 108) qui correspond aux données de facture. Les actions effectuées par le serveur 118 pour obtenir les identifiants de vendeur et de client varient en fonction des contenus des données de factures reçues au bloc 305. La Fig. 5 illustre un procédé exemplaire pour la mise en oeuvre du bloc 310. [0047] Commençant au bloc 505, le serveur 118 est configuré pour déterminer si les données de facture reçues au bloc 305 sont des données structurées ou non structurées. Lorsque les données de facture ne sont pas structurées, telles que les données de facture 404 illustrées dans la Fig. 4B (p. ex. une image saisie par la caméra du dispositif client 128), le serveur 118 avance au bloc 510. Au bloc 510, le serveur 118 est configuré pour analyser les données de factures non structurées, par exemple via l'exécution de l'application analytique 220. Via l'exécution de l'application analytique 220, le serveur 118 est configuré pour identifier le texte dans les données de facture 404 (p. ex. via toute opération de reconnaissance optique de caractères appropriée, OCR) et pour classifier le texte identifié dans les données de facture 404. La classification du texte identifié dans les données de facture 404 sert à identifier une portion de texte correspondant aux divers attributs de la transaction primaire, incluant 11 un quelconque ou plusieurs des attributs suivant : identifiant de vendeur, identifiant de client, prix, date et/ou information horaire, description des produits fournis par le vendeur 104, et ainsi de suite. La classification de texte identifié dans les données de facture peut se faire par l'application d'un quelconque ou d'une quelconque combinaison de mécanismes de classification, incluant les classificateurs basés sur l'apprentissage automatique. [0048] En d'autres termes, au bloc 510 le serveur 118 est configuré pour générer des données de facture structurées à partir des données de facture non structurées. Le résultat de l'opération(s) d'analyse est stocké dans l'dépôt 120 conjointement avec les données de factures non structurées reçues initialement, p. ex. dans un objet de données commun. Dans certains modes de réalisation, plutôt que de mettre en oeuvre le bloc 510 localement, le serveur 118 est configuré pour transmettre une demande d'analyse contenant les données de factures non structurées à un autre dispositif informatique du système 100 qui à son tour est configuré pour analyser les données de facture non structurées et renvoyer les données de factures structurées qui en résultent au serveur 118. [0049] Au bloc 515, ayant obtenu les données de facture structurées (soit via le bloc 510, soit parce que les données de facture reçues au bloc 305 étaient des données de facture structurées), le serveur 118 est configure pour extraire un identifiant de vendeur des données de facture structurées. L'identifiant du vendeur peut être un nom du vendeur tel que la chaîne «HÔTEL 123» dans les données de facture 404 montrées dans la Fig. 4B. L'identifiant du vendeur peut aussi être un identifiant prédéfini, également stocké dans le dépôt de profils 122, tel que la chaîne «HTL123 » dans les données de facture 400 montrées dans la Fig. 4A. Dans d'autres exemples, l'identifiant du vendeur n'a pas besoin d'être extrait directement à partir des données de facture elles-mêmes, mais en revanche il peut être extrait à partir de métadonnées accompagnant les données de facture. Par exemple, lorsque les données de facture sont reçues au bloc 305 sous forme de données de facture structurées via la sollicitation d'une API prédéfinie, le dispositif vendeur 124 a généralement fourni des données d'authentification (p. ex. un identifiant de compte et un mot de passe, ou autres) au serveur 118 avant de transmettre les données de facture. Le processus d'authentification associe le dispositif vendeur 124 à un identifiant de vendeur dans le dépôt de profils 122 et l'identifiant du vendeur n'a donc pas besoin d'être présent dans les données de facture elles-mêmes. [0050] Au bloc 520, le serveur 118 est configuré pour déterminer si les données de facture (ou les métadonnées qui lui sont associées, obtenues par une transmission contenant les données de facture telles que décrites ci-dessus) contiennent un identifiant de client. En particulier, le dépôt de profils 122 inclut les enregistrements correspondant à chaque client 108 enregistré pour utiliser le système 100 et le serveur 118 est configuré pour 12 déterminer au bloc 520 si un identifiant de client correspondant à un des enregistrements susmentionnés est présent dans les données de facture ou dans les métadonnées associées. Selon la présence ou l'absence d'un identifiant de client, le serveur 118 est configuré pour sélectionner un mécanisme d'identification de client différent afin d'obtenir l'identifiant du client. [0051] Lorsque les données de facture sont reçues au bloc 305 en provenance du dispositif client 128, la détermination au bloc 520 est généralement affirmative. Comme exposé en lien avec l'identifiant du vendeur au bloc 515, le dispositif client 128 peut être configuré pour transmettre des données de facture au serveur 118 via une connexion authentifiée établie via le réseau 116 et, par conséquent, même lorsqu'un identifiant de client fait défaut dans les données de facture, la transmission (p. ex. la sollicitation d'une API transmise par le dispositif client 128), est associée à un identifiant de client. Dans d'autres exemples, les données de facture elles-mêmes incluent un identifiant de client, tel que la chaîne « Alice Smith » dans les données de facture 404 ou l'adresse courriel « alice@acme.com » dans les données de facture 400. [0052] Lorsque la détermination au bloc 520 est négative, indiquant que les données de facture (et toutes métadonnées associées à la transmission des données de facture au serveur 118) ne contiennent pas d'identifiant de client correspondant à un enregistrement dans le dépôt de profils 122, le serveur 118 est configuré pour poursuivre au bloc 525. Au bloc 525, le serveur 118 est configuré pour initier un processus d'association afin de récupérer l'identifiant d'un client. Typiquement, lorsque la détermination au bloc 520 est négative, les données de facture ont été reçues au bloc 305 en provenance du dispositif vendeur 124 plutôt que du dispositif client 128. Par conséquent au bloc 525, le serveur 118 est configuré pour transmettre l'identifiant de facture unique susmentionné au dispositif vendeur 124 duquel les données de facture ont été reçues au bloc 305. L'identifiant de facture unique est présenté par le dispositif vendeur 124, p. ex. sur un écran, via une interface de communications de courte portée, ou autre de ce genre, afin d'être saisi par le dispositif client 128. Le dispositif client 128 est ensuite configuré pour transmettre une requête d'association au serveur 118, contenant l'identifiant unique (ainsi que l'identifiant du client en vertu de l'authentification notée ci-dessus entre le dispositif client 128 et le serveur 118). [0053] Au bloc 530, le serveur 118 est configuré pour recevoir la requête d'association contenant l'identifiant de la facture et l'identifiant du client. Au bloc 535, le serveur 118 est configuré pour stocker l'identifiant du client dans le dépôt 120 en association avec les données de facture. La Fig. 6 illustre le processus susmentionné. En particulier, la Fig. 6 illustre la transmission des données de facture structurées 600 du dispositif vendeur 124 au serveur d'intermédiation 118 (c.-à-d. au bloc 305). Comme illustrées dans la Fig. 6, les données de facture 600 n'incluent aucune information 13 identifiant le client 108 (par contraste aux données de facture 400 montrées dans la Fig. 4A). [0054] Suite à la réception des données de facture 600, le serveur 118 est configuré pour extraire et stocker l'identifiant du vendeur «HTL123 » au bloc 515. Par ailleurs, en réponse à une détermination négative au bloc 520, au bloc 525 le serveur 118 est configuré pour générer et transmettre un identifiant de facture unique 604 au dispositif vendeur 124. Dans le présent exemple, l'identifiant est la chaîne «B2NUKGIN5OR5», bien qu'une grande variété d'autres formats d'identifiants peuvent aussi être utilisés. [0055] Lors de la réception de l'identifiant de facture 604, le dispositif vendeur 124 est configuré pour présenter l'identifiant de facture 604 afin qu'il soit saisi par le dispositif client 128. Le mécanisme de présentation dans l'exemple montré dans la Fig. 6, est de restituer la chaîne sous forme d'indicium lisible par machine, tel qu'un code 608 QR sur un écran 612 du dispositif vendeur 124. D'autres mécanismes de présentation peuvent aussi être utilisés, en incluant cependant la transmission d'un identifiant 604 via un protocole de communication de courte portée (p. ex. le protocole de communication en champ proche, NFC). Le dispositif client 128 est configuré pour saisir l'identifiant 604 par exemple en saisissant une image du code QR 608 et en décodant l'identifiant 604 de cette dernière. Suite à la saisie de l'identifiant 604, le dispositif client 128 est configuré pour transmettre une requête d'association 616 contenant un identifiant de client (p. ex. «alite@acme.com ») et l'identifiant 604. La requête 616 peut, par exemple, utiliser un service « obtenirfacture » implémenté par les APIs susmentionnées exposées par le serveur 118. Le serveur 118, en réponse à la réception de la requête 116 (au bloc 530), stocke l'identifiant de client en association aux données de facture. En d'autres termes, le processus illustré dans les FIGS. 5 et 6 permet au dispositif client 128 de «réclamer» les données de facture fournies au serveur 118 sans un quelconque identifiant de client. [0056] Au bloc 535, le serveur 118 peut aussi être configuré pour générer une ou plusieurs notifications pour transmission à un ou à plusieurs dispositifs clients 128, au dispositif vendeur 124 et au dispositif payeur 132. Par exemple, lorsque les données de facture sont reçues par le dispositif vendeur 124 au bloc 305 et identifient le client 108, de sorte que le processus de réclamation de facture montré dans la Fig. 6 n'est pas nécessaire, le serveur 118 peut être configuré pour transmettre une notification au dispositif client 128 via l'exécution de l'application notificatrice 216 contenant au moins une portion des données de facture, indiquant que les données de facture ont été soumises par le vendeur 104 et sont en cours de traitement. Dans d'autres exemples, lorsque les données de facture sont reçues des dispositifs clients 128 au bloc 305, le serveur 118 peut être configuré pour générer une notification pour transmission au dispositif vendeur 124 contenant au moins une portion des données de facture, 14 indiquant que les données de facture ont été soumises par le client 108 et sont en cours de traitement. [0057] Ainsi en revenant à la Fig. 3, suite à la mise en oeuvre du bloc 310, le dépôt 120 contient les données de factures reçues au bloc 305, ainsi une version structurée des données de factures lorsque les données de factures d'origine étaient non structurées et les identifiants correspondant à chaque vendeur 104 et chaque client 108. [0058] Au bloc 315, le serveur 118 est configuré pour récupérer un identifiant de payeur (c.-à-d. correspondant au payeur 112 et donc au dispositif payeur 132). Par exemple, l'ID du payeur peut être récupéré à partir de le dépôt de profils 122 sur la base de l'identifiant de client détermine au bloc 310. Plus spécifiquement, le dépôt 122 définit des liens logiques entre des identifiants de payeurs et des d'identifiants de clients, par exemple pour indiquer avec quels payeurs 112 sont associés les clients 108 (p. ex. par emploi). Par conséquent, au bloc 315 le serveur 118 peut être configuré pour interroger le dépôt 122 pour obtenir l'identifiant d'un payeur qui est logiquement lié à identifiant du client du bloc 310. [0059] Dans d'autres exemples, la récupération de l'identifiant de payeur au bloc 315 peut être mise en oeuvre simultanément avec la mise en oeuvre du bloc 310. Par exemple, les données de facture elles-mêmes (telles qu'elles sont reçues au bloc 305) peuvent contenir l'identifiant du payeur. Cela peut être le cas lorsque par exemple, les produits représentes par les données de facture sont lies à des services de voyage réserves précédemment par le payeur 112 pour le compte du client 108 et par conséquent associés précédemment au payeur 112. Dans de tels cas, la mise en oeuvre séparée du bloc 315 n'est pas nécessaire et peut être omise Suite à la récupération de l'identifiant de payeur au bloc 315, le serveur 118 peut aussi être configuré pour transmettre une notification au dispositif payeur 132, par exemple, contenant au moins une portion des données de facture et au moins un identifiant de client ou un identifiant de vendeur. [0060] Ayant récupéré identifiant du payeur au bloc 315, le serveur 118 est configuré pour poursuivre au bloc 320. Au bloc 320, le serveur 118 est configuré pour récupérer des directives de transaction pour une application à la transaction primaire définie par les données de facture, sur la base au moins de l'identifiant du payeur du bloc 315. Le dépôt de profils 122, ainsi que noté antérieurement, contient des règles et d'autres paramètres pour affecter des portions du prix défini pour une transaction entre le payeur 112 et le client 108. Les contenus de le dépôt de profils 122 définissent aussi des critères pour sélectionner des méthodes de paiement et des informations utilisées pour effectuer les paiements du payeur 112 au vendeur 104. Les informations susmentionnées sont collectivement qualifiées de politique de transaction. Le dépôt 122 contient des directives de transactions pour chaque payeur 112 pour lequel le système 100 a été déployé. Au bloc 320, le serveur 118 est donc configuré pour récupérer la politique de transaction correspondant à l'identifiant du payeur (c.-à-d. au payeur 112 dans le présent exemple). [0061] En général, la politique de transaction définit des critères pour répartir les dépenses entre le payeur 112 et le client 108. En d'autres termes, la politique de transaction définit des critères permettant au serveur 118 de déterminer si le produit(s) indiqué dans les données de facture est éligible au paiement par le payeur 112, inéligible au paiement par le payeur 112 (et nécessite donc un paiement par le client 108), ou s'il est éligible uniquement en partie. La politique peut définir un quelconque d'une grande variété de critères pour effectuer l'affectation ci-dessus, les hommes de métier seront confrontés à de nombreux exemples. [0062] Un exemple de critères définis par la politique de transaction inclut des critères basés sur des types de produits. Par exemple, la politique peut définir des types de produits éligibles, tels que des chambres d'hôtel qui sont éligibles pour paiement par le payeur 112 et des types de produits inéligibles, tels que des frais de minihar associés aux chambres d'hôtel qui ne sont pas éligibles au paiement par le payeur 112.11 sera désormais évident que les données de factures reçues au bloc 305 énumèrent généralement des produits individuels et chaque produit peut donc être évalué indépendamment. Les critères basés sur les types de produits peuvent aussi spécifier que certains types de produits sont partiellement éligibles, p. ex. qu'un pourcentage spécifié du prix du produit est éligible, ou que le produit est éligible jusqu'à un seuil de prix (et par conséquent une quelconque portion du prix des produits au-dessus du seuil est inéligible). [0063] D'autres exemples de critères définis par la politique de transaction incluent des critères géographiques, définissant si les dépenses sont éligibles au paiement par le payeur 112 sur la base du lieu géographique du vendeur 104 et/ou du client 108. D'autres exemples encore de critères définis par la politique de transaction incluent des critères de validation appliqués à certains types de produits. Par exemple, la politique de transaction peut contenir un critère exigeant la comparaison de la localisation du vendeur pour des données d'itinéraire de voyage correspondant au client 108 et spécifiant que la dépense est éligible uniquement si la localisation du vendeur est alignée sur les données d'itinéraire. Les données d'itinéraire peuvent être stockées clans le dispositif payeur 132 ou dans un sous-système distinct connecté au réseau 116. [0064] Au bloc 325, ayant récupéré la politique de transaction pertinente de le dépôt 122, le serveur 118 est configuré pour appliquer la politique aux données de facture. L'application des directives de transaction aux données de facture sert à affecter une portion éligible du prix défini dans les données de facture au paiement par le payeur 112. Toute portion restante du prix défini dans les données de facture est inéligible au paiement par le payeur 112 et doit en revanche être payée par le client 108. 16 La portion restante inéligible du prix est donc affectée au paiement par le client 108. L'application des directives au bloc 325 est mise en oeuvre en comparant les données de facture aux critères définis par la politique afin de déterminer quelle portion du prix défini par les données de facture est éligible. Par exemple, un critère géographique peut être évalué en comparant la localisation du vendeur 104 (récupérée selon l'identifiant du vendeur obtenu au bloc 310) à une localisation ou région définie par le critère. [0065] Le résultat de l'application des directives de transactions est une affectation complète du prix total défini dans les données de facture (p. ex. $254,26 dans les données de facture illustrées dans les FIGS. 4A et 4B) entre le payeur 112 et le client 108. La portion éligible affectée au payeur 112 peut se situer entre zéro et la totalité du prix. Toute portion du prix qui n'est pas éligible est affectée au client 108, de sorte que la somme des portions éligibles et inéligibles est égale au prix total. Le serveur 118 peut être configuré pour transmettre des notifications à un ou à plusieurs dispositifs payeurs 132, au dispositif vendeur 124 et au dispositif client 128 indiquant les répartitions. [0066] Au bloc 330, le serveur 118 est configuré pour générer et transmettre une ou plusieurs données de paiement et des notification(s). En particulier, lorsque la portion éligible est non zéro, le serveur 118 est configuré pour générer des données de paiement pour transmission à un ou à plusieurs éléments du système 100 afin d'initier un paiement de la portion éligible du payeur 112 au vendeur 104. Lorsque la portion éligible est zéro, la génération des données de paiement est généralement omise et le serveur 118 peut générer des notifications uniquement au bloc 330. [0067] Faisant référence à la Fig. 7, un procédé exemplaire de mise en oeuvre du bloc 330 au serveur 118 est illustré. Au bloc 700, le serveur 118 est configuré pour déterminer si la portion éligible du prix total défini par les données de facture telles qu'elles sont déterminées au bloc 320 est non à zéro. Lorsque la portion éligible est zéro, indiquant que le prix entier défini par les données de facture est affecté au client 108 plutôt qu'au payeur 112, la mise en oeuvre du bloc 330 passe directement au bloc 730 (ce qui sera exposé ci-dessous) sans génération de données de paiement. [0068] Lorsque la détermination au bloc 700 est affirmative, le serveur 118 sélectionne une méthode de paiement et obtient des données de paiement au bloc 705. La sélection d'une méthode de paiement peut être basée sur la politique de transaction récupérée au bloc 320. Par exemple, la politique de transaction peut définir, en plus des critères d'affectation susmentionnés, des critères de sélection de méthode de paiement. Les critères de sélection de méthode de paiement définissent une ou plusieurs méthodes de paiement et les conditions correspondantes permettant à chaque méthode de paiement d'être sélectionnée. Par exemple, certaines méthodes de paiement peuvent correspondre à des zones géographiques spécifiques, à des vendeurs spécifiques, à des 17 clients spécifiques ou autres. [0069] Une variété de méthodes de paiement est envisagée, incluant des méthodes de paiement initiées directement par le serveur 118 (p. ex. des virements) et les méthodes de paiement initiées par le dispositif client 128 en utilisant des données reçues du serveur 118. Par exemple, la méthode de paiement sélectionnée peut être une carte de crédit virtuelle (VCC, également désignée comme numéro de carte virtuel, VCN), dans laquelle le serveur 118 obtient et fournit un VCN au dispositif client 128 pour une présentation subséquente au dispositif vendeur 124 afin d'effectuer le paiement. [0070] Le mécanisme utilisé par le serveur 118 pour obtenir les données de paiement varie donc avec le mécanisme de paiement sélectionné. Par exemple, dans le cas d'une carte de crédit virtuelle, le serveur 118 est configure au bloc 705 pour envoyer une requête au sous-système de paiement 136 afin d'obtenir un VCN associé à un compte prédétermine correspondant au payeur 112. Pour d'autres méthodes de paiement, les données de paiement peuvent être générées localement au serveur 118, p. ex. sous la forme d'instructions de transfert de fonds. [0071] Au bloc 710, le serveur 118 est configure pour déterminer si la méthode de paiement sélectionnée au bloc 705 nécessite que le paiement soit être effectué via le dispositif client 128 (ainsi que noté ci-dessus en lien avec la méthode de paiement VCN). Lorsque la détermination est négative, le serveur 118 poursuit au bloc 715 et transmet une instruction de paiement incluant les données de paiement au sous-système 136. Par exemple, le serveur 118 peut transmettre une instruction de transfert de fonds à une institution financière pour transférer au bloc 325 la portion éligible affectée, d'un compte (p. ex. défini dans le dépôt 122), associé au payeur 112 à un compte associé au vendeur 104. [0072] Lorsque la détermination au bloc 710 est affirmative, le serveur 118 transmet alors les données de paiement au dispositif client 128 au bloc 720. Par exemple, le serveur 118 peut transmettre le VCN susmentionné au dispositif client 128 pour présentation au dispositif vendeur 124 ou à un dispositif associé (p. ex. un terminal de point de vente). Le dispositif vendeur 124 à son tour transmet le VCN au sous-système de paiement 136 pour effectuer le paiement, comme cela sera évident pour les hommes de métier. La transmission des données de paiement au dispositif client 128 au bloc 720 peut être accompagnée par une notification d'une quelconque portion inéligible du paiement en fonction de l'affectation au bloc 325. Par exemple, faisant référence à la Fig. 8, un exemple d'interface présentée au dispositif client 128 est illustré, incluant des données de paiement 800 reçues du serveur 118 sous forme d'une carte de crédit virtuelle et une indication 804 de la portion éligible du prix total de la facture. Également représentée dans la Fig. 8, une notification 808 (p. ex. reçue avec les données de paiement) indique qu'une portion du prix de la facture est inéligible au 18 paiement par le payeur 112 et doit être payée par le client 108. La notification 808 peut aussi inclure, dans certains exemples, une indication 812 de la raison(s) de l'inéligibilité (c.-à-d. une indication des critères des directives de transactions responsables de l'affectation de la portion inéligible au client 108). [0073] Suite à la mise en oeuvre des blocs 715 ou 720, au bloc 725 le serveur 118 attend la confirmation que le paiement a été finalisé. La confirmation peut être reçue au bloc 725 en provenance du sous-système de paiement 136, par exemple sous la forme d'un message de notification de paiement instantané (IPN) généré par le sous-système de paiement 136. [0074] Suite à la réception de la confirmation de paiement au bloc 725, le serveur 118 est configuré pour générer au moins une notification au bloc 730. En particulier, le serveur 118 peut notifier un quelconque ou plusieurs des dispositifs payeurs 132 le dispositif vendeur 124 et le dispositif client 128 que le paiement a été finalisé. [0075] Des variations des systèmes ci-dessus et des procédés sont envisagées. Par exemple, dans certains modes de réalisation le serveur 118 peut être configure pour générer et transmettre des données de paiement au dispositif client (p. ex. un VCN comme indiqué ci-dessus) sans recevoir les données de facture définissant une transaction primaire spécifique. Par exemple, les données de paiement peuvent définir un montant journalier utilisable par le client 108 pour le paiement de factures quelconques (c.-à-d. un quelconque vendeur 104). En d'autres termes, la mise en oeuvre des blocs 305-315 peut être omise et les données de paiement peuvent être générées conformément à la politique de transaction pour un montant prédéterminé (ou un montant requis par le dispositif client 128). [0076] Dans d'autres modes de réalisation, certains blocs du procédé 300 peuvent être mis en oeuvre par le serveur 118 uniquement en réponse à des requêtes explicites, p. ex. provenant du dispositif client 128. Par exemple, la mise en oeuvre du bloc 320 peut être initiée uniquement en réponse à une requête de validation soumise par le dispositif client 128 (une fois que le dispositif client 128 a reçu les données de facture traitées obtenues via les blocs 305-315). [0077] Dans d'autres modes de réalisation, les politiques de transaction peuvent être conservées au niveau du dispositif payeur 132 plutôt que dans le dépôt 122 au niveau du serveur intermédiation 118. Dans ces modes de réalisation, plutôt que de récupérer la politique de transaction au bloc 320 et d'appliquer la politique pour affecter des portions du paiement au payeur 112 et/ou au client 108, le serveur 118 est configuré pour transmettre une requête de décision en matière de politique au dispositif payeur 132. La requête peut inclure par exemple les données de facture ainsi que les identifiants déterminés aux blocs 310 et 315. En réponse à la requête, le serveur 118 reçoit une décision en matière de directive du dispositif payeur 132, spécifiant 19 l'affectation des portions éligibles inéligibles du prix défini par les données de facture. [0078] Les hommes de métier apprécieront que dans certains modes de réalisation, la fonc- tionnalité des applications 212, 216 et 220 peut être implémentée en utilisant du matériel préprogrammé ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications (ASICs), des mémoires à lecture seule programmables et effaçables électriquement (EEPROMs, etc.) ou d'autres composants associés). [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]