FR2954844A3

FR2954844A3 - Data i.e. bank data, exchange management method for e.g. client server in electronic-commerce technical platform, involves partitioning commercial site utilization data having database structure linking account of client to merchant site

Info

Publication number: FR2954844A3
Application number: FR0906381A
Authority: FR
Inventors: Marc Guedj
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-12-29
Filing date: 2009-12-29
Publication date: 2011-07-01

Abstract

The method involves updating data i.e. promises of financial contributions, from clients. The data is hosted on a server independent of a commercial site and clients, and a process is implemented on the merchant site with insertion of Java(RTM: programming language) Script and cascading style sheet. Bank data of an organization for the commercial site is displayed in HTML and cascading style sheet templates. Utilization data of the commercial site comprising a database structure linking an account of client to the merchant site is partitioned.

Description

Description du procédé Etat de l'art / problématique : La fonction d'achat à plusieurs , qui se caractérise par une étape de cumul de plusieurs contributions financières de la part d'utilisateurs pour payer la même commande, est actuellement absente des plateformes e-commerce. Par ailleurs, la rigidité technique de ces plateformes e-commerce ajoutée à celle des paiement en ligne rend difficile voire impossible un développement spécifique pour un marchand qui souhaiterait une telle fonction . Alors qu'aujourd'hui, une grand majorité de sites marchands sont basés sur ces plateformes techniques, ils n'ont donc aucun moyen technique à leur disposition pour proposer une fonction d'achat à plusieurs sur leur site. Quant aux sites marchands ne reposant pas sur une plateforme e-commerce, ils sont obligés de recourir à des développements sur mesure. En plus des couts conséquents de développement et des difficultés technique d'intégration, ce type de service est en général développé autour des modes de paiement en ligne déjà acceptés par le site marchand. Le service obtenu comporte alors des contraintes importantes liées à l'arrière-boutique (connue sous le terme « back office » par les hommes de métier) telles que de nombreuses opérations manuelles pour le marchand, dues aux demandes de remboursement et d'annulation, lorsque par exemple, le montant total des contributions financières n'a pas atteint le minimum requis pour l'achat prévu initialement, ou bien lorsque les articles ne sont plus en stock. Supprimer les contraintes et le surcroît de travail liés à l'arrière-boutique (connue sous le terme « back office » par les hommes de métier) Au préalable, le procédé inclut une fonction d'enregistrement d'une « sélection » d'articles depuis le site du marchand, ceci afin de pourvoir calculer et définir le montant total de l'achat à financer à plusieurs ; cet objectif d'achat à plusieurs étant représentée par ce qu'on appelle communément une « collecte ». Description of the process State of the art / problematic: The multiple purchase function, which is characterized by a step of cumulating several financial contributions from users to pay for the same order, is currently absent from the platforms e- trade. Moreover, the technical rigidity of these e-commerce platforms added to that of online payment makes it difficult or impossible to develop specifically for a merchant who would like such a function. While today, a large majority of merchant sites are based on these technical platforms, they have no technical means at their disposal to offer a multi-purchase function on their site. As for merchant sites that do not rely on an e-commerce platform, they are obliged to resort to custom-made developments. In addition to the significant costs of development and integration technical difficulties, this type of service is generally developed around online payment methods already accepted by the merchant site. The service obtained then has significant constraints related to the back shop (known by the term "back office" by tradesmen) such as many manual operations for the merchant, due to requests for refund and cancellation, for example, the total amount of financial contributions has not reached the minimum required for the purchase originally planned, or when the items are no longer in stock. Remove the constraints and extra work related to the back shop (known as "back office" by tradesmen) The process beforehand includes a function of recording a "selection" of articles from the merchant site, in order to be able to calculate and define the total amount of the purchase to be financed by several; this goal of buying together is represented by what is commonly called a "collection".

Le procédé (figure 1) consiste à permettre techniquement à l'organisateur de recevoir lui-même et directement, les contributions financières des participants. Une fois l'argent collecté, l'organisateur peut alors passer la commande sur le site du marchand et ce, de manière classique. Ce procédé élimine totalement tous les problèmes d' arrière-boutique (connue sous le terme « back office » par les hommes de métier). En effet, jusqu'au moment du passage effectif de la commande, l'argent est entre les mains de l'organisateur. Le marchand n' a donc pas à effectuer de remboursement ou d'annulation, quelle qu'en soit la cause (somme insuffisante, articles devenus indisponibles...) comme ce serait le cas dans une solution classique ou c'est le marchand qui collecte les contributions financières. Pour ce faire, le procédé consiste donc aussi à permettre à l'organisateur de choisir parmi différents modes de paiement ( figure 2): 1. Remise en main propre : le participant remettra à l'organisateur une enveloppe avec des espèces ou un cheque. 2. Virement bancaire : le participant contactera sa banque pour réaliser un virement en faveur de l'organisateur. Le procédé inclut l'enregistrement et l'affichage des données bancaires de l'organisateur de façon à ce que le participant en prenne connaissance. -3 - -4 - 3. Tout autre moyen défini au préalable par l'organisateur. 4. Voie électronique : le participant effectue directement un paiement par carte bancaire classique. A cette fin, le procédé inclut l'enregistrement de l'adresse Paypal de l'organisateur ; le but étant que l'organisateur reçoive directement l'argent sur son propre compte PaypalR. The process (Figure 1) is to technically allow the organizer to receive himself and directly, the financial contributions of participants. Once the money has been collected, the organizer can then place the order on the merchant's site in a classic way. This process completely eliminates all back shop problems (known as "back office" by tradesmen). Indeed, until the actual passage of the order, the money is in the hands of the organizer. The merchant does not have to make any refund or cancellation, whatever the cause (insufficient sum, items become unavailable ...) as it would be the case in a conventional solution or it is the merchant who collects the financial contributions. To do this, the process also consists in allowing the organizer to choose among different payment methods (Figure 2): 1. Hand delivery: the participant will give the organizer an envelope with cash or a check. 2. Bank transfer: the participant will contact his bank to make a transfer in favor of the organizer. The method includes recording and displaying the organizer's bank details so that the participant becomes aware of them. -3 - -4 - 3. Any other means previously defined by the organizer. 4. Electronic way: the participant makes a direct payment by traditional bank card. For this purpose, the method includes the registration of the Paypal address of the organizer; the goal being that the organizer receives the money directly on his own PaypalR account.

Les modes 1, 2 et 3 ci-dessus requièrent une action différée dans le temps du participant, sur laquelle il n'est pas possible d'avoir un contrôle direct. Par conséquent et pour palier à cet inconvénient, le procédé inclut une fonction de suivi complet des participations qui consiste à: • Permettre au participant d'enregistrer une « promesse » de don. • Alerter l'organisateur lorsqu'une promesse a été enregistrée. • Permettre à l'organisateur d'enregistrer la réception effective du don : promesse tenue ; ceci afin de pouvoir remercier les donateurs et éventuellement relancer les mauvais payeurs. Le 4eme mode de paiement étant par voie électronique, il doit être instantané : le procédé inclut la 15 récupération en tant réel depuis le serveur de l'organisme financier responsable de la transaction R bancaire (comme Paypal ), de la notification instantanée de paiement, ceci afin de pouvoir mettre à jour la collecte automatiquement et sans aucune opération manuelle. La somme des dons (contributions financières) est recalculée après chaque contribution (électronique ou promesse) et peut-être représentée par une barre de progression ( figure 5), au 20 regard du montant total cumulé des prix des articles enregistrés dans la « sélection ». Par ailleurs, le procédé inclut la possibilité pour l'organisateur de définir un montant de participation fixe ainsi qu'une date limite au-delà de laquelle les participations ne sont plus acceptées. Si l'argent n'est pas utilisé pour la commande sur le site marchand, l'organisateur peut simplement le restituer aux participants et le marchand n'a aucune action à réaliser. 25 Réaliser un système de gestion d'achat à plusieurs pour sites marchands , totalement Independent de la plateforme technique e-commerce des site marchands Le procédé consiste aussi à : • Regrouper dans un « noyau commun » les fonctions et la base de données du système de gestion d'achat à plusieurs et l'héberger sur un serveur distant indépendant de celui du site marchand. • Mettre en place le système de gestion d'achat à plusieurs sur le site du marchand exclusivement grâce à des scripts JavaScripts et CSS à installer sur le serveur du site marchand. L'avantage de n'utiliser que ces types de fichiers réside dans le fait qu'ils sont acceptés universellement quelle que soit la plateforme technique du site marchand. • Lancer les fonctions d'achat à plusieurs sous la forme de liens et de boutons du type « acheter à plusieurs » ou « ajouter à ma liste » en pointant sur les fonctions JavaScripts mises en place sur le site marchand (voir au-dessus). 30 35 -5 - Par ailleurs, dans un système idéal totalement intégré, le marchand aurait directement accès aux informations qui lui sont utiles (par exemple les données d'inscription). Pour pallier ici au fait que la base de données n'est pas directement accessible au marchand (serveur distant et mutualisation), les données habituellement utiles au marchand doivent être renvoyées vers la base du site du marchand pour y être enregistrées . Pour ce faire, le procédé consiste à renvoyer les données utiles au marchand en temps réel (automatiquement) en méthode « GET » sur un script situé sur le serveur du site marchand pour synchronisation de la base du marchand avec ces données. Ceci rend possible par exemple l'utilisation de champ Optin pour l'abonnement à une Newsletter du marchand tout en lui permettant de disposer librement de sa mailing liste à jour en temps réel. Modes 1, 2 and 3 above require a deferred action in the participant's time, over which it is not possible to have direct control. Therefore, and to overcome this drawback, the method includes a complete participation tracking function that consists of: • Enabling the participant to record a "promise" of donation. • Alert the organizer when a promise has been recorded. • Allow the organizer to record the actual receipt of the donation: promise kept; this in order to thank the donors and eventually re-launch the bad payers. Since the 4th method of payment is electronic, it must be instantaneous: the method includes the recovery as real from the server of the financial institution responsible for the bank transaction R (like Paypal), the instant payment notification, this in order to update the collection automatically and without any manual operation. The sum of the donations (financial contributions) is recalculated after each contribution (electronic or pledge) and may be represented by a progress bar (FIG. 5), in view of the cumulative total amount of the prices of the articles recorded in the "selection". . In addition, the process includes the possibility for the organizer to define a fixed participation amount and a deadline beyond which entries are no longer accepted. If the money is not used for the order on the merchant site, the organizer can simply return it to the participants and the merchant has no action to perform. 25 Realizing a multiple purchase management system for commercial sites, totally Independent of the e-commerce technical platform of commercial sites The process also consists of: • Grouping together in a "common core" the functions and the database of the system purchase management and host it on a remote server independent of the merchant site. • Set up the multiple purchase management system on the merchant site exclusively through JavaScripts and CSS scripts to be installed on the server of the merchant site. The advantage of using only these types of files lies in the fact that they are accepted universally regardless of the technical platform of the merchant site. • Launch multiple purchase functions in the form of links and buttons of the type "buy to many" or "add to my list" by pointing to the JavaScripts functions implemented on the merchant site (see above) . Moreover, in a fully integrated ideal system, the merchant would have direct access to information that is useful to him (for example registration data). To overcome the fact that the database is not directly accessible to the merchant (remote server and pooling), the data usually useful to the merchant must be returned to the base of the merchant site to be recorded. To do this, the method consists in returning the useful data to the merchant in real time (automatically) in "GET" method on a script located on the server of the merchant site for synchronization of the merchant's database with this data. This makes it possible, for example, to use the Optin field for subscribing to a merchant's newsletter while allowing him to freely dispose of his mailing list updated in real time.

En outre, le procédé de gestion d'achat à plusieurs, pour être applicable concrètement à un site marchand, doit comporter un système d'affichage adéquat et indépendant pour chaque site marchand. Le procédé consiste donc aussi à : • Réaliser tous les affichages nécessaires au fonctionnement du système via une fenêtre additionnelle (appelée communément « popup » par les hommes du métier) ou, mieux, une technique « IFRAME » injectée dans la page du site marchand, ce qui rend les codes des pages du système de gestion indépendantes de celles du site du marchand. In addition, the multi-purchase management method, to be practically applicable to a merchant site, must include an adequate and independent display system for each merchant site. The method therefore also consists in: • Carrying out all the displays necessary for the operation of the system via an additional window (commonly called "popup" by those skilled in the art) or, better, an "IFRAME" technique injected into the page of the merchant site, This makes the codes of the management system pages independent of those of the merchant's site.

• Permettre une adaptation graphique poussée (textes, images, couleurs, formes...) totalement indépendante d'un marchand à l'autre tout en maintenant un noyau de fonctions commun à tous les sites marchands (semi-mutualisation). Pour ce faire : - La totalité de l'habillage graphique et des textes est complètement séparée du noyau de fonctions grâce à l'usage de modèles de pages CSS et HTML (appelés communément «templates CSS et HTML » par l'homme de métier), en conjonction avec un moteur de modèles de pages (appelé communément « moteur de templates » par l'homme de métier) dont le rôle principal est d'appeler les bons fichiers en fonction du site marchand. • Allow a graphic adaptation (texts, images, colors, forms ...) completely independent of a merchant to another while maintaining a core of functions common to all commercial sites (semi-mutualization). To do this: - The entire graphics and text wrapping is completely separate from the kernel of functions through the use of templates CSS and HTML pages (commonly called "CSS templates and HTML" by the skilled person) , in conjunction with a page template engine (commonly called "template engine" by the skilled person) whose main role is to call the right files based on the merchant site.

L'arborescence des fichiers est réalisée de façon à avoir un répertoire dédié par site marchand. Chacun de ces répertoires contient l'habillage graphique ainsi que les appels aux fonctions du noyau. Les fonctions du noyau sont elles-mêmes stockées dans un répertoire indépendant de tous les autres et commun à tous les sites. The file tree is made to have a dedicated directory by merchant site. Each of these directories contains the graphic skin as well as the calls to the kernel functions. The kernel functions are themselves stored in a directory independent of all others and common to all sites.

• Permettre au marchand de modifier lui-même le graphisme (par exemple pour des besoins saisonniers) en accédant directement à la totalité du matériel graphique (modèles de pages, images...) dédié à son site et dans un sous-répertoire « custom » ou sont placés les fichiers modifiables. Ce matériel étant situé sur un serveur distant, il pourra y accéder par FTP. Durant toute la vie du site marchand, l'identité visuelle est ainsi préservée. • Masquer complètement l'url du serveur distant sur lequel est hébergé le système de gestion d'achat à plusieurs, en la remplaçant par une url au choix du marchand (par exemple un sous-domaine du site du marchand) . Pour ce faire, le marchand fera pointer l'url (domaine ou sous- -6 - domaine) de son choix vers le répertoire qui lui est dédié sur l'hébergement distant (voir ci-dessus). • Allow the merchant to modify the graphics himself (for example for seasonal needs) by directly accessing all the graphic material (page templates, images ...) dedicated to his site and in a "custom" subdirectory Where the editable files are placed. Since this hardware is located on a remote server, it will be able to access it by FTP. Throughout the life of the merchant site, the visual identity is preserved. • Completely hide the URL of the remote server on which the multiple purchase management system is hosted, replacing it with a URL of the merchant's choice (for example, a subdomain of the merchant's site). To do this, the merchant will point the url (domain or sub-domain) of his choice to the directory that is dedicated to him on remote hosting (see above).

• N'afficher aucune marque autre que celle du marchand. • Cloisonner les données d'utilisation propres à chaque site marchand afin d'éviter tout interférence entre les données propres à chaque site marchand. Pour ce faire, il faut que la structure de la base de données fasse en sorte que le compte d'un organisateur utilisant le système d'achat à plusieurs soit lié au site marchand à partir duquel le compte à été créé. Par exemple, un organisateur qui, grâce au système de gestion d'achat à plusieurs, a crée un compte depuis un site A et a ouvert une collecte pour une sélection d'articles du site A, ne pourra accéder aux informations lés à cette collecte que depuis le site A, et ceci, même s'il a crée un autre compte depuis un site B utilisant lui aussi le système de gestion d'achat à plusieurs.15 ,-2 - Liste des figures Figure 1 : Principe de gestion d'achat à plusieurs Figure 2 : Choix des modes de paiement par l'organisateur Figure 3 : Visualisation des modes de paiement disponibles pour un participant/invité 5 Figure 4 : Exemple de tableau de suivi des contributions financières Figure 5 : Exemple de barre de progression de la collecte indiquant le statut de celle-ci • Do not display any brand other than the merchant. • Clone the usage data specific to each merchant site to avoid any interference between the data specific to each merchant site. To do this, the database structure must ensure that the account of an organizer using the multiple purchase system is linked to the merchant site from which the account was created. For example, an organizer who, through the multiple purchase management system, created an account from a site A and opened a collection for a selection of articles from site A, will not be able to access the information collected at this collection. only from the site A, and this, even if he created another account from a site B also using the multiple purchasing management system.15, -2 - List of figures Figure 1: Principle of management of Multiple Purchase Figure 2: Choice of payment methods by the organizer Figure 3: Visualization of payment methods available for a participant / guest 5 Figure 4: Example of a financial contribution tracking table Figure 5: Example of progress bar the collection indicating the status of it

Claims

REVENDICATIONS1. A method for managing the exchange of data between a first server called a merchant site and a set of second so-called client servers, characterized in that it comprises: data storage means known as pledges of financial contributions from the customers, and updating these data; Means for hosting this data on at least a third independent server of the merchant site and customers; • implementation of the process on the commercial site including the insertion of scripts 10 JavaScripts and CSS; A display adapted to the merchant site comprising models of HTML and CSS pages (known by those skilled in the art as "HTML and CSS templates"); Means for partitioning the usage data of the merchant site comprising a database structure linking the customer's account to the merchant's site. 15

2. Method according to claim 1, characterized in that it comprises: a step of accumulation of several financial contributions from participants in order to pay an order for a selection of articles; Means of payment allowing the participants to send their financial contributions directly to an organizer, who is not the merchant, and who is responsible for carrying out the said order once the accumulation of the contributions is sufficient to pay this amount. ordered ;

3. Method according to any one of claims 1 and 2, characterized in that it comprises: • means of recording instructions for the delivery of own financial contributions (checks, cash); Means for recording the bank account data in order to allow a bank transfer transaction by a third party; • means of exchange and communication by the global network (internet) between at least one independent server of the merchant site and a server of a banking organization such as Paypal for the purpose of recording payment card payment notifications for the automatic update of the collections.

4. Method according to any one of claims 1, 2 and 3, characterized in that it comprises a comparison of the current date to a deadline defined by an organizer and beyond which the financial contributions are no longer accepted.

5. Method according to any one of claims 1, 2, 3 and 4 characterized in that it comprises a function of return method "GET" useful data for the merchant 40 (eg registration data), in order to allow the recording of these data in the database of the commercial site.