FR2835942A1

FR2835942A1 - Procede et dispositif de traitement d'information

Info

Publication number: FR2835942A1
Application number: FR0202176A
Authority: FR
Inventors: Eric Quere; Jean Fabrice Feuillet
Original assignee: Individual
Current assignee: Individual
Priority date: 2002-02-13
Filing date: 2002-02-13
Publication date: 2003-08-15

Abstract

Le procédé comporte :- une étape (100, 105, 110, 115) de communication d'informations entre un terminal utilisateur d'un client et un serveur distant- une étape (120) de transmission d'éléments représentatifs des informations communiquées, éléments comportant au moins une adresse électronique à un serveur d'information tiers, par la mise en oeuvre d'une interface programmable d'application,- une étape (130) d'archivage de l'adresse électronique du client, par le serveur d'information tiers, - à la date déterminée, une étape (135) de transmission à l'adresse électronique d'un courrier électronique requérant une réponse,- à réception de la réponse par le serveur d'information tiers, une étape (140)d'archivage,- si le client fournit une information de type prédéterminé, une étape (145) de traitement de ladite information avec transmission au serveur distant, - une étape (150) de détermination d'éléments statistiques, et - une étape (160) de consultation, par le serveur distant, des éléments statistiques.

Description

PROCEDE ET DISPOSITIF DE TRAITEMENT D'INFORMATION
La présente invention vise un procédé et un dispositif de suivi de commande en ligne. Elle s'applique, en particulier, à la gestion et au suivi de clientèle et de réclamations pour un site Internet.

La présente invention peut être mise en oeuvre techniquement d'au moins deux façons : - la première concerne la mise en place du dispositif sur le site marchand à partir d'un logiciel exécutable et son interface automatique, ou par l'intermédiaire d'un annuaire de services web. Le dispositif et ses traitements sont alors gérés par le système d'information, et - la deuxième concerne l'intégration de la totalité de l'invention et donc de toutes ses fonctionnalités au sein d'un progiciel cessible par téléchargement ou par support numérique (disquette, CD ROM,..).

L'Internet est aujourd'hui l'environnement naturel où sont disponibles les applications distribuées : Internet est un middleware (ou"logiciel médian", partie de la classe de logiciels qui assurent l'intermédiaire entre les applications et le transport des données par les réseaux) à grande échelle.

Les protocoles permettant de faire communiquer des applications distantes sont très sophistiqués : RMI (Remote Method Invocation pour Invocation à distance de méthode), CORBA (Common Object Request Broker Architecture, document de synthèse décrivant les mécanismes d'échange entre les modules d'applications développées pour une architecture distribuée), DCOM... (Distributed Common Object Model, extension de la norme de contrôle d'applications par d'autres applications COM introduite par MicroSoft, marque déposée, permettant à cette dernière de fonctionner en environnement réseau.). Ces protocoles sophistiqués imposent des coûts d'installation et utilisent beaucoup de ressources, matérielles ("hardware"), logicielles ("software"), et humaines. Tout d'abord, et c'est l'argument ayant le plus de poids, ils s'appuient souvent sur des protocoles de transport non naturels sur Internet, et ainsi peuvent mal s'intégrer dans la topologie d'un réseau qui comporte des coupe-feu ("firewalls"), Passerelle (gateways, équipement permettant à deux réseaux différents de communiquer), proxy (Ordinateur qui s'intercale entre un réseau privé et l'Internet, pour faire office de firewall (ou de cache). Dans ce dernier cas, il enregistre les pages Web transférées par les utilisateurs pour les délivrer sans qu'il soit nécessaire de se connecter sur le serveur initial),.... Par ailleurs ils nécessitent souvent un déploiement server-side (c'est-à-dire sur le serveur) assez important, et qui s'amplifie encore d'avantage lorsque l'on veut

obtenir un couplage faible entre les noeuds de l'application répartie. Enfin les spécifications caractérisant ces standards sont complexes et étendues (en particulier les spécifications Corba), et entraînent, dans un projet, une inertie initiale due à une phase de conception inévitablement alourdie (typiquement mise en oeuvre de définitions IDL, Interface Definition Language), tout à fait inadaptée à la réalisation d'une application distribuée dont la complexité trouve son origine dans la répartition des noeuds, plus que dans la complexité de chaque noeud pris indépendamment.

Il s'ensuit, pour les sites marchands, une grande difficulté pour suivre les commandes, les tiers fournisseurs intervenant dans leur transport ou leur assurance et, plus généralement dans la collecte et le suivi des informations stratégiques concernant leur clientèle.

La présente invention vise à remédier à ces inconvénients.

A cet effet, selon un premier aspect, la présente invention vise un procédé de traitement d'informations relatives à un site marchand et à un client, caractérisé en ce qu'il comporte : - une étape de commande au cours de laquelle le client passe une commande par l'intermédiaire d'un terminal utilisateur auprès du site marchand par l'intermédiaire d'un serveur de site, une étape de paiement, au cours de laquelle le client paye sa commande, par exemple par fourniture d'un numéro de carte bancaire et de sa date d'expiration, une étape de validation de paiement par la banque auprès du site marchand, - une étape de traitement de la commande par le site marchand, - une étape de transmission des éléments essentiels de la commande comportant au moins un objet de la commande et un montant de la commande et d'une adresse électronique du client à un serveur d'information tiers, par la mise en oeuvre d'une interface programmable d'application, une étape d'archivage des éléments essentiels de la commande et de l'adresse électronique du client, par le serveur d'information, - une étape de détermination d'une date de satisfaction probable de la commande, à la date déterminée, - une étape de transmission à l'adresse électronique du client d'un courrier électronique (en anglais"e-mail") dit"de satisfaction"invitant le client à y répondre et à donner une information de suivi de commande, - à réception de la réponse du client, une étape d'archivage des éléments de réponse du client,

- si le client fournit une information relative à un mécontentement du client, une étape de traitement dudit litige comportant au moins une étape de transmission au site marchand de l'information relative audit mécontentement, une étape de détermination d'éléments statistiques concernant des clients du site marchand, statistique comportant au moins une information relative aux mécontentements des clients, et une étape de consultation, par le site marchand, des éléments statistiques.

Selon une autre caractéristique de l'invention, la date de satisfaction probable de la commande est définie automatiquement notamment à partir de la grille des délais du transporteur.

Ainsi, dés qu'un client passe une commande chez un site marchand mettant en oeuvre la présente invention, cette commande est validée (confirmation de paiement et de disponibilité, par exemple). Ensuite la commande est retransmise automatiquement vers le serveur d'informations pour la mise en oeuvre de la présente invention. Le système d'information mémorise la commande ainsi que sa date et l'ensemble des informations liées à cette commande jusqu'à l'acceptation finale de la commande par le client.

Le service de confirmation en ligne objet de la présente invention permet l'émission automatique d'un mail de confirmation électronique de réception de commande. En cas de non-satisfaction du client, une procédure est mise en place ainsi qu'un suivi et une mémorisation du litige avec datation d'au moins un événement qui compose son traitement.

L'ensemble des informations archivées constitue une source d'informations stratégiques inconnu à la date de la présente invention. Ce système d'informations stratégiques est la base d'un système de pilotage du site marchand, avec capacité de contrôle, adaptabilité, capacité d'apprentissage et fiabilité. Ces informations sont préférentiellement présentées sous forme de tableaux de bord et sont accessibles de façon sélective, avec des droits d'accès individuels.

Ce service est donc un outil de mesure de la performance du site marchand et plus généralement de sites avec des fonctions transactionnelles. Il permet d'éventuelles actions correctives et donne des éléments tangibles d'appréciation lors des renégociations d'un contrat de transport des biens vendus par le site, d'un contrat d'assurance et, plus généralement, des contrats de fourniture et services entrant dans l'offre du site marchand. Le site marchand peut, de son côté, pleinement se préoccuper de son coeur d'activité et de sa démarche commerciale. Pour le fournisseur des services

objets de la présente invention, mis en oeuvre par le serveur d'information, ces services permettent aussi une collecte d'informations stratégiquement complémentaires aux données collectées dans le cadre du retour d'expérience des sites marchands et des internautes acheteurs (via forum, courrier électronique).

La mise en oeuvre de la présente invention fournit : - un outil de mesure de la performance du transporteur/intégrateur/prestataire qui permet d'éventuelles actions correctives et donne des éléments tangibles d'appréciation lors des renégociations du contrat de transport, - pour le site d'information, ce service permet aussi une collecte d'informations stratégiques (dans une perspective de commercialisation des données statistiques), - des informations marketing sur l'activité marchande du site, telles que provenance des clients, quantités achetées en absolu et en moyenne, panier moyen mais aussi en restituant des données fondamentales fournies par le client sur l'appréciation de la qualité du bien acheté, de son intégrité et de sa conservation à la réception, du délai réel d'acheminement et de son acceptabilité commerciale, - en terme de marketing achat, des évaluations du transporteur/intégrateur/prestataire pour permettre au responsable du site marchand de gagner du temps, de rester objectif dans ses choix et de présenter une décision argumentée, un service de gestion de relation client (en anglais"CRM"pour"customer relationship management") pour le site marchand, service qui lui permet de mesurer la qualité de son organisation logistique, d'autoriser des actions correctrices et de réduire de façon importante le degré ou le risque de mécontentement du client et donc de fidéliser ledit client.

Selon des caractéristiques particulières, au cours de l'étape de détermination de date, la date est fournie par le site marchand.

Selon des caractéristiques particulières, au cours de l'étape de détermination de date, la date est fournie par le client, en réponse à un courrier électronique transmis à son adresse électronique.

Selon des caractéristiques particulières, au cours de l'étape de détermination de date, la date est déterminée par addition d'un délai de livraison à une date d'expédition transmise par le site marchand.

Selon des caractéristiques particulières, au cours de l'étape de détermination de date, la date est déterminée, pour les produits disponibles, par addition d'un délai de

livraison à un délai de traitement de la commande, par exemple un jour après la date de la commande.

Selon des caractéristiques particulières, au cours de l'étape de détermination de date, la date est déterminée sur la base de critère historique et par croisement avec une base de données relatives au site marchand.

Grâce à chacune de ces dispositions, l'étape de détermination de la date est aisée et efficace.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de mémorisation et de datation de chaque communication relative au mécontentement du client, entre le site marchand et le client.

Les autres communications du client (pas de mécontentement) sont archivées et traitées statistiquement pour répondre à la fourniture de l'invention telle que décrite précédemment (informations de marketing, outils de mesure de la performance,...)
Selon des caractéristiques particulières, au cours de l'étape de transmission de courrier électronique, le courrier électronique comporte au moins un élément essentiel de la commande et un identifiant du site marchand.

Selon des caractéristiques particulières, au cours de l'étape de transmission d'éléments essentiels, les éléments essentiels comportent, en outre : - un numéro de référence ou numéro de commande (attribué par le site marchand), - une désignation du ou des articles commandés, - une quantité de chaque article commandé, - une date de commande, une date de livraison prévue, - un nom du transporteur, - des coordonnées du client, - un prix, éventuellement détaillé, - des frais de port, et/ou - un numéro d'expédition (pour suivi du colis) ; et au cours de l'étape transmission de courrier électronique, le courrier électronique comporte au moins un desdits éléments.

Grâce à chacune de ces dispositions, l'information conservée par le serveur d'information est riche et détaillée. Le serveur d'information par le processus de l'invention va enrichir l'information au fur et à mesure des traitements.

Selon des caractéristiques particulières, au cours de l'étape de transmission des éléments essentiels, le serveur du site marchand effectue : - une étape de connexion au serveur d'information, - une étape d'identification du site marchand, - une étape d'écriture, dans la base de données du serveur d'information, des éléments essentiels de la commande.

Grâce à ces dispositions, le serveur d'information est mis en oeuvre par le serveur du site marchand, ce qui est efficace et évite une perturbation du serveur du site marchand par le serveur d'information.

D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite en regard des dessins annexés dans lesquels : - la figure 1 représente un logigramme de mise en oeuvre d'un mode de réalisation exemplaire du procédé objet de la présente invention ; - la figure 2 représente, schématiquement, une architecture simplifiée de communication entre un serveur de site marchand et un serveur d'information, dans mode particulier de réalisation de la présente invention ; et - la figure 3 représente, schématiquement, un mode particulier d'implémentation du procédé objet de la présente invention.

Dans un premier mode de réalisation, illustré en figure 1, le procédé objet de la présente invention comporte : une étape 100 de commande au cours de laquelle le client passe une commande par l'intermédiaire d'un terminal utilisateur et d'un serveur de site auprès du site marchand, une étape 105 de paiement, au cours de laquelle le client paye sa commande, par exemple par fourniture d'un numéro de carte bancaire et de sa date d'expiration, une étape 110 de validation de paiement par la banque auprès du site marchand, une étape 115 de traitement de la commande par le site marchand et, parallèlement, une étape 120 de transmission des éléments essentiels de la commande comportant au moins un objet de la commande et un montant de la commande et d'une adresse électronique du client à un serveur d'information tiers, par la mise en oeuvre d'une API (pour"Application Programmable
Interface"ou Interface programmable d'application) spécifique,

- une étape 125 de détermination d'une date de satisfaction probable de la commande, une étape 130 d'archivage des éléments essentiels de la commande et de l'adresse électronique du client, par le serveur d'information, à la date déterminée, une étape 135 de transmission à l'adresse électronique du client d'un courrier électronique (en anglais"e-mail") dit"de satisfaction"invitant le client à y répondre et à donner une information de suivi de commande (par exemple suivi ou appréciation de livraison), - à réception de la réponse du client, une étape 140 d'archivage des éléments de réponse du client, si le client fournit une information relative à un mécontentement, une étape 145 de traitement dudit litige comportant au moins une étape de transmission au site marchand de l'information relative audit mécontentement, une étape 150 de détermination d'éléments statistiques concernant une partie des clients ou l'ensemble des clients du site marchand, statistiques comportant au moins une information relative aux mécontentements des clients, une étape 155 de mémorisation et de datation de chaque communication relative au mécontentement du client, entre le site marchand et le client, et une étape 160 de consultation, par le site marchand, des éléments statistiques.

On observe que, au cours de l'étape 125 de détermination d'une date de satisfaction probable de la commande, la date est fournie soit par le site marchand, soit par le client, en réponse à un courrier électronique transmis par le serveur de site, à son adresse électronique, soit par addition d'un délai de livraison à une date d'expédition transmise par le site marchand, soit, pour les produits disponibles, par addition d'un délai de livraison à un délai de traitement de la commande, par exemple un jour après la date de la commande Au cours de l'étape 125, la date peut aussi être déterminée en fonction d'au moins un critère historique relatif au site marchand, aux articles commandés et/ou au client.

Préférentiellement, au cours de l'étape 120 de transmission d'éléments essentiels, les éléments essentiels comportent, en outre : - un numéro de référence ou numéro de commande (attribué par le site marchand), - une désignation du ou des articles commandés, une quantité de chaque article commandé, - une date de commande,

- une date de livraison prévue, - un nom du transporteur, - des coordonnées du client, - un prix, éventuellement détaillé, - des frais de port, et/ou - un numéro d'expédition (pour suivi du colis).

Au cours de l'étape 135 de transmission de courrier électronique, le courrier électronique comporte préférentiellement au moins un élément essentiel de la commande et un identifiant du site marchand.

On observe que, au cours de l'étape 150 de détermination d'éléments statistiques, ceux-ci comportent, éventuellement, par site, pour chaque article vendu sur le site marchand - le taux de client ayant exprimé un mécontentement, - le nombre moyen de communication entre le site et le client nécessaire à la satisfaction des clients ayant exprimé un mécontentement, - des informations à caractère logistique sur la qualité de service des transporteurs et des prestataires logistiques telles que taux de qualité de service par transporteur (nombre de litiges/nombre de livraison), type de litiges par transporteur, par destination, par produit - des informations à caractère marketing, - des données d'évaluation sur la qualité d'emballage.

Ces statistiques portant sur les prestations logistiques sont produites par le web marchand mais également de façon globale.

Comme illustré en figure 1, le service de confirmation en ligne objet de la présente invention permet ainsi l'émission automatique d'un mail de confirmation de réception, et en retour (envoi du mail par le client) la confirmation de la réception ou la détection pro-active d'un problème de livraison (casse, non-livraison, absence...). En cas de non-satisfaction du client, une procédure est mise en place ainsi qu'un suivi et une mémorisation complète du litige avec datation des événements successifs qui composent son traitement.

Le logiciel de communication entre le site marchand et le site d'information se présente sous forme d'un exécutable et d'une interface. Le marchand l'intègre à son site marchand et se charge de le mettre en oeuvre à chaque nouvelle commande acceptée.

Compte tenu de la diversité des plates-formes client, ce module est hautement portable.

En effet, le problème doit se poser en termes d'interopérabilité entre les sites marchands, les logisticiens et le système central du site d'information.

Le logiciel de communication entre le site marchand et le site d'information met en oeuvre les fonctionnalités de base suivantes : - connections au site d'information, - identification du site marchand, - écriture, dans la base de données du site d'information, des informations concernant la commande en cours.

La mise en oeuvre de la présente invention fournit : - un outil de mesure de la performance du transporteur qui permet d'éventuelles actions correctives et donne des éléments tangibles d'appréciation lors des renégociations du contrat de transport, - pour le site d'information, ce service permet aussi une collecte d'informations stratégiques (dans une perspective de commercialisation des données statistiques), des informations marketing sur l'activité marchande du site, - un service de gestion de relation client (en anglais"CRM"pour"customer relationship management") pour le site marchand, service qui lui permet de mesurer notamment la qualité de son organisation logistique, d'autoriser des actions correctrices et de réduire de façon importante le degré de mécontentement du client.

L'architecture simplifiée est représentée par le schéma donné en figure 2. On observe, en figure 2, un serveur de site 200 mettant en oeuvre un navigateur 210 pour émettre et recevoir des requêtes et des réponses 220 en communication, sur Internet, avec un serveur d'information 230 comportant une interface mettant en oeuvre le protocole HTTP avec un DEAMON 240, des servlets 250 et un pilote JDBC 260, en relation avec une base de données 270.

Chaque servi et (Programme Java s'exécutant sur un serveur HTTP) 250 est un module pouvant s'exécuter à l'intérieur d'un serveur Web. Les servlets 250 sont un substitut aux scripts CGI (Common Gateway Interface, norme d'interfaçage d'applications exécutables et de sites Web. cette norme permet de mettre à disposition des concepteurs de pages, d'outils tels que compteurs de visite, traitement de formulaires, gestion de bases de données etc...) en étant plus simples à développer et plus rapides à l'exécution. En effet, le mécanisme CGI nécessite, pour chaque requête, le démarrage d'un processus"lourd". Les servlets s'exécutent comme des threads (pour "tâche légère", processus léger, correspondant à l'exécution d'un petit

programme, ou d'une routine d'un programme plus gros, indépendamment de celui-ci) dans un même interpréteur. Les changements de contexte sont donc plus rapides.

Le protocole HTTP (pour"hypertext transfer protocol" ou protocole de transmission hypertexte) définit un mode simple de communication selon le modèle requête-réponse. Une requête HTTP est principalement composée du nom d'une méthode (action à réaliser) et d'une URL ("Universal Ressource Locator"pour adresse universelle de ressource) désignant l'objet recherché (document html, c'est-à-dire décrit en langage hypertext markup language, script à exécuter...).

L'application mise en oeuvre par le serveur d'information est constituée d'un ensemble de servlets. Deux méthodes HTTP permettent de transmettre les informations au serveur : GET et PUT. PUT permet d'envoyer de grandes quantités d'information. A titre d'exemple : un servlet"NouvelleCommande" gère la demande de prise en charge d'une commande. un servlet"TableauDeMesure"génère une liste des tableaux de mesure accessibles par le client. La couche de persistance.

Pour l'implémentation, les données permanentes (site marchand, produits, commandes, etc. ) sont stockées dans la base de données relationnelle 270, et rendues accessibles au travers de l'API JDBC (pour Java DataBase Connectivity, interface de programmation pour langage JAVA permettant l'accès et la gestion de bases de données). Nous proposons de définir une interface Java (appelée"DataStore", par exemple), dans laquelle toutes les fonctions Java de consultation et de modification de cette base sont définies. Cette interface peut, lors de l'exécution de l'application du serveur, être disponible via un objet singleton chargé de gérer les accès à la base. Les accès concurrents sont gérés par la base de données.

L'API"JDBC"est une API permettant de se connecter à n'importe quelle base de données relationnelle, d'exécuter des requêtes SQL et de lire les résultats. Pour cela, chaque base de données doit proposer un driver spécifique. On peut trouver l'ensemble des drivers existant sur le site de Java consacré à l'API"JDBC".

Le driver (en français"pilote")"JDBC"260 imp) émente trois interfaces principales de l'API JDBC : - l'interface "Connection", qui gère l'établissement et la fermeture de la connexion avec la base ainsi que les droits d'accès.

- l'interface"Statement"qui exécute les requêtes SQL (pour"Simple Query Language").

- l'interface "Results" qui donne accès aux résultats sous forme de table.

Dans un mode de réalisation de la présente invention, la solution adoptée est SOAP (pour"Simple Object Access Protocol") définit un protocole permettant des appels de procédures à distances, RPC, s'appuyant principalement sur le protocole HTTP et sur XML, mais aussi SMTP et POP. Il permet ainsi de définir des services WEB. Les paquets de données circulent sous forme de texte structuré au format XML, Extensible Markup Language. Ses spécifications étaient, au moment du choix, les plus avancées et les plus utilisées parmi celles avancées sur la liste de discussion du W3C consacrée à l'utilisation de XML (pour"extended markup language"ou langage de marquage étendu) comme base pour un format adressant l'échange de messages entre applications distantes. Le concurrent le plus important à l'époque était XML-RPC (pour remote procédure call , appel de procédure à distance), dont les implémentations possédaient leurs partisans. A la date de dépôt de la demande de brevet français, SOAP demeure le plus utilisé et le plus prometteur, bien que ses spécifications restent des W3C-recommandations, et ne soient pas encore des W3C-specifications.

L'application mettant en oeuvre la présente invention, dans le mode particulier de réalisation illustré en figure 2, est une application distribuée s'appuyant, pour la couche de transport, sur des protocoles naturels, se contentant des topologies réseau les plus contraignantes, et dont les mécanismes de RPC s'appuient uniquement sur un format textuel (XML).

Le prototype décrit ici a été développé, déployé et testé confidentiellement par l'inventeur. Quel que soit le statut des spécifications SOAP à ce jour, le choix d'une architecture de type RPC sur XML sur SMTP sur HTTP, demeure des plus pertinents.

L'inventeur a établit l'interopérabilité entre deux implémentations Open Source, c'est-à- dire en logiciel à code accessible à tous, des spécifications SOAP, l'une en Perl et l'autre en JAVA.

Le système d'information du serveur d'information peut s'interfacer avec les systèmes des sites marchands, quels que soient leurs langages d'implémentation et leurs plate-formes d'exécution. Le couplage entre le système d'information et les systèmes de chacun de ses sites marchands est faible. A cet effet, l'indisponibilité du noeud du système d'information (qui intervient après la vente effective d'un produit par un site marchand) ne se propage pas, c'est à dire ne rend pas également indisponible les systèmes des sites marchands.

Si le temps de propagation de l'information n'a que peu d'incidence en lui même (tant que l'intervalle s'écoulant entre la vente et son enregistrement dans le système

d'information est inférieur au délai dit confirmation de commande), la qualité de cette propagation est importante ; il faut que toutes les commandes enregistrées chez un site marchand finissent par intégrer le système d'information.

Pour utiliser le protocole de communication SOAP il suffit de respecter ses spécifications, et ceci peut être effectué par n'importe quel langage. Aujourd'hui la plupart des langages ont des librairies implémentant les spécifications SOAP. Le site marchand comme le serveur d'information peuvent donc être écrits avec un langage quelconque. Ils doivent simplement être capables de construire les fichiers XML décrivant les messages et de les envoyer par HTTP au destinataire. Le client effectue une requête SOAP, le serveur SOAP appelle l'API de confirmation de commande qui a été demandée avec les paramètres décrit dans le fichier XML.

Le moyen le plus naturel de parvenir à un couplage faible nous paraît être l'utilisation d'un protocole de communication asynchrone. Le logiciel côté site marchand effectue une requête sur le serveur d'information et continue son traitement sans attendre la réponse du serveur d'information. A cet effet, le protocole utilisé pour transporter les messages inter sites est le protocole SMTP.

En figure 3 sont représentés un site marchand 300, une boîte aux lettres électronique 302 d'adresse électronique soap~requete&commat;kireli. com, une boîte aux lettres électronique 304 d'adresse électronique sitemarchand~reponse&commat;kireli. com, un pont 306, un serveur http 308, un serveur SOAP 310 et une API 312.

Tout d'abord, le site marchand 300 pose sa requête 322 sous forme de courrier électronique (courrier de confirmation de commande) dans le récipient 302 soap~requete&commat;kireli. com. Le contenu du courrier électronique est constitué des données XML permettant l'appel de l'API de confirmation de commande sur le serveur d'information. L'adresse de retour du courrier électronique est sitemarchand~reponse&commat;kireli. com, ou"sitemarchand"représente le nom ou un identifiant du site marchand.

Le pont (en anglais"bridge") 306 HTTP2SMTP2HTTP effectue périodiquement des POP sur le récipient 302 soap~requete&commat;kireli. com. Lorsque le pont 306 récupère le courrier électronique de confirmation de commande, il prend le contenu XML de celui-ci et effectue une requête HTTP à l'adresse http ://www. kireli. com/soap/rpcrouter du serveur http 308.

Le serveur http 308 reçoit ainsi une requête HTTP sur son mapping /soap/rpcrouter, il redirige cette requête sur la servlet SOAP ou serveur SOAP 310, analyse les données XML d'après les spécifications SOAP du W3C afin de déterminer

quelle est l'API cible de la requête. L'API de confirmation de commande 312 est appelée et effectue son traitement à partir des paramètres que lui a donnés le serveur SOAP. L'API de confirmation de commande 312 renvoie les valeurs de retour au programme qui l'a appelé, c'est à dire le serveur SOAP.

Le serveur SOAP 310 traduit en XML selon les spécifications SOAP du W3C les valeurs de retour. Il renvoie ces données au programme appelant c'est à dire le serveur Http 308. Le serveur Http 308 renvoie, via le protocole http, les données XML au pont 306. Le pont 306 pose dans le récipient 304 sitemarchand~reponse&commat;kireli. com un courrier électronique 324 contenant les données XML. Le récipient de retour est l'adresse indiquée dans le libellé"de" (en anglais"from") du courrier électronique de départ 322.

Le site marchand 300 effectue, pendant ses heures creuses, des POP sur le récipient 304 sitemarchand~reponse&commat;kireli. com Il traduit, grâce aux spécifications SOAP du W3C, les données XML.

Si le serveur d'information 308 est inactif ou si le réseau Internet est saturé, le serveur de mails du site marchand 300 garde le message à envoyer 322 tant que celuici n'a pas atteint sa destination. De cette manière, sauf si le réseau Internet implose , le message 322 arrive, malgré tout, tôt ou tard, au serveur d'information 308.

La partie du logiciel mise en oeuvre sur le serveur du site marchand 300 implique simplement le postage d'un courrier électronique 322 pour l'invocation. Le postage est rapide donc l'exécution du site marchand n'est pas modifiée. Pour récupérer la réponse, le site marchand 304 effectue un POP sur la boîte aux lettres 304 sitemarchand~reponse&commat;kireli. com. Ce POP peut être effectué pendant ces heures "creuses". C'est une communication asynchrone. Comme il a été détaillé dans le paragraphe précédent, le choix technique correspondant aux besoins de l'application de confirmation de commande est le suivant. Le serveur d'information 308 communique avec les serveurs de sites marchands 300 par l'intermédiaire du protocole de communication SOAP sur le protocole de transport SMTP afin de permettre une communication asynchrone robuste avec des serveurs quelconques.

Le logiciel mis en oeuvre par le serveur d'information 308 intègre également le suivi de commande effectué par le site marchand 300 : un Daemon (Disk And Execution MONitor : un programme installé sur un système UNIX pour accomplir automatiquement une tâche spécifique ou pour contrôler un périphérique. C'est sous cet intitulé souvent que vous reviennent vos e-mails mal arrivés) scrute périodiquement la base de données afin d'alerter, par courrier électronique, les clients des sites marchands 300. Les clients

reçoivent un courrier électronique les invitant à remplir les formulaires du confirmation de commande. Ces formulaires exécutent des servlets : dans ce cas précis il n'est pas nécessaire de passer par une communication SOAP.

Serveur HTTP 308 : Apache est le produit phare du projet Apache. C'est le serveur HTTP le plus utilisé et l'un des plus robustes. Container J2EE : met en oeuvre Apache Tomcat
Serveur SOAP 310 : l'inventeur a utilisé l'implémentation JAVA Apache SOAP (qui fournit également l'implémentation du pont SMTP2HTTP), et l'implémentation Perl SOAP : : Lite. MySQL : nous avons choisi comme serveur de données un SGBD relationnel (Système de Gestion de Base de Données) Open Source fiable, léger, rapide, et bien documenté. Quoiqu'il en soit, l'application de confirmation de commande communicant avec la base de données exclusivement via l'API JDBC, changer de RDBMS serait transparent. DOM/SAX : manipuler des documents XML requiert une implémentation des spécifications W3C SAX et DOM ; là encore l'inventeur a utilisé un logiciel du projet Apache Jakarta, Apache Xerces.

Comme déjà mentionné en introduction, le Simple Object Access Protocol ("SOAP") est une spécification adressant la mise en oeuvre de mécanismes de RPC, par échange de messages textuels (encapsulant donc requêtes et réponses) au format XML. Ces spécifications ne posent pas de contraintes fortes sur la couche de transport utilisée, mais privilégie tout de même les protocoles HTTP et SMTP. Cette spécification a été soumise au W3C par IBM, Microsoft et Lotus, où elle demeure, un peu plus d'un an après, avec le statut"sousmission" (en anglais"submission").

Il s'agit d'utiliser SOAP pour rendre disponible, via HTTP, une API (Application Programmable Interface) implémentée sur un serveur ; la première étape est donc naturellement la définition de cette API. Comme nous l'avons déjà suggéré, cette définition ne doit pas être décrite en IDL.

Le serveur SOAP, grâce au ficher de déploiement suivant, fait le lien entre l'invocation de l'URN"urn : Hello-World" et l'appel à la méthode hello () de la class perso. test. soap. Helio. L'URN est le pendant pour SOAP de l'URL pour HTTP : l'URN permet d'identifier de façon unique une API déployé sur un endpoint SOAP.

Le texte de déploiement est de la forme : < isd : service xm Ins : isd="http ://xm 1. apache. org/xml-soa p/deployment" id="urn : apiHelloWorld" > < isd : provider type="java" scope="Application"

methods="hello" > < isd : java class="perso. test. soap. Helio" static="false"/ > < /isd : provider > < /isd : service >
L'implémentation JAVA pourrait être simplement : package perso. test. soap ; public class Helio { public String hello (String personne) { return "Hello"+personne+"!!!"; } }
L'invocation correspond à l'envoi d'un message XML par l'appelant (ce message contient alors l'identification de l'API, la définition de l'appel à invoquer, ainsi que les éventuels paramètres nécessaires) ; l'implémentation de l'API répond elle aussi par message XML. La couche de transport considérée ici est HTTP ; on parle de SOAP sur HTTP.

Une requête HTTP encapsulant le message XML d'invocation est de la forme :
POST http ://www. kireli. com/soap~router HTTP/1.0
Content-Type : textlxml ; charset="utf-8"
Content-Length : 587 < SOAP-ENV : Envelope xmlns : SOAP-ENV=" http ://schemas. xmlsoap. org/soap/envelope/" xmlns : xsi=" http ://www. w3. org/1999/XMLSchema-instance" xmlns : xsd="http : //www. w3. org/1999/XMLSchema" > < SOAP-ENV : Header > < /SOAP-ENV : Header > < SOAP-ENV : Body >

< ns1 : hello xmlns : ns1 ="urn : apiHello~World" SOAP-ENV : encodingStyle=" http ://schemas. xmlsoap. org/soap/encoding/" > < name xsi : type="xsd : string" > TrucMuche < /name > < /ns1 : hello > < /SOAP-ENV : Body >

< /SOAP-ENV : Envelope > Une requête HTTP encapsulant la réponse serait de la forme : HTTP/1. 0 200 OK Content-Type. text/xml ; charset="utf-8" Content-Length : 615 < SOAP-ENVEnve) ope xmlns : SOAP-ENV=" http ://schemas. xmlsoap. org/soap/envelope/" xmlns : xsi=" http ://www. w3. org/1999/XMLSchema-instance" xmlns : xsd="http : //www. w3. org/1999/XMLSchema" > < SOAP-ENV : Body > < ns1 : helloResponse

xmlns : nus1 ="urn : apiHello~World"
SOAP-ENV : encodingStyle=" http ://schemas. xmlsoap. org/soap/encoding/" > < return xsi : type="xsd : string" > Helio TrucMuche ! ! ! < /return > < /ns1 : helloResponse > < /SOAP-ENV : Body > < /SOAP-ENV : Envelope >
On note que SOAP-ENV labellise le namespace http ://schemas. xmlsoap. org/soap/envelope/, xsi le namespace http ://www. w3. org/1999/XMLSchema-instance, et xsd le namespace http : //www. w3. org/1999/XMLSchema.

On observe que la communication avec le client du site marchand est effectuée par le serveur d'information en mettant en oeuvre un formulaire d'enquête de satisfaction permettant le remplissage d'une base de données comportant chaque site marchand, chaque client des sites marchands et chaque article vendu sur les sites marchands, chaque commande passée par un client avec référence aux articles commandés, date de livraison prévue et réponse au courrier électronique de satisfaction et/ou au formulaire d'enquête de satisfaction. Le serveur d'information calcule, en outre, des éléments statistiques relatifs, à chaque site, à chaque client, à chaque article et à chaque motif de mécontentement éventuel. La base de données conserve les éléments statistiques ainsi déterminés.

La présente demande décrit complètement le processus lié à la première façon de mise en oeuvre de l'invention, étant entendu que la deuxième façon intègre tous services et fonctionnalités techniques décrits et ne considère pas, par définition, les échanges entre un web marchand et la plateforme d'informations.

Claims

REVENDICATIONS

1. Procédé de traitement d'information, caractérisé en ce qu'il comporte : une étape (100,105, 110,115) de communication d'informations entre un terminal utilisateur d'un client et un serveur distant, une étape (120) de transmission d'éléments représentatifs des informations communiquées, éléments comportant au moins une adresse électronique à un serveur d'information tiers, par la mise en oeuvre d'une interface programmable d'application, une étape (130) d'archivage de l'adresse électronique du client, par le serveur d'information tiers, une étape (125) de détermination d'une date de transmission d'un courrier électronique, à la date déterminée, une étape (135) de transmission à l'adresse électronique du client d'un courrier électronique requérant une réponse, - à réception de la réponse par le serveur d'information tiers, une étape (140) d'archivage des éléments de réponse du client, - si le client fournit une information de type prédéterminé, une étape (145) de traitement de ladite information comportant au moins une étape de transmission au serveur distant de ladite information de type prédéterminé, une étape (150) de détermination d'éléments statistiques concernant les communications d'information au serveur distant, statistique comportant au moins une information relative aux dites informations de type prédéterminé, et une étape (160) de consultation, par le serveur distant, des éléments statistiques.

2. Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination de date, la date est fournie par le serveur distant.

3. Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination de date, la date est fournie par un terminal utilisateur, en réponse à un courrier électronique transmis à l'adresse électronique de son utilisateur.

4. Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination de date, la date est déterminée par addition d'un délai de livraison à une date d'expédition transmise par le serveur distant.

5. Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination de date, la date est déterminée par addition d'un premier délai prédéterminé à un deuxième délai prédéterminé.

6. Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination de date, la date est déterminée sur la base de critère historique et par croisement avec une base de données relatives au serveur distant.

7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comporte une étape (155) de mémorisation et de datation de chaque communication relative au terminal utilisateur, entre le serveur distant et le terminal utilisateur.

8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, au cours de l'étape de transmission de courrier électronique, le courrier électronique comporte au moins un élément essentiel des informations transmises par le terminal utilisateur et un identifiant du serveur distant.

9. Procédé selon la revendication 8, caractérisé en ce que, au cours de l'étape de transmission d'éléments essentiels, les éléments essentiels comportent, en outre : un numéro de référence ou numéro de commande (attribué par le site marchand), une désignation du ou des articles commandés, une quantité de chaque article commandé, une date de commande, une date de livraison prévue, un nom du transporteur, - des coordonnées du client, - un prix, éventuellement détaillé, - des frais de port, et/ou - un numéro d'expédition (pour suivi du colis) ; et au cours de l'étape transmission de courrier électronique, le courrier électronique comporte au moins un desdits éléments.

10. Procédé selon l'une quelconque des revendications 8 ou 9, caractérisé en ce que, au cours de l'étape de transmission d'éléments essentiels, le serveur distant effectue :

une étape de connexion au serveur d'information tiers, une étape d'identification du serveur distant, une étape d'écriture, dans la base de données du serveur d'information tiers, de chaque élément essentiel transmis.