FR2864663A1 - Echange securise de donnees, notamment de donnees certifiees pour l'affacturage - Google Patents

Abstract

L'invention concerne un système informatique, comprenant :- une interface réseau (50), propre à initialiser une connexion avec un poste distant (91),- un gestionnaire de mémoire (41), propre à créer et maintenir un espace mémoire dédié à un poste distant (91), pour l'échange de données entre le système et ce poste distant (91), et- un gestionnaire de session (41), réagissant à une initialisation de connexion avec identification réussie en ouvrant une session de poste distant, associée à un jeton unique, et à un espace mémoire dédié au poste distant dans le gestionnaire de mémoire,- les échanges de données avec le poste distant au cours d'une session étant conditionnés par la présence du jeton associé.

Description

Echan e sécurisé de données notamment de données certifiées É our l'

affactura _ e

L'invention concerne l'échange sécurisé de données certifiées, notamment sur un réseau étendu comme Internet.

Dans une technique telle que l'affacturage, il est nécessaire d'établir un échange ayant valeur juridique entre l'affactureur et ses clients, les vendeurs, qui ont eux même déjà établi des factures à leurs propres clients, les acheteurs.

Traditionnellement, l'échange en question s'établit sur papier. Mais il est manifestement souhaitable de le rendre aussi efficace que possible, donc de l'informatiser au maximum, tout en conservant le caractère certain, la valeur juridique, et aussi la commodité d'emploi.

Sur le dernier point, la commodité d'emploi, un réseau comme Internet convient bien; par contre, avec Internet, les autres impératifs sont difficiles à tenir.

L'échange de fichiers en ligne sur Internet est aujourd'hui assez bien maîtrisé. Il en est différemment pour des opérations interactives, comme une saisie en ligne, où il s'agit d'établir à distance un document de grande taille, qui est destiné à présenter un caractère certain, a fortiori une valeur juridique.

La présente invention vient améliorer la situation.

Selon un aspect de l'invention, il est proposé un système informatique, comprenant: - une interface réseau, propre à initialiser une connexion avec un poste distant, - un gestionnaire de mémoire, propre à créer et maintenir un espace mémoire dédié à un poste distant, pour l'échange de données entre le système et ce poste distant, et - un gestionnaire de session, réagissant à une initialisation de connexion avec identification réussie en ouvrant une session de poste distant, associée à un jeton unique, et à un espace mémoire dédié au poste distant dans le gestionnaire de mémoire, - les échanges de données avec le poste distant au cours d'une session étant conditionnés par la présence du jeton associé.

3 5 Dans un mode de réalisation, le gestionnaire de mémoire est agencé pour définir ledit espace mémoire dédié en tant qu'objet logiciel, associé à l'identifiant et au jeton unique. On peut alors prévoir un conteneur propre à stocker une correspondance entre des objets logiciels et des jetons uniques qui leur sont attribués.

De son côté, le gestionnaire de session peut être agencé pour, après identification réussie, rechercher un objet logiciel correspondant à cette identification, et, s'il en existe, offrir au poste distant, comme premier échange avec jeton, la faculté de reprendre une tâche sur cet objet logiciel, ou de l'abandonner pour en créer un nouveau associé à une nouvelle tâche.

Dans une application particulière, les tâches offertes à un poste distant sont: une fonction de saisie de données, une fonction de validation de données saisie, et au moins une fonction de post-traitement après saisie validée. S'agissant d'une application de saisie à distance, offerte au poste distant, l'espace mémoire dédié est consacré au stockage temporaire de données saisies, en attente de validation. Ainsi, le gestionnaire de session peut opérer par envoi au poste distant d'un formulaire de saisie, avec attente d'un retour du formulaire complété, à chaque fois accompagné du jeton unique correspondant. Plus précisément, les données saisies peuvent être des données de factures, soumises à distance à une entité d'affacturage, par un poste distant de vendeur.

Par ailleurs, le gestionnaire de session peut être agencé pour subordonner au moins la fonction de validation de factures saisies pour remise en affacturage à une certification fondée sur un code personnel (PIN) de la part d'un acteur habilité côté vendeur.

Selon un autre aspect de l'invention, le système informatique comprend un générateur d'un fichier natif d'impression, relatif une impression à caractère probant, tirée d'un ensemble cohérent de données présentes dans le système, par exemple dans un serveur interne, et un gestionnaire de documents capable de tirer de ce fichier natif des impressions orientées comptes selon différents formats.

Plus particulièrement, le gestionnaire de documents peut comprendre: - un accesseur de fichier natif, capable de réagir à un identifiant de document en sélectionnant une portion correspondante du fichier natif, et - au moins deux constructeurs de visualisation/impression, capable de coopérer avec l'accesseur de fichier natif pour construire deux fichiers de visualisation/impression, correspondant à un même contenu imprimable, ces deux constructeurs de visualisation/impression opérant sur des formats de fichier différents.

Ceci permet de disposer, en interne et chez les vendeurs, de documents directement comparables, imprimés et/ou à l'écran.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels: - la figure 1 est un schéma de principe général d'un système informatique utilisable notamment pour l'affacturage, avec connexion Internet, - la figure 2 est un schéma plus détaillé sur le plan structurel du système de la figure 1, - la figure 3A est un diagramme de flux de l'entrée d'un poste externe dans un des modes possibles de l'invention, en vue plus matérielle, - la figure 3B est un diagramme de flux de l'entrée d'un poste externe dans le mode "saisie 10 en ligne", en vue fonctionnelle, - la figure 4 est un schéma plus détaillé sur le plan structurel d'un serveur de la figure 2, - la figure 5 est un diagramme du traitement du mode "saisie en ligne" de la figure 3B par 15 un serveur de la figure 2, - la figure 6 illustre l'usage de fichiers natifs d'impression, pour différents formats de visualisation/impression, dans un système selon l'une des figures précédentes, 2 0 - la figure 7 illustre le fonctionnement du système de l'une des figures 1 à 4, dans l'exemple de l'élaboration d'un relevé mensuel de gestion, avec préparation d'un ficher natif d'impression selon la figure 6, - la figure 8 est un schéma de flux illustrant le fonctionnement du système selon l'une des 2 5 figures 1 à 4, dans un autre exemple, qui est l'élaboration d'un document à valeur juridique dit "quittance subrogative",et - la figure 9 est un schéma de flux illustrant la génération d'un type particulier de fichier d'impression.

Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.

La présente description peut faire intervenir des éléments susceptible de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa partie descriptive, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits.

Bien qu'elle soit d'application plus générale, l'invention sera décrite ci-après dans le contexte d'un exemple particulier, qui est l'affacturage, au sens large du terme.

L'affacturage consiste en ce qu'une entité ("vendeur"), qui émet des factures à l'égard de ses clients ("acheteurs") délègue la gestion de ces factures à une troisième entité ("affactureur" ou "hôte").

La "gestion des factures" comprend a priori: - la prise en charge ou "saisie" de la facture par le prestataire, sous la forme des identifications requises de la facture, des parties concernées (vendeur et acheteur) , et, au moins du cumul facturé à chaque fois, assorti en principe d'un délai de paiement, - le recouvrement de leur paiement, éventuellement dans les délais convenus, au besoin avec des mesures de contrainte sur les débiteurs défaillants, - la "consultation des comptes acheteurs", c'est-à-dire le compte rendu à chaque vendeur, en ce qui le concerne, de l'exécution de ce recouvrement, acheteur par acheteur, sous forme de cumul et/ou détaillée, et - la gestion par le vendeur des "profils utilisateur", c'est-à-dire des comptes d'accès selon le vendeur (accès commercial ou accès pour un dépôt de garanti).

2 0 On comprendra que, pour l'hôte, une même entité peut être à la fois vendeur et acheteur. Ces deux rôles sont naturellement cloisonnés autant que nécessaire.

Mais la "gestion des factures" peut comprendre également: - l'ouverture éventuelle de lignes de garantie aux vendeurs en fonction des montants qui leur sont dus, - à cet effet, l'évaluation de la fiabilité du portefeuille de créances gérés par le prestataire pour chacun des vendeurs, - la "liste des dernières approbations" qui correspondent aux lignes de garantie, - la fourniture à chaque vendeur de statistiques sur son activité, vue du côté des facturations 3 0 et de leur règlement.

A côté de cela, chaque vendeur peut échanger des messages, par exemple par courriel, avec son gestionnaire ou "contact" chez l'hôte (l'affactureur, dans l'exemple). On observera cependant que les intervenants de part et d'autre ne sont pas nécessairement les mêmes, selon la fonction considérée. Par exemple: - la saisie des factures est une opération de niveau comptable, - à l'opposé, la demande de lignes de garantie est une opération de gestion financière qui, au moins du côté vendeur, fera en principe intervenir un "décideur".

La mise en oeuvre de ces fonctions fait intervenir un système informatique évolué et sécurisé du côté du prestataire.

Il est naturellement intéressant qu'au moins en partie, les fonctions précitées puissent se faire par télécommunications entre le vendeur et le système informatique du prestataire. A cet effet, il a été possible d'utiliser: - les liaisons de type Minitel (marque déposée), mais dont les capacités sont assez limitées, - des lignes de télécommunication spécialisées, qui ne sont pas d'application générale à tous les vendeurs clients du prestataire, - les liaisons Internet, qui sont plus puissantes, mais posent différents problèmes, notamment sur la sécurité et la confidentialité.

La présente invention a notamment pour but d'améliorer et d'augmenter les fonctions réalisables par télécommunications, notamment, mais non exclusivement, sur Internet. 15 Ainsi, elle vise notamment à permettre à chaque vendeur qui le souhaite, sans investissement excessif, de: - saisir en ligne les factures rétrocédées, c'est à dire confiées au prestataire affactureur; - consulter non seulement son compte de vendeur, mais aussi le détail des comptes des 2 0 acheteurs qui le concernent; - récupérer une version informatique témoin imprimable de tous les documents comptables et annexes requis; - échanger électroniquement avec l'hôte affactureur des documents ayant valeur légale, tels que ceux dits "quittance subrogative", avec en option la possibilité d'une gestion automatique des déblocages de fonds, qui sont alors avancés au vendeur.

Il est maintenant fait référence à la figure 1. Un système informatique hôte applicable à l'affacturage peut se composer d'un serveur principal 10, (Srvl), associé à différents autres serveurs, ici un serveur 20 (Srv2) , et un serveur 30 (Srv3).

Il peut être également prévu un serveur d'application, qui permet à des postes internes d'accéder aux données. Le poste 60 est par exemple un poste d'opérateur interne qui sert à gérer des comptes vendeurs.

3 5 Un serveur Internet (IIS Srv) 50 permet à des postes externes tels que 91 et 92, d'accéder à la partie restreinte des informations qui les concernent. On décrira plus loin comment cette restriction est effectuée.

Le serveur 10 contient par exemple: - les données relatives à la tenue des comptes, notamment la liste des factures et des opérations diverses, - les fonctions permettant la consultation par les vendeurs de leurs comptes, le suivi des encours, compte tenu des règlements d'acheteurs, reçus par l'affactureur, sur 5 des factures de vendeurs.

Le serveur 20 contient, par exemple, les demandes de garantie par les vendeurs, en fonction de l'encours des acheteurs, la gestion du disponible, ainsi que des tables de référence, par exemple des tables de devises, pays, codes d'opérations.

Le serveur 30 contient des informations d'image, des informations statistiques utiles à , ainsi que les fonctions relatives à la saisie en ligne des factures.

La figure 2 illustre un exemple d'architecture matérielle correspondant au système de la 15 figure 1.

Cette figure 2 fait apparaître les mémoires de masse (disques durs, par exemple) 11, 21, et 31, respectivement associées aux serveurs 10, 20 et 30.

2 0 La structure est un peu différente de celle de la figure 1, en ce sens que les fonctions du serveur d'applications 40 de la figure 1 sont maintenant contenues dans le cadre en trait tireté 40, qui comprend: - du côté du serveur Internet 50, une application 41de services en ligne, (dite "Factonet.dll"), avec une interface de communication 42 (DCOM) vers le serveur 30, et une autre interface 25 de communication 43 (TCP), qui communique avec le serveur 10; - du côté du serveur 10, une pile TCP 44, suivie de l'interface de communication générale 45 de ce serveur 10, puis d'une fonction 46 (dite VIDO100) faisant le pendant de l'application de services en ligne, existant dans le serveur 30; - également du côté du serveur 10, une couche de communication 47, permettant aux postes 30 internes, comme 60, d'accéder au serveur 10.

Ainsi, les échanges portant sur l'évolution de données déjà établies (certifiées côté vendeur) peuvent se produire directement entre le serveur internet 50 et le serveur 10. Par contre, dans l'exemple décrit, les échanges de données à certifier sont traités différemment, à l'aide du 3 5 serveur 30, comme on le verra ci-après en détail.

La figure 2 fait également apparaître que le serveur 10 est muni d'un environnement de programmation procédurale 12 (PP), fondé par exemple sur le langage Cobol. Cet environnement est apte à traiter des objets sous forme procédurale.

Dans l'exemple, la saisie en ligne de factures, une fois terminée, va s'accompagner d'un échange certifié qui délègue à l'hôte affactureur la charge de recouvrer les factures listées. Cette délégation certifiée est appelée une "quittance subrogative". C'est un document juridique, qui pourra être confirmé par la transmission séparée d'un document papier dûment signé. Il est bien entendu essentiel que la saisie en ligne et le document papier soient rendus autant que possible identiques en substance. Et ceci pose d'abord le problème de la saisie sûre, en ligne, du document imposant que constitue généralement la quittance subrogative. En effet, un nombre d'une centaine de factures mensuelles subrogées est courant.

La demanderesse a résolu ce problème en prévoyant dans un serveur, ici le serveur 30, une zone mémoire dédiée à la saisie en ligne pour chacun des vendeurs. Lorsque la quittance subrogative est terminée, et validée, les factures subrogées passent dans le serveur 10 par une communication groupée asynchrone entre un module batch 3 du serveur 30 et un module batch 1 du serveur 1. Le serveur 10 et le serveur 20 peuvent ensuite se servir de ces factures subrogées.

La demanderesse s'est préoccupée de définir une identification stable entre le poste "vendeur" distant, pouvant être celui de l'émetteur des factures, et le système informatique hôte. Il s'est avéré que l'adresse Internet (ou autre adresse réseau) n'est pas satisfaisante, du 2 0 fait que des postes vendeurs peuvent être associés à un fournisseur d'accès Internet sécurisé, qui change l'adresse Internet dynamiquement, par exemple à chaque connexion.

La demanderesse a résolu ce problème en utilisant un système à jetons multiples.

2 5 La figure 3A illustre l'entrée en session d'un poste vendeur, en vue "matérielle", c'est-à-dire pour les aspects de plus bas niveau (jeton) de la connexion.

En 310, un vendeur accède, ici par Internet, au site hôte, en l'espèce: https://www. facto. fr/factonet A l'opération 312, l'opérateur du vendeur fournit un identifiant et un mot de passe de manière sécurisée (par exemple par cryptage dit SSL ou "Secure Socket Layer"). Côté hôte, à l'opération 313, il est procédé à une validation de l'identification du vendeur. Ceci s'effectue ici par une fonction de type "dll", dénommée par convenance DLLfactonet. Si la validation est positive, la fonction DLL crée et renvoie de manière sécurisée (par exemple par cryptage SSL) au vendeur, en 315, un jeton unique d'identification, noté 315T.

Ce jeton peut être calculé comme une fonction aléatoire de la date, de l'heure et d'une valeur comprise entre 0 et 9999 par exemple, en préservant au besoin son unicité par un mécanisme anti-doublon, de manière connue. Un exemple de jeton est donné 3ZBYEYBW04355865 dans lequel le jeton est la concaténation du résultat d'une fonction aléatoire sur la date (3ZBYEYBW), de l'heure (04:35) et d'une valeur aléatoire. Un tel jeton, combiné au cryptage SSL, fournit de façon commode à la fois une bonne sécurisation des transmissions, et une bonne isolation de celles-ci, d'un vendeur à l'autre. Ces aspects ont été importants, pour permettre à la Demanderesse de mettre en oeuvre une saisie des factures subrogées en ligne.

Ensuite (316), pour chaque demande de fonction par le poste vendeur, cette demande (317), accompagnée du jeton 315T, est adressée à la fonction factonet.dll notée ici 319, et la réponse 318 est accompagnée du même jeton. Le cryptage SSL peut être utilisé, comme précédemment. Cette demande de fonction peut concerner par exemple l'une des fonctions suivantes, qui peuvent être offertes en menu: - la saisie en ligne à l'opération 320 - l'approbation de crédit à l'opération 321, - la visualisation des comptes à l'opération 322.

Une telle demande de fonction peut avoir la forme: https://www. facto. fr/scripts/factonet.DLL/menu?jeton = <Jeton> où l'expression menu? désigne l'une des fonctions requise par l'opérateur du vendeur, et où 2 0 l'expression <Jeton> représente le jeton.

La figure 3B illustre plus particulièrement le cas d'une fonction de saisie requise par un vendeur comme indiqué à l'opération 320 de la figure 3A. La saisie des factures et leur certification n'appartiennent pas à la même personne. De plus, des interruptions, volontaires ou non, peuvent se produire dans la saisie.

Les opérations 310 et 312 de la figure 3A correspondent aux opérations 300 et 302 de la figure 3B.

3 0 Un poste distant entrant (300) indique (302) son identifiant id_vendor de manière sécurisée (communication de type SSL). Les opérations 313 à 320 de la figure 3A se déroulent. Ainsi, après validation de l'identification du vendeur (313) par la fonction DLL, un jeton est renvoyé (315) de manière sécurisée au serveur 50, ce jeton jouant le rôle de l'identifiant de l'état en cours de la session du vendeur. Si l'opérateur du vendeur requiert la fonction de saisie (320), le serveur 50 transmet l'identifiant du vendeur et le jeton au serveur 30, qui recherche (304) s'il existe en mémoire pour ce vendeur un bordereau de saisie commencé lors d'une session précédente. En variante, ce peut être le serveur 50 qui vérifie si un bordereau est déjà présent en mémoire. Dans le cas où il existe un bordereau commencé et non terminé, la session précédente et son état d'avancement ont été identifiés en mémoire respectivement par l'identifiant du vendeur et un jeton. L'usager distant est alors invité (306) à décider de reprendre ce travail précédent (307), ou d'en entamer un nouveau. Dans ce dernier cas, le travail précédent peut être annulé et détruit (308), et l'usager entamera la saisie d'un nouveau bordereau de factures (309). Bien entendu, si le test 304 n'indique pas de travail précédent, l'usager passe directement en 309.

Ce mécanisme permet une sécurisation satisfaisante de la saisie, tout en évitant à l'usager de tout recommencer si une session est interrompue, volontairement ou non. On observera que les données saisies sont intégralement stockées en direct chez l'hôte.

La figure 4 illustre un mode de fonctionnement par jetons pour des accès internet. Sur cette figure est représenté le serveur Internet 50 comprenant l'application 41 DLL Factonet, avec l'interface de communication 42 (DCOM) vers le serveur 30, et une autre interface de communication 43 (TCP), qui communique avec le serveur 10. L'application 41 est plus particulièrement détaillée ci-après.

L'application 41 comprend un module Web 410 en relation avec le serveur 50 d'un côté et une librairie de fonctions 412, appelées objets fonction, de l'autre. Le module Web appelle les fonctions de cette librairie. Le module Web comprend un répartiteur (ou dispatcheur) 2 0 adapté pour répartir sur les bonnes interfaces de communication les différentes demandes de fonction des vendeurs.

Le module Web 410 valide l'identification d'un vendeur et appelle une fonction de la librairie 412 afin de calculer un jeton pour un vendeur donné et une session donnée. Le module Web 410 attribue le jeton calculé et le renvoie au serveur 50. Le module Web agit à ce stade comme un gestionnaire de mémoire, agencé pour définir un espace mémoire dédié, en tant qu'objet logiciel, associé à l'identifiant et au jeton unique. Ainsi, il crée un objet vendeur qui permet de stocker l'historique d'une session de vendeur, et l'enregistre sur un disque 419 à entrée/sortie temporaires, chaque objet vendeur comprenant l'identifiant du vendeur. De plus, le module Web stocke temporairement dans un conteneur qui peut être une table 414 chaque pointeur d'un objet vendeur et son jeton associé. Ainsi, un jeton permet d'identifier la session du vendeur correspondant à l'objet vendeur. Autrement dit, le conteneur stocke une correspondance entre des objets logiciels et des jetons uniques qui leur sont attribués.

Si l'opérateur du vendeur n'effectue aucune action durant une session pendant un temps donné, par exemple 15 minutes, un processus de nettoyage 416 intervient pour détruire le jeton correspondant, le pointeur d'objet vendeur dans la table 414. Le module Web permet également de gérer les demandes répétées et non encore satisfaites des vendeurs en envoyant un message d'attente au vendeur.

Lors d'une demande de fonction par l'opérateur du vendeur, le module web utilise une fonction de la librairie 412 afin de communiquer cette demande de fonction au serveur adéquat: - si l'opérateur du vendeur demande une saisie en ligne, la communication de la demande sera faite par l'interface de communication 42 (DCOM) vers le serveur 30, - si l'opérateur du vendeur demande une visualisation de ses comptes, la communication de la demande sera faite par l'interface de communication 43 (TCP), qui communique avec le serveur 10, - si l'opérateur du vendeur demande une approbation de crédit, la communication de la demande sera faite par l'interface de communication 43 (TCP) vers le serveur 10.

La demande de fonction est envoyée avec le jeton de la session courante du vendeur. La réponse renvoyée à l'application Factonet DLL 41 comprend également le jeton de la session.

A titre de généralisation de la figure 3B et en rapport avec la figure 4, le module Web peut 2 0 rechercher, après identification d'un vendeur et création d'un jeton pour la session en cours du vendeur, si l'identifiant de ce vendeur se trouve dans un précédent objet vendeur correspondant à une précédente session et ceci à partir du conteneur qui pointe sur les objets vendeurs stockés. Ainsi, si la recherche ne retrouve pas d'objet vendeur comprenant l'identifiant du vendeur, un nouvel objet vendeur est créé pour la nouvelle session et le module Web attribue à cet objet vendeur le jeton courant. Si la recherche aboutit à trouver un objet vendeur comprenant l'identifiant du vendeur et que l'opérateur du vendeur valide la création d'un nouvel objet vendeur pour la nouvelle session, cet objet vendeur est créé et le module Web attribue le jeton courant à cet objet vendeur. L'opérateur du vendeur ne bénéficiera pas de l'objet vendeur de la session antérieure qui pourra être détruit. Au contraire, l'opérateur du vendeur peut valider la reprise de l'objet vendeur stocké sur le disque de façon à ce que l'opérateur du vendeur reprenne et complète la session antérieure. Dans ce cas, le module Web attribue le jeton courant à cet objet vendeur de la session antérieure.

3 5 Le module web agit ici comme un gestionnaire de session qui est agencé comme suit: après identification réussie, il recherche un objet logiciel correspondant à cette identification, et, s'il en existe, il offre au poste distant, comme premier échange avec jeton, la faculté de reprendre une tâche sur cet objet logiciel, ou de l'abandonner pour en créer un nouveau associé à une nouvelle tâche. Ceci peut servir, notamment, pour la saisie à distance. t

La figure 5 illustre le traitement de la demande d'une saisie de facture à subroger en ligne du vendeur par le serveur 30 sur demande de l'application Factonet DLL 41 de la figure 4.

L'opérateur du vendeur entre les principaux éléments de la facture en cours de saisie (502).

Le serveur 30 de la figure 2 vérifie si l'acheteur est déjà connu, par exemple dans une table des acheteurs associés au vendeur saisissant la facture (504).

Si l'acheteur est déjà connu, l'opérateur du vendeur peut sélectionner, dans une liste d'acheteurs, les détails concernant cet acheteur (508) afin d'établir une facture détaillée.

Sinon, le serveur 30 vérifie si l'opérateur du vendeur a entré des informations détaillées concernant l'acheteur (506). Dans la négative, le serveur demande au vendeur d'entrer les informations minimales concernant l'acheteur (516); dans l'affirmative, il est demandé au vendeur s'il souhaite avoir l'assistance de recherche de l'acheteur (510). Si l'assistance est requise, l'opérateur du vendeur reçoit une fenêtre de saisie de l'acheteur avec des zones pré- remplies (512) puis complète la fenêtre de saisie par des informations acheteur et valide la fenêtre (514). Si l'assistance n'est pas requise, l'opérateur du vendeur reçoit une fenêtre de saisie de l'acheteur et la fenêtre de saisie par des informations acheteur et valide la fenêtre (514) . Ces informations sont conservées par le serveur 30 sur son disque. Cette fenêtre peut être rattachée à la liste des acheteurs de l'opération 508.

Après l'opération 508, 514 ou 516, l'opérateur du vendeur valide la facture(518) par son enregistrement et le serveur 30 peut le stocker sur son disque. Durant une même session, l'opérateur du vendeur peut entrer et valider d'autres factures pour un même client ou d'autres clients (520) , le diagramme recommençant alors en 502. Si aucune autre facture ne doit être saisie (520), le serveur 30 exécute le traitement final de la facture comme illustré par le figure 8.

La figure 8 illustre la phase finale de certification des éléments saisis, toujours dans l'exemple d'une quittance subrogative.

Une fois la facture enregistrée et validée, les instructions concernant le règlement de la facture sont saisie par l'opérateur du vendeur (524). Une empreinte est établie (526) et le code PIN (Personal Identification Number) du vendeur inscrit sur une carte du vendeur est saisi (528). La carte de certification peut être par exemple du type "Click and trust", garanti par un tiers de confiance. La certification (530) de la facture est établie par l'opérateur du vendeur si celui-ci peut certifier la facture. Si l'opérateur du vendeur n'est habilité qu'à saisir une tellefacture, la certification de la facture subrogée est effectuée par une autre personne habilitée du vendeur, après identification de cette dernière par sa carte. L'opérateur du vendeur ou la personne habilitée à certifier la facture et sa subrogation donne son accord pour la subrogation de la facture (532).

Un fichier d'ensemble des factures subrogées est généré (534). Il peut servir de base pour construire un fichier d'impression, par exemple au format PDF (540), côté hôte. Ce fichier est envoyé au vendeur, qui l'imprime (542). Une personne habilitée du vendeur retourne alors le document imprimé signé, par exemple par télécopie classique ou par courrier. Ainsi, si besoin est, le document juridique certifié en ligne peut ainsi être confirmé par la transmission séparée d'un document papier portant une signature écrite classique (544).

Optionnellement, un financement peut être demandé dès la certification des factures, comme le rappelle l'opération 538.

En parallèle, le fichier contenant l'ensemble des factures saisies et subrogées est envoyé du serveur 30 au serveur 10 par une communication 536 par exemple par lots (en batch 536).A partir de là, les factures subrogées peuvent être traitées par le serveur 10. En bref, à partir des factures subrogées, l'hôte affactureur peut, de manière connue, mettre en oeuvre différents traitements, pour lui-même et pour l'opérateur du vendeur, son client.

D'autres types d'échanges entre le système informatique hôte, et les postes vendeurs distants, ainsi que les postes internes de l'hôte, sont illustrés sur la figure 7. Il s'agit notamment: - de comptes-rendus sur l'évolution des comptes acheteurs de ce vendeur 702, par exemple quel acheteur a payé dans les délais, ou quel acheteur n'a pas encore payé.

- de demandes de garantie 704 en amont d'une commande acheteur à un vendeur, - de données statistiques 706.

Tout cela doit: - correspondre exactement aux données sécurisées introduites dans le système informatique hôte, - permettre de déterminer un état cohérent des choses, au vu des différents intervenants (vendeurs, acheteurs, hôte), - pouvoir être visualisé/imprimé d'une manière stable, pouvoir être archivé avec un encombrement aussi réduit que possible.

Les deux premiers points sont importants, mais relèvent naturellement du savoir-faire de l'affactureur. On notera que les contrôles correspondants sont faits en parallèle, et que le résultat de chacun de ces contrôles peut arriver de façon tout à fait asynchrone, par rapport au moment où l'hôte décide de "fixer" un état cohérent, pour lui même, ou pour un ou des vendeurs. Ainsi qualifié, le problème devient: - accumuler des données de façon non ordonnée, - pouvoir les visualiser/imprimer d'une manière stable, - pouvoir les archiver avec un encombrement aussi réduit que possible.

On décrira maintenant comment ce problème a été résolu, à partir d'un fichier de base que l'on appelle ici "fichier natif' ou "fichier générique".

La figure 7 décrit l'élaboration d'un fichier natif décrit ci-dessous.

Diverses informations sont requises pour élaborer un fichier natif associé à un vendeur: l'évolution des comptes des acheteurs 702 pour ce vendeur, les demandes de garantie 704 de ce vendeur, les données statistiques 706 relatives aux informations concernant ce vendeur et d'autres informations stockées dans une mémoire 700. Chacune de ces informations est traitée par le serveur 10 sous la forme de flux d'informations respectivement 720, 740 et 760. D'autres flux d'informations peuvent être pris en compte, et sont consultables à partir d'une mémoire 710. Des processus appropriés, par exemple en batch, permettent de traiter (770) ces flux d'informations afin de construire un fichier natif (600) pour ce vendeur. Les 2 0 fichiers résultant peuvent être adressés au vendeur à travers l'application Factonet DLL 41 de la figure 4, de l'une des manières décrites.

Dans l'exemple, le fichier natif est un fichier à enregistrements (lignes ou rangées) de longueur fixe. Il comprend: - un enregistrement de tête dont la structure est donnée dans la table 1 annexée; - un nombre variable d'enregistrements utiles ("corps"), dont la structure est donnée dans la table 2 annexée; et - un enregistrement de fin dont la structure est donnée dans la table 3 annexée.

Pour le corps, chaque rangée comprend: - un second identifiant de compte vend id, - un identifiant de type de document (de visualisation/impression) Doc_type, - des informations de présentation dans le document, ici: 3 5 * un numéro de page PageNolnDoc * un choix de recto-verso PrintSide * des informations de position Datapos * des informations d'attributs d'impression PrintAttrib * des informations de saut de ligne LineJump des pointeurs d'informations d'éléments graphiques à insérer Graph elmts - une zone de remplissage filler, et - une zone de données (de visualisation/impression) Data_content.

Le corps peut également comprendre une rangée définissant un premier identifiant de la société d'affacturage soc_id.

Dans l'exemple, les données à visualiser/imprimer peuvent être définies: par la zone Data_content, une chaîne de caractères, et/ou - par un pointeur vers un autre élément de données, par exemple graphique, comme 10 Graph_elmts.

La valeur de Data_content peut être du type caractère, implicite par convention. Dans ce cas, les autres types de donnée à imprimer peuvent être convertis en caractères pour être ainsi notés en Data_content. En variante, Data_content peut contenir aussi, par exemple en tête, un code définissant le type de données contenues à chaque fois dans la zone Data_content. Si cela est désiré, les autres types de donnée peuvent être aussi définis à travers un pointeur stocké dans Data content.

La demanderesse a observé que cette structure reste assez simple pour loger en sécurité de 2 0 grandes quantités de données de visualisation/impression, arrivant en flot mélangé quant au document visé, quant au temps, et même quant à différentes parties d'un même document.

Un tel fichier, créé en flot, intéresse a priori une pluralité de vendeurs.

2 5 Il est bordé en tête par un enregistrement de début (Table 1) comportant ici les informations utiles suivantes: - une date de création du fichier Creat Date - une date d'effet du fichier Effect Date - une information de classe de fichier File class, par exemple la classe Relevé Mensuel de 3 0 Gestion (RMG) définissant un ensemble de documents à destination des vendeurs, la classe Relevé de Notification Acheteur (RNA) définissant un autre ensemble de documents, à destination cette fois des acheteurs, L'enregistrement de début comporte également à titre optionnel: - soc_id, déjà citée.

L'enregistrement de fin (Table 3) est semblable à l'enregistrement de début. Dans l'exemple, les informations de dates et classe de fichier sont remplacées par un nombre d'enregistrements NbOfRec.

Reste la zone de tête de chaque enregistrement rec_code, qui vaut 1 pour l'enregistrement de tête, 9 pour l'enregistrement de fin, et, pour les enregistrements de corps, une valeur allant de 2 à 4, pour indiquer (dans l'exemple) si l'enregistrement concerné est destiné à la visualisation, à l'impression, ou aux deux (les valeurs 5 à 8 sont réservées).

On observera que le fichier natif peut contenir en théorie jusqu'à 100 millions d'enregistrements (10), ce qui, pour 241 caractères par enregistrement, lui donnerait une taille de 24,1 Gigaoctets environ. En pratique, la Demanderesse a utilisé en test un fichier de 500 Mégaoctets environ, couvrant plus de mille vendeurs.

L'une des tâches incombant aux affactureurs est de produire un "relevé mensuel de gestion", qui doit être adressé à ses clients, les vendeurs, pour consultation, impression et/ou archivage. On considère maintenant cet exemple du "relevé mensuel de gestion".

Le relevé mensuel de gestion est définit par un ensemble de documents envoyés au vendeur et comprenant par exemple: - des lignes de garantie attribuée au vendeur, - le compte courant du vendeur, - les factures subrogées qui sont "en exception", par exemple les factures qui sont en retard 2 0 de paiement.

Le vendeur peut simplement demander une garantie, gérer lui-même les factures et se servir du relevé mensuel de gestion pour détecter notamment les factures en retard de paiement. Ce relevé mensuel de gestion peut être élaboré à partir d'un fichier natif.

La figure 6 utilise un fichier natif 600, élaboré par exemple comme indiqué ci-dessus. Le flot d'entrée qui nourrit le fichier natif est ici sous le contrôle d'un gestionnaire de fichier natif 602.

Ainsi, selon un autre aspect de l'invention, il est prévu un générateur d'un fichier natif d'impression, relatif une impression à caractère probant, tirée d'un ensemble cohérent de données présentes dans le serveur interne, et un gestionnaire de documents capable de tirer de ce fichier natif des impressions orientées comptes (vendeurs) selon différents formats.

Le ficher natif (ou fichier générique) 600 peut servir à différentes sortes de visualisation/impression, à l'aide d'un outil d'accès ("accesseur") à ce fichier 605, que l'on appellera ici extracteur.

L'utilisation la plus simple du fichier natif est la préparation des relevés mensuels de gestions individuels pour tous les vendeurs.

De manière connue, l'extracteur est agencé comme une fonction qui reçoit une ou des conditions de filtrage applicables aux enregistrements de corps (ou lignes) du fichier natif. En réponse, cette fonction est capable d'isoler toutes les lignes du fichier natif qui vérifient la ou les conditions de filtrage. Dans le cas d'une impression, le filtrage sera en outre limité aux lignes dont le rec_code est 3 ou 4; ceci peut être défini par la nature de la requête.

De préférence, la fonction utilise aussi un ou des critères de tri, qui peuvent être prédéfinis ou reçus par la fonction comme second paramètre (en plus du premier paramètre que constituent les conditions de filtrage).

Une condition prédéfinie de tri particulièrement intéressante est: - tri primaire par vendeur (vend id), - tri secondaire par position dans le document, à savoir, en principe dans l'ordre: * numéro de page PageNolnDoc * choix de recto-verso PrintSide * informations de position Data_pos, et * autres données de position tirées éventuellement des informations d'éléments graphiques à insérer Graph_elmts, des informations de saut de ligne LineJump, et de la longueur effective du champs de données utiles Data_content.

Bien entendu, des requêtes plus précises peuvent également être effectuées, par exemple si un poste interne de l'hôte désire visualiser ce qui concerne un vendeur précis.

En bref, pour visualiser/imprimer un état, le système informatique doit seulement fournir une requête, traitée par le requêteur 607. Celui-ci peut alors fournir les données correspondant à la requête. Celle-ci peut porter seulement sur la zone Doc_type, comme déjà décrit 3 0 pour simplifier. En pratique,Doc_type est seulement un identifiant de type de document, par exemple un "relevé mensuel de gestion", qui peut être de portée globale, mais se décomposer en autant de fichiers cibles qu'il y a de vendeurs traités.

Par contre, si l'on se limite à un vendeur donné les données à visualiser/imprimer ne sont complètement déterminées que par un doublet (vend id, Doc_type).

Des critères de sélection supplémentaires peuvent être mis en oeuvre après la première sélection sur Doc type, ou bien en même temps que celle- ci. Des index peuvent être utilisés pour accélérer le travail de l'extracteur 605.

Dans l'exemple, la figure 6 fait apparaître trois constructeurs de fichiers de visualisation/impression de formats différents.

Le constructeur 610 élabore ici des fichiers, par exemple "pdf', assurant une présentation stable pratiquement quel que soit le périphérique d'impression (et/ou de visualisation). Ceci peut constituer des fichiers de taille raisonnable, compatible avec une transmission rapide au "vendeur" par Internet. En variante, pour les vendeurs "Grands comptes", il serait concevable de leur envoyer l'extrait du fichier générique qui les concerne, tandis que le constructeur 610 serait implanté dans l'informatique du vendeur.

Le constructeur 620 élabore ici des fichiers image, par exemple "tiff ', assurant une visualisation stable et confortable, pratiquement quel que soit le périphérique de visualisation, pour des personnels de l'hôte utilisant à plein temps les écrans. La création des fichiers image, par exemple "tiff', à partir du fichier générique est considérée comme accessible à l'homme du métier.

Le constructeur 630 élabore ici des fichiers, par exemple au format dit VIPP (Variable Data Intelligent Postcript Printware), compatible avec une impression stable et de haute qualité, qui peut être confiée en soustraitance. Ici, la rapidité n'est pas primordiale, compte-tenu du 2 0 temps requis pour l'impression qui va suivre.

Il est important de souligner que tout ceci peut se faire à tout moment, sur la base d'un fichier natif simple, donc facile à archiver.

2 5 La figure 9 illustre un mode de réalisation de la lecture d'un fichier natif par un constructeur de fichier de visualisation/impression.

Le fichier d'entrée à lire est tout d'abord ouvert en 810 et la lecture de ce fichier commence en 812. Dans cet exemple, le fait que le fichier d'entrée peut effectivement servir comme fichier natif (pour traitement par le constructeur de fichier concerné) est indiqué par une variable codenr mise à "1". Le processus se termine donc en 830 si la variable codenr est différente de 1. Cette variable codenr reflète le code "1" (rec_code) contenu dans l'enregistrement de tête d'un ficher natif. Si la variable codenr est égale à 1, le procédé se poursuit à l'opération 816.

Il est rappelé que le code File_class de l'en tête du fichier natif range le document dans une classe particulière. L'ensemble des classes possibles de document peut être stocké dans une table, notée "Tab124", qui définit aussi quels types d'impression sont prévus pour chaque classe de documents. L'opération 813 inspecte cette table "Tab124", afin de déterminer si le fichier natif d'entrée a vocation à être traité par le constructeur de fichier de visualisation/impression considéré (ici, l'un des constructeurs 610, 620 et 630). Si ce n'est pas le cas (818), le processus se termine en 830.

Si au contraire la table Tab124 accepte en 818 la classe de document du fichier natif en 818 pour le constructeur de fichier de visualisation/impression considéré, la lecture du fichier natif se poursuit en 820, tant que la fin du fichier n'est pas atteinte (test 822).

En principe, dans une passe, seuls les enregistrements relatifs à un vendeur donné (code vend id) sont considérés.

A chaque pas de lecture, on examine en 824 la valeur du code enregistrement rec code, pour déterminer s'il correspond au constructeur concerné. Ici, un rec_code 2 ou 4 autorise les constructeurs de fichiers 610 et 630; un rec_code 3 ou 4 autorise le constructeur de fichier image 620.

On examine également la valeur du code Doc_Type en 824, de façon à établir les limites de "dossier", dans le fichier.

2 0 Là où les codes voulus sont trouvés en 824, la mise en forme pour impression peut être faite en 826. Cette mise en forme sera décrite plus loin.

La lecture du fichier natif continue ensuite en 820 jusqu'à un nouveau code enregistrement qui a la valeur édition en 824 et ceci jusqu'à la fin du fichier en 822. Dès que le fichier natif 2 5 est entièrement parcouru, on peut afficher en 828 le nombre de dossiers mis en forme à partir du fichier natif. Le procédé se termine à l'étape 830.

Dans le cas de l'élaboration d'un fichier au format pdf à partir d'un fichier natif comme décrit ci-dessus, la mise en forme consiste a priori à créer l'en tête spécifique d'un fichier pdf. Chaque passage à l'opération 826 peut se faire en générant, à partir des zones utiles à l'impression de l'enregistrement concerné du fichier natif, les paramètres voulus pour un appel d'un outil du commerce, comme le pilote "Adobe PDFwriter". Ainsi, la Demanderesse a pu écrire sous DELPHI (Borland) un module dénommé "rasterPDF.exe" fondé sur le diagramme de flux de la Figure 9.

Dans le cas de l'élaboration d'un fichier au format VIPP à partir d'un fichier natif, la mise en forme consiste principalement à écrire différentes déclarations, qui sont fonction des données du fichier natif, et du contexte.

Dans le cas du format VIPP, écrire une déclaration consiste à écrire dans le fichier un objet déclaré, puis écrire les attributs généraux concernant cet objet, et écrire la fin de cette déclaration.

Ainsi, la mise en forme proprement dite fait intervenir une déclaration d'en tête (dite XRX) pour l'édition sous format VIPP, suivie des attributs généraux de l'édition, puis d'une "fin de déclaration XRX".

D'autres types de déclarations peuvent être écrites, notamment pour: - le début (START) du fichier au format VIPP, - ce qui est relatif au code natif, - l'orientation du papier, - l'impression recto/verso, ou non, les marges d'impression.

Lorsque des ruptures sont détectées, différentes mesures sont prises, selon la nature de la rupture et le contexte.

Ainsi, lorsqu'une rupture de type de document est rencontrée: - une table des données signalétiques du document est lue, - des déclarations de type de "bac d'alimentation papier à utiliser" sont écrites, - des déclarations du début d'édition en recto ou en verso sont écrites, - des contrôles de polices et de logos à utiliser sont effectués.

Lorsqu'un changement de page est détecté: - un contrôle est effectué pour un éventuel changement de bac d'alimentation papier, - des déclarations de codes de changements de page sont écrites.

Lorsqu'un changement de données est détecté : - une table des caractéristiques des données est lue, - des déclarations d'alignement sont écrites, si le paragraphe est justifié, - des déclarations des coordonnées d'affichage/impression de la donnée sont écrites.

D'autres écritures de déclarations sont disponibles notamment pour déclarer un nombre de lignes d'espacements, et, sur lecture d'une table des caractéristiques de la police, déclarer le nom de la police, sa taille, l'interlignage, le soulignement au besoin.

D'autres interventions possibles consistent en la transformation de certains caractères (ceux qui sont utilisés comme commande dans le format VIPP), ou encore en l'écriture des déclarations du type d'alignement dans le cas d'un nouveau paragraphe.

Dans le cas d'un élément graphique: - les caractéristiques de l'élément graphique sont lues dans une table, - les déclarations de la donnée du fichier natif sont écrites.

Le fichier se termine par des déclarations de fin d'édition au format VIPP.

Il est maintenant possible de résumer l'application de l'invention à l'affacturage.

On considère un "vendeur", qui a passé un contrat général d'affacturage avec l'affactureur Ensuite, le vendeur peut déléguer à un opérateur comptable la saisie des factures à déléguer à l'affactureur. Cette saisie s'effectue en direct à partir d'un poste distant, sur un réseau étendu comme Internet, Après identification de l'opérateur, donc du vendeur, un jeton unique est utilisé pour obtenir une saisie en ligne sûre, à la fois entre opérateurs de différents vendeurs, et au niveau d'éventuelles ruptures ou anomalies de transmission.

En fin de saisie, une délégation des factures saisies à l'affactureur est effectuée en ligne, par une personne habilitée, côté vendeur. Pour obtenir un caractère certain, juridiquement, cet acte de délégation de factures est accompagné d'une certification électronique, sur la base par exemple de clefs publiques PKI, définies par un tiers de confiance. Si des raisons 2 5 juridiques justifient une preuve supplémentaire, une version imprimée des factures saisies est établie, et retournée dûment signée à l'affactureur. L'impression peut se faire immédiate-ment, soit sur la base des informations saisies côté vendeur, soit sur la base d'un retour de fichier à imprimer, depuis l'affactureur vers le vendeur.

3 0 A partir de là, l'affactureur peut mener la mission qui lui est déléguée, à savoir encaisser les factures auprès des acheteurs, et les relancer au besoin.

Le vendeur peut également demander à l'affactureur: - de garantir le paiements de factures en instance, et/ou - de lui consentir un crédit sur la base des paiements de factures en instance.

Ces demandes s'effectuent avec la même sécurité et le même caractère certain que la saisie des factures en ligne.

Ainsi, l'invention permet bien d'effectuer en ligne, sur un réseau étendu, donc ouvert, la saisie de documents de grande taille ayant valeur juridique entre les parties, de façon sûre et certifiable.

On peut en outre obtenir une correspondance étroite entre la version saisie à l'écran et la version papier d'accompagnement.

Par la suite, un opérateur du vendeur pourra consulter son ou ses comptes, toujours à l'écran et sur son poste distant.

L'affactureur doit délivrer au vendeur des documents de compte rendu, à caractère systématique et/ou périodique. Par ailleurs, des personnels de l'affactureur gèrent les comptes des vendeurs, et sont à disposition des vendeurs pour répondre en ligne à leurs questions. On a décrit l'usage des fichiers natifs en interne chez l'affactureur. Ils permettent d'établir plusieurs versions d'un même document imprimé ou visualisé, tout en faisant en sorte que les présentations du contenu, dans les différentes versions soient identiques ou très proches. Ceci contribue de manière considérable à faciliter le travail et la discussion à distance entre les vendeurs et les personnels de l'affactureur.

2 0 Ainsi, les moyens décrits permettent une avancée considérable vers un traitement à distance de l'affacturage. On peut ainsi limiter au maximum les frais de saisie informatique, aussi bien que les frais de gestion des comptes, au niveau des compte-rendus et du dialogue avec les vendeurs.

Lors de l'interaction à distance, les opérations effectuées par le système peuvent être les suivantes: - vérifier l'identification du vendeur, débuter une session vendeur par la création d'un objet vendeur et d'un jeton unique attribué à cet objet vendeur, ce jeton identifiant l'avancement de la session du vendeur et 3 0 l'objet vendeur contenant le déroulement de la session jusqu'à l'état courant de son avancement, - en réponse à une demande de saisie du vendeur associée au jeton, renvoyer du serveur un formulaire de saisie associé au jeton, - enregistrer les informations saisies reçues en retour avec le jeton, 3 5 - vérifier la validation de ces informations par le vendeur, puis la certification par un code personnel (PIN) d'une entité autorisée à certifier pour ce vendeur.

- au besoin, générer un fichier d'impression prévu pour être retourné comme document signé par le vendeur. b

Côté serveur d'affacturage (vers l'extérieur), cela peut faire intervenir les éléments suivants: - une fonction d'identification d'un vendeur sur réception d'un identifiant de vendeur, - une première fonction de création, pour créer un objet vendeur, avec un identifiant de vendeur, une deuxième fonction de création, pour créer un jeton unique, - une fonction d'attribution d'un jeton créé à un objet vendeur, un objet vendeur auquel est attribué un jeton définissant une session de vendeur, un conteneur pour stocker chaque objet vendeur et son jeton attribué, une fonction de recherche d'identifiant de vendeur dans les objets vendeur du conteneur, - une fonction d'échange entre au moins le serveur de services et le ou les postes vendeurs pour utiliser le jeton lors d'échanges d'informations durant la session du vendeur, le jeton permettant d'établir l'état en cours de la session.

A partir de là, le serveur de service est agencé pour appeler la fonction d'identification, la deuxième fonction de création et la fonction de recherche sur la demande d'un vendeur pour ouvrir une session de vendeur, puis pour appeler soit la première fonction de création et la fonction d'attribution, soit la fonction d'attribution seule en fonction notamment du résultat de la fonction de recherche, et ensuite pour appeler la fonction d'échange. 2 0 2 5

Annexe Al Table 1 - début de fichier Item Pos. Len. Type Val.

rec_code 1 1 N 1 soc_id 2 2 A filler 4 30 version_No 34 2 A Creat_Date 36 8 N Effect Date 44 8 N File class 52 20 A Filler 72 169 N Table 2 - corps de fichier Item Pos. Len. Type Val.

rec_code 1 1 N 2...8 soc_id 2 2 A vend id 4 6 N Doc_type 10 4 A PageNolnDoc 14 3 N PrintSide 17 1 A Data_pos 18 6 N PrintAttrib 24 6 N Graph_elmts 30 4 N LineJump 34 2 N Filler 36 5 A Data_Content 41 200_A Table 3 - fin de fichier Item Pos. Len. Type Val.

rec_code 1 1 N 9 soc_id 2 2 A filler 4 30 version_No 34 2 A NbOfRec 36 8 N Filler 44 197

Claims (22)

Revendications

1. Système informatique, comprenant: - une interface réseau (50), propre à initialiser une connexion avec un poste distant (91), - un gestionnaire de mémoire (410), propre à créer et maintenir un espace mémoire dédié à un poste distant, pour l'échange de données entre le système et ce poste distant (91), et - un gestionnaire de session (410), réagissant à une initialisation de connexion avec identification réussie en ouvrant une session de poste distant (91), associée à un jeton unique (315T), et à un espace mémoire dédié au poste distant dans le gestionnaire de mémoire, les échanges de données avec le poste distant (91) au cours d'une session étant condition-nés par la présence du jeton associé.

2. Système informatique selon la revendication 1, caractérisé en ce que le gestionnaire de mémoire (410) est agencé pour définir ledit espace mémoire dédié en tant qu'objet logiciel, associé à l'identifiant et au jeton unique.

3. Système informatique selon la revendication 2, caractérisé en ce qu'il comprend un conteneur (414) propre à stocker une correspondance entre des objets logiciels et des jetons uniques qui leur sont attribués.

4. Système informatique selon la revendication 3, caractérisé en ce que le gestionnaire de session (410) est agencé pour, après identification réussie, rechercher un objet logiciel correspondant à cette identification, et, s'il en existe, offrir au poste distant (91), comme premier échange avec jeton, la faculté de reprendre une tâche sur cet objet logiciel, ou de l'abandonner pour en créer un nouveau associé à une nouvelle tâche.

5. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le jeton unique est obtenu par la concaténation du résultat d'une fonction aléatoire sur la date courante, l'heure courante et une valeur aléatoire.

6. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le gestionnaire de session (410) de vendeur est agencé pour offrir à un poste distant (91) une fonction de saisie de données (320), une fonction de validation de données saisie, et au moins une fonction de post-traitement après saisie validée.

7. Système informatique selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une application de saisie à distance, offerte au poste distant (91), l'espace mémoire (419) dédié étant consacré au stockage temporaire de données saisies, en attente de validation.

8. Système informatique selon la revendication 7, caractérisé en ce que les données saisies sont des données de factures, soumises à distance à une entité d'affacturage, par un poste distant (91) de vendeur.

9. Système informatique selon la revendication 8, caractérisé en ce que le gestionnaire de session (410) est agencé pour offrir, à un poste distant (91) de vendeur, une fonction de saisie de factures (320), une fonction de validation de factures saisies pour remise en affacturage, une fonction de demande d'approbation de crédit (321) sur factures remises en affacturage, et une fonction de consultation de compte (322) chez l' affactureur.

10. Système informatique selon la revendication 9, caractérisé en ce qu'en mode de saisie de factures, le gestionnaire de session (410) opère par envoi au poste distant (91) d'un formulaire de saisie, avec attente d'un retour du formulaire complété, à chaque fois accompagné du jeton unique correspondant.

11. Système informatique selon l'une des revendications 9 et 10, caractérisé en ce que gestionnaire de session (410) est agencé pour subordonner au moins la fonction de validation de factures saisies pour remise en affacturage à une certification fondée sur un code personnel (PIN) de la part d'un acteur habilité côté vendeur.

12. Système informatique selon l'une des revendications 9 à 11, agencé comme un serveur d'échanges coopérant avec un serveur interne, caractérisé en ce que le serveur d'échanges 2 5 est agencé pour transmettre les saisies validées au serveur interne, lequel assure la tenue de comptes et les opérations connexes, sélectivement pour chaque entité vendeur.

13. Système informatique selon la revendication 12, caractérisé en ce que la validation définitive est conditionnée par l'envoi d'un autre document signé par le vendeur, par un 3 0 moyen autre que le réseau étendu.

14. Système informatique selon l'une des revendications 12 et 13, caractérisé en ce que le gestionnaire de session (410) est agencé pour offrir aussi, à un poste distant (91) de vendeur, une fonction de demande de garantie sur des factures saisies.

15. Système informatique selon l'une des revendications 12 à 14, caractérisé en ce qu'il comprend un générateur d'un fichier natif d'impression, relatif une impression à caractère probant, tirée d'un ensemble cohérent de données présentes dans le serveur interne, et un gestionnaire de documents capable de tirer de ce fichier natif des impressions orientées comptes selon différents formats.

16. Système informatique selon la revendication 15, caractérisé en ce que le gestionnaire 5 de documents comprend: - un accesseur (605) de fichier natif, capable de réagir à un identifiant de document en sélectionnant une portion correspondante du fichier natif, et - au moins deux constructeurs de visualisation/impression, capable de coopérer avec l'accesseur (605) de fichier natif pour construire deux fichiers de visualisation/impression, correspondant à un même contenu imprimable, ces deux constructeurs de visualisation/impression opérant sur des formats de fichier différents, ce qui permet de disposer, en interne et chez les vendeurs, de documents directement comparables, imprimés et/ou à l'écran.

17. Système informatique selon la revendication 16, caractérisé en ce que les constructeurs de visualisation/impression comprennent un constructeur de visualisation/impression opérant au format pdf.

18. Système informatique selon la revendication 16, caractérisé en ce que les constructeurs 2 0 de visualisation/impression comprennent un constructeur de visualisation/impression opérant selon un format de fichier image.

19. Système informatique selon la revendication 16, caractérisé en ce que les constructeurs de visualisation/impression comprennent un constructeur de visualisation/impression opérant selon un format de fichier d'échange, propre à être transmis pour impression en masse.

20.Système informatique, comprenant un serveur d'affacturage, propre à gérer des comptes de vendeurs établis sur la base de factures remises par chaque vendeur à l' affactureur, en fonction des encaissements de factures auprès d'acheteurs, de façon connue en soi, ainsi qu'un serveur d'applications vers l'extérieur, pour des postes distants, caractérisé en ce que le serveur d'applications vers l'extérieur est agencé pour travailler en réseau étendu avec un ou des postes distants de vendeurs, et pour répondre à un identifiant de vendeur pour une demande de saisie d'informations, en opérant une application de traitement de demande qui est propre: - à vérifier l'identification du vendeur, - à débuter la session vendeur par la création d'un objet vendeur et d'un jeton unique attribué à cet objet vendeur, ce jeton identifiant l'avancement de la session du vendeur et l'objet vendeur contenant le déroulement de la session jusqu'à l'état courant de son avancement, - à envoyer une demande de saisie du vendeur associée au jeton à un serveur réponse propre à renvoyer un formulaire de saisie associé au jeton, - à enregistrer les informations saisies reçues en retour avec le jeton, et - à vérifier la validation de ces informations par le vendeur, puis la certification par un code personnel (PIN) d'une entité autorisée à certifier pour ce vendeur.

21. Système informatique selon la revendication 20, caractérisé en ce que ladite application de traitement de demande est propre en outre - à générer un fichier d'impression prévu pour être retourné comme document signé par le vendeur.

22. Système informatique, comprenant un serveur de services d'affacturage interconnecté en réseau étendu avec un ou des postes vendeurs, caractérisé en ce que le serveur de services d'affacturage comprend - une fonction d'identification d'un vendeur sur réception d'un identifiant de vendeur, une première fonction de création d'un objet vendeur, un objet vendeur comprenant un identifiant de vendeur, 2 0 - une deuxième fonction de création d'un jeton unique, - une fonction d'attribution d'un jeton créé à un objet vendeur, un objet vendeur auquel est attribué un jeton définissant une session de vendeur, - un conteneur pour stocker chaque objet vendeur et son jeton attribué, - une fonction de recherche d'identifiant de vendeur dans les objets vendeur du conteneur, - une fonction d'échange entre au moins le serveur de services et le ou les postes vendeurs pour utiliser le jeton lors d'échanges d'informations durant la session du vendeur, le jeton permettant d'établir l'état en cours de la session, le serveur de service étant propre à appeler la fonction d'identification, la deuxième fonction de création et la fonction de recherche sur la demande d'un vendeur pour ouvrir une session 3 0 de vendeur, propre à appeler soit la première fonction de création et la fonction d'attribution, soit la fonction d'attribution seule en fonction d'au moins le résultat de la fonction de recherche, et propre à appeler également la fonction d'échange.