WO2004014058A2 - Procede d'achat initie par l'utilisateur sur terminal mobile - Google Patents

Abstract

L'invention concerne un procédé de contrôle d'un processus d'achat par un équipement électronique de communication mobile (10), comprenant une étape d'identification d'au moins un produit ou d'au moins un service, étape mettant en oeuvre une transmission à un serveur d'achat (30) de données d'identification du produit ou du service par un message émis par l'équipement mobile (10), caractérisé en ce que le procédé met en oeuvre une étape de transmission de données de paiement permettant une transaction, et en ce que le procédé inclut la mise en oeuvre d'un protocole imposant la simultanéité des transmissions des données d'identification de produit ou de service avec la transmission des données de paiement, dans un même message.

Description

Procédé d'achat initié par l'utilisateur sur terminal mobile

La présente invention a pour objet le paiement de biens ou services à distance par terminal de communication mobile, notamment par téléphone mobile.

L'invention trouve une application dans les systèmes nécessitant un paiement, tels que les achats de biens et services, le paiement en matière de télévision à péage, le règlement de factures, et autres. On a déjà proposé un procédé, appelé ItiAchat (FR 2 790 162), qui permet le paiement à distance sur un téléphone mobile équipé d'un lecteur de carte bancaire.

Une offre de bien ou service est envoyée en message de type SMS (Short Message Service) par un téléphone mobile, le numéro de ce téléphone ayant été antérieurement communiqué par l'acheteur lors d'une phase de consultation en ligne, téléphonique ou par internet.

Ce SMS active une application SimTooIkit, demandant à l'utilisateur s'il veut effectuer le paiement de cette offre. Si tel est le cas, il introduit sa carte bancaire dans le lecteur du téléphone mobile, saisit son code confidentiel de carte bancaire, et, après calcul de certificats, un message SMS contenant les informations bancaires est renvoyé, pour traitement par une plate-forme reliée au RCB (Réseau de Carte Bancaire).

Le fait d'avoir à consulter en ligne l'offre du marchant impose une connexion préalable qui dans certains cas nécessite un terminal autre que le téléphone mobile (GSM), ce qui est un facteur limitant en termes de marchands concernés par ce procédé.

De plus, cette procédure d'achat apparaît fort complexe à l'utilisateur.

On a également proposé, dans le WO 01/41419, un procédé d'achat par téléphone mobile dans lequel on saisit des données d'identification d'article sur le clavier de téléphone, puis on les transmet à un serveur d'achat. S'en suit alors une procédure d'échanges entre ce serveur d'achat et un porte-monnaie électronique associé au téléphone mobile dans une étape préalable à l'achat.

Au cours de cette procédure, le serveur d'achat interroge entre autres l'utilisateur sur le mode de paiement souhaité, et également demande une confirmation d'achat à ce dernier.

Ce procédé est, lui aussi, d'utilisation lourde, aussi bien pour l'acheteur que pour les services techniques qui le mettent en place.

Le but de l'invention est un procédé d'achat par téléphone mobile, qui soit de mise en place et de mise en œuvre plus simples que les procédés d'achat existants.

Ce but est atteint selon l'invention grâce à un procédé de contrôle d'un processus d'achat par un équipement électronique de communication mobile, comprenant une étape d'identification d'au moins un produit ou d'au moins un service, étape mettant en œuvre une transmission à un serveur d'achat de données d'identification du produit ou du service par un message émis par l'équipement mobile, caractérisé en ce que le procédé met en œuvre une étape de transmission de données de paiement permettant une transaction, et en ce que le procédé inclut la mise en œuvre d'un protocole imposant la simultanéité des transmissions des données d'identification de produit ou de service avec la transmission des données de paiement, dans un même message.

On propose également selon l'invention un ensemble de communication mobile comprenant au moins un équipement mobile de communication et un serveur d'achat en communication avec l'équipement mobile, caractérisé en ce que le serveur d'achat est programmé pour effectuer une transaction financière et initier une livraison de produit ou de service en réponse à un seul message émis par l'équipement mobile et contenant à la fois une désignation de produit ou de service et à la fois des données de paiement suffisantes à la transaction.

On propose également selon l'invention un équipement de communication mobile comprenant des moyens d'envoi de messages, caractérisé en ce qu'il inclut une application de production de message pour l'achat à distance d'un produit ou d'un service, cette application générant des données suffisantes à un paiement et produisant un même message dans lequel elle introduit ces données de paiement produites par elle ainsi que des données de désignation de produit ou de service saisies par l'utilisateur.

Dans une variante privilégiée, il s'agit de fournir un équipement mobile incluant une application prévue pour inscrire les données de paiement dans le message, sur commande de l'utilisateur.

D'autres caractéristiques, buts et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles :

- la figure 1 est un organigramme représentant les étapes d'un procédé selon une variante de l'invention ;

- la figure 2 et un schéma simplifié illustrant des échanges d'informations entre différentes unités participant à une mise en œuvre de l'invention.

L'exemple de procédé décrit maintenant en référence à la figure 1 s'organise autour des étapes suivantes :

Le client consulte d'abord (étape A) un catalogue des offres (catalogue au sens générique du terme). Ce catalogue peut être un CD- ROM, un catalogue papier, un serveur Internet, une chaîne de télévision spécialisée, voire même une facture à payer.

Sur ce catalogue sont présentées une partie des informations nécessaires à l'élaboration de la transaction bancaire sur le périphérique mobile accédant au réseau GSM (Global System for Mobile Communication), GPRS (General Packet Radio Service) ou UMTS (Universal Mobile Télécommunications system). Typiquement, on trouve sur ce catalogue l'identité du marchand et de sa banque, l'identification du bien et le montant à payer. Aux étapes B et C explicitées par la suite, le client désireux d'acheter active sur son périphérique mobile une fonctionnalité achat.

Il rentre alors dans un menu dans lequel on lui demande de saisir ces trois informations (identité du marchand et de sa banque, identification du bien, et montant) et de s'authentifier vis à vis du moyen de paiement, par exemple à l'aide d'un code confidentiel de paiement.

Une application programmée dans l'équipement mobile (ou bien le combiné ou bien la carte SIM dans le cas d'un téléphone mobile) fournit alors, en réponse à cette authentification, des données de paiement nécessaires à la transaction.

Cette application élabore ensuite un mini message « Transaction » puis l'envoie (Etape D) à un serveur de paiement via message asynchrone, ici simplement via message SMS. L'application qui génère les données de paiement, bancaires ou non, peut revêtir différentes formes. Les données de paiement peuvent être des données non bancaires car elles peuvent désigner un autre type de compte, par exemple un compte pré-approvisionné d'un quelconque réseau commercial. Dans une première variante, le téléphone est équipé d'une carte d'authentification réseau (carte SIM dans son appellation actuelle), qui présente également une fonction d'identification en tant qu'utilisateur d'un compte de paiement de produits.

En d'autres termes, la carte que l'utilisateur introduit dans son portable lors de l'acquisition de ce dernier, est une carte qui le déclare en tant qu'utilisateur du réseau, et qui l'identifie en tant que porteur de compte, bancaire ou non.

Tout module qui combine à la fois la fonction d'identification de l'utilisateur sur le réseau et la fonction de mémorisation ou de calcul des données nécessaires au paiement est également adapté.

Le téléphone portable, ou de préférence sa carte SIM, est programmé(e) pour inscrire automatiquement dans le message les données bancaires nécessaires à la transaction. Les manipulations de l'utilisateur en sont donc fortement allégées. Dans une première variante, le téléphone inclut simplement une mémoire dans laquelle sont enregistrées des coordonnées de paiement, telles que désignation d'un compte bancaire ou de tout autre compte à débiter. L'activation de la fonction de commande provoque la fourniture automatique de ces coordonnées et leur inscription dans le message, sans nécessité de consultation particulière par l'utilisateur.

Dans une seconde variante, le téléphone ou sa carte SIM incluent des moyens de commande d'un calculateur du téléphone qui élabore les certificats nécessaires à une authentification certaine de l'acheteur, puis les inscrit dans le message.

Dans une troisième variante, le téléphone est équipé d'un lecteur pour cartes bancaires classiques. L'utilisateur insère préalablement la carte dans le téléphone, saisit son code de carte bancaire, et le téléphone calcule des certificats qui authentifient la carte et son utilisateur. Ces certificats sont ensuite inscrits par le téléphone dans le mini-message, avec les désignations de produit.

Le téléphone comporte préférentiellement alors un lecteur de carte ISO ou AFNOR en tant que lecteur de carte bancaire (carte à puce ou carte à micro-circuit). Un tel lecteur peut aussi être un lecteur de type lecteur déporté, c'est-à-dire par exemple un lecteur additionnel qui peut être raccordé au téléphone mobile, physiquement ou par liaison sans contact, par exemple par liaison de proximité radio, bluetooth par exemple.

Après transmission du mini message au serveur d'achat, ce serveur appelle alors des centres d'autorisation pour la transaction, puis notifie le marchand en ce qui concerne la transaction.

A la réception de l'acquittement du marchand, le serveur de paiement acquitte par mini-message (SMS) le client sur la transaction et sur la prestation du marchand. En cas d'impossibilité de prestation par le marchand, le client est également notifié mais la transaction n'est pas placée en remise. Il est à noter que la notification du client sur l'opération de transaction peut être découplée de la notification du marchand.

Les coordonnées physiques du client sont ici conservées sur le serveur de paiement.

Par le fait que le client saisit lui-même les données identifiant le produit et son vendeur, un tel système étend de façon considérable les capacités de commerce électronique utilisant le terminal GSM comme terminal de paiement. Pour l'illustrer, quelques exemples sont présentés par la suite.

Si le client consulte un catalogue du marchand sur CD-ROM, il détermine de façon très libre le choix du bien qu'il désire acheter (à tout moment sans contrainte extérieure comme les temps de téléchargement, le coût des télécommunications, etc.).

Sur catalogue papier, la démarche est la même que précédemment.

On peut noter que la majorité du chiffre d'affaires des vépécistes passe par ce canal. Sur Internet, la consultation du catalogue du marchand se fait en ligne. Ce type de consultation est tout à fait possible mais n'est pas exclusif dans le système.

La télévision est également un média permettant de réaliser facilement un achat de ce type. La consultation d'une chaîne de TV Achat laisse au client l'opportunité de procéder à un achat ultérieur à tout moment.

La chaîne n'a en effet qu'à indiquer les éléments nécessaires à l'achat lors de la présentation des biens (par exemple l'identité du marchand, l'identification du bien et le prix du bien).

Dans le cas des télévisions à péage (péage à la séance par exemple), en indiquant sur la page de présentation des émissions les éléments nécessaires à l'achat d'une émission (l'identité du marchand, l'identification de l'émission et le prix de l'émission), il est possible de construire un système Pay per View (payé pour voir) fondé sur l'utilisation du GSM selon le présent procédé. Le paiement des factures est également une application importante du commerce électronique, et notamment du présent procédé, quelque soit le système retenu, le client dispose toujours d'une facture papier (obligation légale). On utilise cette facture comme support des éléments nécessaires au paiement de celle-ci (l'identité du marchand, l'identification de la facture et le montant de la facture).

A titre d'exemple supplémentaire, lors de la projection de cassettes vidéo, il y a souvent avant le film certaines publicités qui présentent de nouvelles sorties. On prévoit d'accompagner ces publicités par les éléments suffisants à l'achat d'une nouvelle cassette par le présent procédé (l'identité du marchand, l'identification de la nouvelle cassette et le prix de la cassette).

De même, il est prévu de présenter les informations nécessaires à l'achat d'un bien dans la presse, par exemple dans des publicités de la presse.

On va maintenant détailler la série d'étapes mises en œuvre dans le présent exemple selon l'invention, telles qu'illustrées à la figure 1.

A l'étape A, le client consulte un catalogue papier et il se révèle intéressé par deux achats sur ce catalogue.

Il appelle le menu ACHAT de son téléphone GSM.

A l'étape B, il saisit les références du premier article (ou premier service) à 25,20 €.

A l'étape C, il saisit les références du second article, à 12,20 €. L'application programmée dans l'équipement mobile additionne alors les montants des différents articles.

En d'autres termes, le client constitue, hors connexion (off-line), un panier de commande.

Il est ici possible de ne saisir qu'un code représentant les données marchand, alors qu'on pourra saisir plusieurs codes représentant plusieurs articles, et constituer ainsi un « mini-panier électronique ».

A l'étape D, l'utilisateur saisit son code confidentiel nécessaire au paiement.

Dans la variante à carte SIM (Suscriber Identity Module) multifonctions (par exemple une carte EMV pour Eurocard Marstercard Visa, qui combine toutes les fonctions typiques d'une carte SIM et toutes les fonctions d'une carte bancaire), l'utilisateur saisit le code nécessaire à la génération des données de paiement, par exemple sous forme de certificats, par cette carte. Dans la variante à coordonnées de compte pré-enregistrées, la mémoire concernée fournit les coordonnées en réponse au code.

Dans la variante à lecteur de carte bancaire, le code en question est le code d'utilisation de la carte et une application de la carte SIM calcule les ceux certificats typiquement nécessaires à une transaction, puis les inscrit sur le message d'achat.

Puis l'utilisateur confirme son achat.

Le téléphone transmet alors un message de type SMS (ou plus généralement un message asynchrone) au serveur d'achat, dans lequel message se trouvent à la fois les coordonnées définissant l'article et ici le vendeur, ainsi que les coordonnées de paiement, bancaires par exemple, de l'acheteur.

Les informations saisies par le client et les données de paiement, qui constituent ce message, sont suffisantes pour déclencher une opération de paiement.

Il s'agit, par un unique message, d'une commande de paiement qui a été élaborée off-line, c'est à dire hors de connexion à un quelconque serveur au moment de la saisie, et sans liaison à deux directions simultanées lors d'une telle saisie.

L'initialisation de l'acte d'achat est donc, dans cet exemple, toute particulière par le fait qu'elle inclut l'ensemble des données pour la transaction dans un seul et même message.

Illustrée ici en référence à l'utilisation d'un téléphone, l'invention peut être mise en œuvre à l'aide de tout équipement électronique de communication mobile, ou terminal de communication mobile.

On entendra, par équipement électronique de communication mobile ou terminal mobile, tout équipement incluant des moyens d'échange de signaux, notamment hertziens, notamment un assistant personnel digital (PDA) du type incluant une carte SIM ou incluant une autre carte de même nature.

Sur la figure 2, on a représenté schématiquement les interactions entre le téléphone mobile 10, une deuxième entité 20 dite le « commerçant » (disposant d'un instrument de communication ou d'une entité délégataire) et une troisième entité 30, dite « plateforme ». La plateforme 30 est apte à stocker des données et à communiquer d'une part avec un équipement supportant les messages asynchrones et d'autre part une institution financière 40 ou un réseau bancaire. Le procédé décrit ici comprend les échanges suivants entre les équipements des trois entités 10, 20 et 30 :

Tout d'abord, le client 10 saisit des données définissant une offre de prestation. Ensuite l'équipement mobile (téléphone) génère le message à partir de ces données d'identification de produits ou services et à partir de coordonnées nécessaires au paiement, que cet équipement inscrit préférentiellement lui-même dans le message. Il s'agit de l'envoi par l'équipement, de l'ensemble de ces données à la plate forme 30, sous la forme d'un message 100 sur la figure 2.

Cette seconde étape est préférentiellement réalisée dans la carte SIM, qui réalise l'authentification client par code et génère en réponse les données nécessaires au client.

Ensuite l'équipement mobile adresse ce message à une plateforme ou passerelle 30, formant serveur d'achat, incluant donc les données d'identification produit et les données nécessaires au paiement (certificat(s) dans le cas d'une carte bancaire).

Les données de l'offre de prestation mentionnées ci-dessus présentent ici, de manière préférentielle, la forme d'un ou plusieurs codes, indiquant entre autres les données marchand, bancaires, d'articles ou service, le prix unitaire.

Ensuite, la passerelle 30 (serveur d'achat) analyse ces données, les met en relation, si besoin, avec d'autres informations issues du serveur du commerçant 20. Il s'agit de la flèche 200 de communication (facultative) avec le marchand 20 et de passage des données commerçantes. Par cette communication 200 de la demande de produit, le serveur d'achat 30 s'assure que le produit est disponible chez le commerçant. Dans certains cas, comme par exemple dans le cas de biens immatériels (musique, images), un telle interrogation n'est pas obligatoire car le bien est toujours disponible.

Dans le cas ou la réponse 300 du serveur du commerçant est négative, le produit est indisponible et les étapes suivantes, détaillées ci- après, sont annulées. Il se produit également, à ce stade du processus d'achat, une vérification générale des données, et un passage de données supplémentaires si besoin.

Puis la passerelle 30 communique à l'institution financière 40 ou au réseau bancaire les informations nécessaires à l'accomplissement de la transaction (flèche 400 sur la figure 2).

Ensuite, la passerelle 30, après retour de l'opération accomplie par l'institution financière 40 ou le réseau bancaire, renvoie à l'équipement mobile 10, si besoin après interrogation du serveur du marchand 20, un message indiquant les informations issues de l'accomplissement de la transaction, qu'elle ait été acceptée ou non, ou les informations liées à sa non réalisation par la plate-forme 30. Il s'agit de la flèche 500 représentant la communication au marchand 20 des données issues de l'accomplissement de la transaction. Alors une réponse du serveur du marchand 20 indiquant des informations complémentaires sur le produit (disponibilité, désignation, etc.) est émise (flèche 600).

Enfin, une information de l'équipement mobile 10 sur l'accomplissement de l'opération a lieu (flèche 700). Sur la figure 2, les traits continus représentent des envois particulièrement souhaitables, les traits pointillés représentent des communications facultatives (qui entraînent la non-existence des envois 400, 500 et 600), et le trait à bandes interrompues (flèche 600) est une communication également facultative. Selon une variante préférentielle, un code représentant les données marchand est saisi par le client, et plusieurs codes simplifiés représentant les données articles ou services peuvent donc être saisis, et envoyés après traitement et éventuelle segmentation à la plate-forme.

Le code pourra être communiqué au terminal à distance par différents moyens comme des périphériques du terminal tels les scanners, outils de reconnaissance vocale ou manuscrite, etc. Le procédé décrit ici, outre ses avantages en termes d'aisance d'utilisation et de mise en place, présente en outre l'avantage de réduire les risques de répudiation d'une demande d'achat.

On notera que dans le présent procédé, la plate-forme 30 effectue une vérification de l'heure communiquée par le client 10. Cette heure tient compte des éventuels décalages horaires, et de l'asynchronisme des messages échangés.

La plate-forme 30 effectue également une vérification des données, articles, commerçant et bancaires, ainsi que des données client.

Claims

REVENDICATIONS

1. Procédé de contrôle d'un processus d'achat par un équipement électronique de communication mobile (10), comprenant une étape d'identification d'au moins un produit ou d'au moins un service, étape mettant en œuvre une transmission à un serveur d'achat (30) de données d'identification du produit ou du service par un message émis par l'équipement mobile (10), caractérisé en ce que le procédé met en œuvre une étape de transmission de données de paiement permettant une transaction, et en ce que le procédé inclut la mise en œuvre d'un protocole imposant la simultanéité des transmissions des données d'identification de produit ou de service avec la transmission des données de paiement, dans un même message.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend l'étape consistant à mettre en œuvre une inscription automatique des données de paiement dans le message.

3. Procédé selon la revendication 2, caractérisé en ce que l'étape d'inscription automatique des données de paiement inclut la saisie d'un mot de passe et est conditionnée par l'équipement mobile à la saisie d'un tel mot de passe.

4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le message d'identification du produit ou du service inclut des données d'identification d'au moins un deuxième article acheté par la même transaction (C).

5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il inclut l'envoi d'un message du serveur d'achat (30) à l'équipement mobile de l'acheteur (10), qui confirme ou signale l'échec de la transaction.

6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données identifiant le produit ou le service se présentent sous la forme d'un ou plusieurs codes qui identifie notamment le marchand, les coordonnées bancaires de celui-ci, une référence du produit ou du service vendu, et le montant de ce produit ou service.

7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'équipement mobile (10) est un téléphone mobile (10).

8. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que l'équipement mobile (10) est un assistant électronique personnel (PDA).

9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le message incluant les données d'identification du produit ou du service ainsi que les données bancaires de l'acheteur est un message asynchrone, c'est à dire un message élaboré (A, B, C) en dehors de toute connexion entre l'équipement mobile et le serveur d'achat.

10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il inclut l'utilisation d'une plateforme (30) stockant des données et communiquant avec un serveur d'institution financière (40), et en ce que les échanges suivants sont réalisés :

- l'équipement mobile (10) adresse à la plateforme (30) à la fois des données définissant un produit ou un service et à la fois des données de paiement ;

- la plateforme (30) communique avec le serveur d'institution financière (40) pour accomplissement de la transaction.

11. Procédé selon la revendication précédente, caractérisé en ce que la plateforme (30), après accomplissement ou refus de la transaction, indique à l'équipement mobile (10) l'état de cette transaction.

12. Procédé selon la revendication précédente, caractérisé en ce que la plateforme (30) interroge le marchand (20) sur la bonne désignation et/ou la disponibilité du produit, puis communique des données de transaction au serveur d'institution financière (40), puis indique à l'équipement mobile (10) si la transaction est accomplie ou non.

13. Ensemble de communication mobile comprenant au moins un équipement mobile de communication (10) et un serveur d'achat (30) en communication avec l'équipement mobile (10), caractérisé en ce que le serveur d'achat (30) est programmé pour effectuer une transaction financière et initier une livraison de produit ou de service en réponse à un seul message émis par l'équipement mobile (10) et contenant à la fois une désignation de produit ou de service et à la fois des données de paiement suffisantes à la transaction.

14. Ensemble selon la revendication précédente, caractérisé en ce que l'équipement mobile (10) comporte une carte du type introduite dans le mobile à l'acquisition du mobile par l'utilisateur et servant à l'authentification sur réseau de l'utilisateur, la carte étant de plus prévue pour l'identification d'un compte financier et l'authentification de l'utilisateur de ce compte financier.

15. Ensemble selon la revendication précédente, caractérisé en ce que la carte servant à l'authentification de l'utilisateur à la fois sur réseau et pour le paiement inclut en outre une application fournissant des données de paiement et introduisant ces données de paiement dans un message à envoyer, en réponse à une commande correspondante de l'utilisateur.

16. Ensemble selon la revendication 13, caractérisé en ce que l'équipement mobile (10) inclut un lecteur de carte bancaire et une application pour lire cette carte et inscrire dans le message des données de paiement suffisantes au paiement par carte bancaire.

17. Equipement de communication mobile (10) comprenant des moyens d'envoi de messages, caractérisé en ce qu'il inclut une application de production de message pour l'achat à distance d'un produit ou d'un service, cette application générant des données suffisantes à un paiement et produisant un même message dans lequel elle introduit ces données de paiement produites par elle ainsi que des données de désignation de produit ou de service saisies par l'utilisateur.