WO2000063859A1 - Systeme de paiment pour l'utilisation de logiciels - Google Patents

Systeme de paiment pour l'utilisation de logiciels Download PDF

Info

Publication number
WO2000063859A1
WO2000063859A1 PCT/FR2000/001023 FR0001023W WO0063859A1 WO 2000063859 A1 WO2000063859 A1 WO 2000063859A1 FR 0001023 W FR0001023 W FR 0001023W WO 0063859 A1 WO0063859 A1 WO 0063859A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
message
software
card
user
Prior art date
Application number
PCT/FR2000/001023
Other languages
English (en)
Inventor
Jean-Claude Pailles
Philippe Michon
Stéphane Petit
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to CA002370990A priority Critical patent/CA2370990A1/fr
Priority to AU39740/00A priority patent/AU3974000A/en
Priority to DE60008091T priority patent/DE60008091T2/de
Priority to EP00918975A priority patent/EP1171854B1/fr
Priority to JP2000612904A priority patent/JP2002542546A/ja
Publication of WO2000063859A1 publication Critical patent/WO2000063859A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/16—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for devices exhibiting advertisements, announcements, pictures or the like

Definitions

  • the subject of the present invention is a payment system for the use of software.
  • This software can be of any kind and for example be software recorded on a medium such as CD-ROM (Compact Disc-Read Only Memory) or DVD-ROM (Digital Versatile Disc-Read Only Memory) or downloaded software.
  • the current mode of software distribution is mainly CD-ROM, and will soon be DVD-ROM.
  • CD-ROM Code Division Multiple Access
  • DVD-ROM DVD-ROM
  • the problem of fraudulent copying of this software is becoming more and more acute. If, for a while, the format of the CD-ROM prevented copying onto a blank medium, at present, recordable discs and CD burners have become accessible to the general public. The same phenomenon will undoubtedly soon appear in the case of DVD technology.
  • a payment system for the use of software must be able to fulfill at least three functions: • to control the use of the software, each time the software is launched, or periodically, or else when a particular event occurs in the software (for example a change of "world” in a game, a passage to the second act of a play or film ...); then, the software must request that a payment be made;
  • CD-ROMs can be foreign: a software payment system must therefore have a cross-border dimension, therefore mechanisms likely to be deployed internationally, and international recognition in standardization committees;
  • the system of the invention comprises a payment module and means for processing messages and for payment.
  • the software whose use is to be controlled includes a software interface.
  • the functions of these means are as follows: • the software interface is able to constitute a first message which is an offer message for using the software, this first message containing, in particular, the identity of the software publisher, the parameters of the offer, the digital signature by the publisher of at least part of the offer, this first message being addressed to the payment module;
  • the payment module is able to receive this first message, to display it, to receive in return the possible acceptance by the user of the software, and, in the event of acceptance, to constitute a second payment request message containing in particular the identity of the user and that of the publisher, as well as proof that the user accepts the offer, this module being able to send this second message to the processing means;
  • the message processing and payment means are capable of receiving the second message, of checking the proof that it contains, of recording the payment request with at least the identity of the user and the identity of the software publisher, the amount to be paid, and to credit the publisher of said amount, these means being further capable of constituting a third message, which is an acknowledgment message, this third message comprising, in particular, the identity of the means processing and a digital signature of the offer, this third message being addressed to the payment module; • the payment module is further capable of retransmitting this third message to the software interface;
  • the software interface is also able to verify the signature of the processing means in relation to the parameters of the offer contained in the first message and, in the event of a match, to authorize the use of the software.
  • the message processing and payment means are constituted by a remote payment server connected to the payment module by a telecommunications network, this server receiving and processing the second message, constituting and sending the third message.
  • This payment server aggregates the elementary credits in order to periodically pay the publishers the amount due to them.
  • the message processing and payment means comprise secure means containing at least the identity of the user, these means being further able to receive the second message, to check the proof that it contains, to record the payment request and constitute the third acknowledgment message, and further comprise a remote payment server able to credit the publisher.
  • the secure means can comprise a smart card reader with a smart card containing the identity of the user, the card being able to receive the second message, check the proof it contains, record the payment request and prepare the third acknowledgment message.
  • the card can be of the prepaid type (in the form of, for example, an electronic purse) or postpaid.
  • the card is capable of constituting a file of the requests paid and the corresponding amounts, the acknowledgment message only being sent with its signature once the update of this file performed.
  • the present invention also relates to a payment module for a payment system for the use of software, characterized in that it comprises:
  • Means for receiving an acceptance from said user of the software • means to constitute a second payment request message containing in particular the identity of the user and that of the publisher as well as proof that the user accepts the offer,
  • a further subject of the present invention is message processing and payment means for a payment system for the use of software, characterized in that they comprise:
  • • means capable of receiving a payment request message from a payment module, containing in particular the identity of a user and that of a publisher, as well as proof that the user accepts the offer to use 'software made to it,
  • Figure 1 illustrates a system according to
  • FIG. 2 illustrates a certification tree with a chain of certificates
  • FIG. 3 illustrates a system according to the invention in its second variant.
  • a personal computer PC supposed to contain software L, which we want to control the use.
  • This software is associated with an IL software interface, hereinafter called “DEALER”, which communicates with the payment system itself.
  • DEALER IL software interface
  • W a payment module W
  • WALLET Remotely there is a payment server SP, connected to the WALLET module by a transmission line (not shown) ...
  • the software editor is referenced E.
  • an offer message referenced 1 is sent by the MERCHANT interface to the WALLET module.
  • This offer message may contain: • the identity of the publisher; • the description of the offer, a text understandable by the user explaining what he will obtain for payment (for example: "30 additional minutes of use” or "scene 3: duration 25 minutes”);
  • the WALLET module receiving this message will ask user U if he agrees to accept this offer. For example, a window is displayed on the screen, displaying the description of the offer, the time and date, the amount and the monetary unit to be paid, and this same price converted into French Francs. This display is symbolized by the arrow la in FIG. 1. If the user U agrees, he clicks for example on a box "agreement” (response symbolized by the arrow lb in FIG. 1). The WALLET module then sends message 2 "payment request" to the server SP. This message may contain: “a summary of the offer ⁇ the price, the date and the time, the hazard, the signature S E (offer h , price);
  • the identity of user U, and that of publisher E • proof that the customer agrees to purchase this offer.
  • the nature of the proof can depend on the embodiment: it can be a password sent to the SP payment server, or a confidential code given to a smart card, which itself provides the SP server with cryptographic proof: signature , etc.
  • the payment server SP receiving this payment request 2 then performs the following operations: • checking the proof given by the client,
  • the SP server verifies that the total amount of what has been consumed since the start of the period is less than the authorization amount allocated to this user (in the case of post-payment), or that this total is lower than the provision made by the user for this use (in the case of pre-payment), • recording of the payment request, in order to be able to carry out the payment operations later; this record includes at least: -identification of the user, -identification of the software publisher, -the price, -the time and date, the digest offers h ,
  • the WALLET module simply transmits the message received to the MARCHAND interface.
  • the DEALER interface verifies the signature
  • S SP (offer, price, randomness, date-time) of the acknowledgment message, compared to the parameters of the offer previously sent. If there is a match, then the execution of the L software can continue.
  • the SP server Periodically, every month for example, calculates the cumulative expenses incurred by each user, and it causes, in the case of a post-payment, the actual payment of the sums due by means of a card for which the prior knowledge of the customer's card number is required, or by direct debit from the customer's account.
  • the accumulation by the publisher makes it possible to calculate the amount due to each publisher.
  • the dotted lines in the drawing in FIG. 1 correspond to this financial flow from the server SP to the editor.
  • An authority A defines the "root" of the certification tree, in which the different actors of the system are located:
  • the E can send a message to the server SP containing the summary offer h , the price, the date and the time, the hazard, the signature S E (offer h , price), certificate of E by SYND, certificate of SYND by A.
  • the server SP which knows the public key of A, verifies the certificate of SYND by A, with the public key of A. It therefore obtains the public key of SYND, in a secure manner and verifies the certificate of E by SYND with the key public of SYND. It then obtains the public key of E, in a secure manner, and can finally control the signature S E.
  • the variant which has just been described can be described as "online” because the user must connect, for example via the INTERNET network, to the server SP at each payment request.
  • This version is only acceptable for infrequent payments (for example to be able to receive a DVD-ROM movie that lasts 2 hours).
  • the invention provides another variant, which is more suitable for repeat payments.
  • This variant is described in FIG. 3. It assumes the existence of an LC card reader and a C card. As the card constitutes a secure medium, it replaces the server SP with regard to messages 2 and 3 , which then circulate between the W module and the LC card reader. This variant can be called "off line" as opposed to the first.
  • the payment of the editor E is always made by the payment server SP, which periodically receives the information stored in the card (line PP).
  • line PP As regards card C, we can distinguish two cases:
  • the card is a prepaid card (of the electronic purse card type, for example); the financial provision decreases each time a payment request message is processed; then, there is no risk of non-payment, because the card before emptying, had to be loaded; it is however necessary to note the uses which were made, to be able to pay the editors, according to the use of their software; this can for example be done when reloading the card;
  • the card is a post-paid card: the risk exists that the uses recorded in the card will never come back to the intermediary, therefore that the customer will never be debited, and consequently that the editors of the software used will not be not credited.
  • the solution to this problem is to limit payments to a certain ceiling and / or to charge a deposit higher than this ceiling, which dissuades the user from having his card disappear.
  • this second variant remains very close to the first, except for the replacement of the server SP by the card C.
  • This card must therefore contain a file of uses which, as in the case of the server SP, will contain the transaction records, themselves containing at least the following information: - user identification,
  • the card can be replaced by a means of storage integrated into the PC.
  • fragmentation / dissemination techniques must be used on the entire disk, the complexity of which will constitute a barrier, certainly less strong than the physical security of smart cards. , but sufficient in many cases.

Abstract

Système de paiement pour l'utilisation d'un logiciel. Le système comprend une interface logicielle (IL), un module de paiement (W), un serveur de paiement (SP) en liaison avec l'éditeur du logiciel (E). L'offre d'utilisation fait l'objet d'un message (2), d'une demande de paiement (2), d'un acquittement (3, 4). Application au contrôle de l'utilisation des logiciels.

Description

SYSTEME DE PAIEMENT POUR L'UTILISATION DE LOGICIELS
DESCRIPTION
Domaine technique La présente invention a pour objet un système de paiement pour 1 ' utilisation de logiciels . Ces logiciels peuvent être de nature quelconque et par exemple être des logiciels enregistrés sur un support comme les CD-ROM (Compact Disc-Read Only Memory) ou les DVD-ROM (Digital Versatile Disc-Read Only Memory) ou les logiciels téléchargés.
Ils peuvent concerner aussi bien des calculs scientifiques que des jeux, des techniques assistées par ordinateur, du traitement de texte, etc..
Etat de la technique antérieure
Le mode actuel de diffusion des logiciels est principalement le CD-ROM, et sera très bientôt le DVD-ROM. Pour les éditeurs de logiciel se pose de façon de plus en plus aiguë le problème de la copie frauduleuse de ces logiciels. Si, pendant un temps, le format du CD-ROM a empêché la recopie sur un support vierge, actuellement, les disques inscriptibles et les graveurs de CD sont devenus accessibles au niveau du grand public. Le même phénomène ne tardera sans doute pas à advenir dans le cas de la technologie DVD.
Un autre mode possible de diffusion des logiciels, quoique moins usité pour des raisons de performances, est le téléchargement. Il n'est pas approprié aux jeux ayant besoin de très nombreuses images, ou scènes en trois dimensions. En revanche, il peut se justifier dans d'autres cas. De nombreux logiciels (compilateurs, éditeurs...) entrent dans cette catégorie. Ces logiciels sont en général gratuits, car, du fait de leur volume faible qui les rend téléchargeables, ils seraient très faciles à copier d'un ordinateur à un autre.
Par ailleurs, il est clair que le prix d'achat élevé d'un logiciel est souvent dissuasif pour les utilisateurs. Le coût du support CD-ROM et de sa gravure intervient pour très peu dans ce prix. Le prix d'achat élevé des CD/DVD-ROM actuels correspond avant tout à la rémunération de 1 ' éditeur et des distributeurs des jeux.
Ces observations donnent a penser qu'il existe un besoin pour le paiement à l'acte, ou à la durée ou à la séance de logiciels sur support CD/DVD-ROM, ou des logiciels téléchargés. Ainsi, les éditeurs se rémunéreront sur une base de clients beaucoup plus importante, en fonction de l'utilisation que le client fait de ce logiciel. Globalement, un tel procédé devrait plutôt développer le chiffre d'affaires de la profession. De plus, la copie de support ne présentera plus d'intérêt, puisque de toute façon, il sera nécessaire de payer pour l'utilisation de ce logiciel. Or, il n'y a pas, à l'heure actuelle de moyens fiables et sûrs pour assurer un paiement pour l'utilisation de logiciels. La présente invention a justement pour but de remédier à cette carence. Exposé de 1 ' invention
Un système de paiement pour l'utilisation de logiciel doit pouvoir remplir au moins trois fonctions : • contrôler l'utilisation du logiciel, chaque fois que le logiciel est lancé, ou bien périodiquement, ou bien lorsqu'un événement particulier se produit dans le logiciel (par exemple un changement de "monde" dans un jeu, un passage au deuxième acte d'une pièce de théâtre ou de film...) ; alors, le logiciel doit demander qu'un paiement soit effectué ;
• enregistrer les utilisations, pour faire payer l'utilisateur : si l'utilisateur accepte la demande de paiement, il faut enregistrer cette demande d'une façon sécurisée, pour pouvoir le faire payer ultérieurement ; la sécurisation doit interdire à l'utilisateur d'effacer ses dettes, et le paiement différé doit permettre d'agréger des petits montants, pour pouvoir présenter à l'utilisateur une note globale, périodiquement (une fois par mois, par exemple), pour des raisons pratiques mais aussi du fait des coûts de recouvrement de ces petits montants ;
• reverser périodiquement à 1 ' éditeur du logiciel le montant dû.
Ces fonctions doivent être remplies compte tenu de certaines contraintes :
• les CD-ROM peuvent être étrangers : un système de paiement de logiciel doit donc comporter une dimension trans-frontière, donc des mécanismes susceptibles d'être déployés internationalement, et une reconnaissance internationale dans des comités de standardisation ;
• 1 ' interface entre logiciel et les moyens de paiement doit être standardisée de façon à ce qu'un développeur de logiciel n ' ait pas à programmer lui-même la logique de paiement correspondant à 1 ' emploi de ce logiciel ;
• le système qui enregistre les utilisations doit être capable de déclencher des paiements internationaux pour rémunérer les éditeurs de logiciels dans n ' importe quel pays du monde ;
• 1 ' agrégation pour les paiements des utilisateurs et les reversements aux éditeurs de logiciels doit être possible : comme indiqué plus haut, ceci correspond à un objectif de simplicité, mais aussi à un souci de réduction des coûts bancaires ; notamment, dans le cas de transactions vers l'étranger, il serait inefficace (voire néfaste), sur le plan des coûts, de faire trop d'opérations de virements de petits montants .
La présente invention répond à toutes ces exigences en tenant compte de toutes ces contraintes. A cette fin, le système de l'invention comprend un module de paiement et des moyens de traitement de messages et de paiement. Par ailleurs, le logiciel dont on veut contrôler l'utilisation comprend une interface logicielle. Les fonctions de ces moyens sont les suivantes : • 1 ' interface logicielle est apte à constituer un premier message qui est un message d'offre d'utilisation du logiciel, ce premier message contenant, notamment, l'identité de l'éditeur du logiciel, les paramètres de l'offre, la signature numérique par- 1 ' éditeur d' au moins une partie de l'offre, ce premier message étant adressé au module de paiement ;
• le module de paiement est apte à recevoir ce premier message, à l'afficher, à recevoir en retour l'acceptation éventuelle de l'utilisateur du logiciel, et, en cas d'acceptation, à constituer un deuxième message de demande de paiement contenant notamment l'identité de l'utilisateur et celle de l'éditeur, ainsi qu'une preuve que l'utilisateur accepte l'offre, ce module étant apte à adresser ce deuxième message aux moyens de traitement ;
• les moyens de traitement de messages et de paiement sont aptes à recevoir le deuxième message, à contrôler la preuve qu'il contient, à enregistrer la demande de paiement avec au moins 1 ' identité de l'utilisateur et l'identité de l'éditeur du logiciel, le montant à payer, et à créditer l'éditeur dudit montant, ces moyens étant aptes en outre à constituer un troisième message, qui est un message d'acquittement, ce troisième message comprenant, notamment, l'identité des moyens de traitement et une signature numérique de l'offre, ce troisième message étant adressé au module de paiement ; • le module de paiement est en outre apte à retransmettre ce troisième message à l'interface logicielle ;
• l'interface logicielle est en outre apte à vérifier la signature des moyens de traitement par rapport aux paramètres de 1 ' offre contenue dans le premier message et, en cas de concordance, à autoriser l'utilisation du logiciel.
Dans une première variante, les moyens de traitement de messages et de paiement sont constitués par un serveur de paiement distant relié au module de paiement par un réseau de télécommunications, ce serveur recevant et traitant le deuxième message, constituant et émettant le troisième message. Ce serveur de paiement agrège les crédits élémentaires pour, périodiquement, reverser aux éditeurs le montant qui leur est dû.
Dans une seconde variante les moyens de traitement de messages et de paiement comprennent des moyens sécurisés contenant au moins l'identité de l'utilisateur, ces moyens étant de plus aptes à recevoir le deuxième message, à contrôler la preuve qu'il contient, à enregistrer la demande de paiement et à constituer le troisième message d'acquittement, et comprennent en outre un serveur de paiement distant apte à créditer l'éditeur.
Dans cette variante, les moyens sécurisés peuvent comprendre un lecteur de carte à puce avec une carte à puce contenant l'identité de l'utilisateur, la carte étant apte à recevoir le deuxième message, à contrôler la preuve qu'il contient, à enregistrer la demande de paiement et à constituer le troisième message d'acquittement.
Régulièrement, l'ensemble des demandes enregistrées dans la carte, qui correspondent à des usages de logiciels, sont rapatriées dans le serveur grâce à un réseau de télécommunications.
La carte peut être du type pré-payée (sous forme par exemple de porte monnaie électronique) ou post-payée.
Pour une carte pré-payée comme pour une carte post-payée, la carte est apte à constituer un fichier des demandes acquittées et des montants correspondants, le message d'acquittement n'étant émis avec sa signature qu'une fois la mise à jour de ce fichier effectuée.
La présente invention a également pour objet, un module de paiement pour système de paiement pour l'utilisation de logiciel, caractérisé en ce qu'il comprend :
• des moyens pour traiter un premier message contenant, notamment, l'identité d'un éditeur de logiciel, des paramètres d'une offre d'utilisation, une signature numérique d'au moins une partie de cette offre,
• des moyens pour émettre ce message vers un utilisateur,
• des moyens pour recevoir une acceptation dudit utilisateur du logiciel, • des moyens pour constituer un deuxième message de demande de paiement contenant notamment l'identité de l'utilisateur et celle de l'éditeur ainsi qu'une preuve que l'utilisateur accepte l'offre,
• des moyens pour recevoir et traiter un troisième message comprenant une signature numérique constituant une preuve de paiement.
La présente invention a encore pour objet des moyens de traitement de messages et de paiement pour système de paiement pour l'utilisation de logiciel, caractérisés en ce qu ' ils comprennent :
• des moyens aptes à recevoir d'un module de paiement un message de demande de paiement contenant notamment l'identité d'un utilisateur et celle d'un éditeur ainsi qu'une preuve que l'utilisateur accepte l'offre d'utilisation d'un logiciel qui lui a été faite,
• des moyens aptes à contrôler cette preuve, • des moyens aptes à enregistrer la demande de paiement avec au moins 1 ' identité de l'utilisateur et l'identité de l'éditeur du logiciel, le montant à payer et des moyens aptes à créditer l'éditeur dudit montant, • des moyens aptes en outre à constituer un message d'acquittement, ce message comprenant, notamment, l'identité des moyens de traitement, et une signature numérique qui constitue la preuve du paiement, , • des moyens pour adresser ce message un module de paiement.
Brève description des figures - la figure 1 illustre un système conforme à
1 ' invention dans sa première variante ;
- la figure 2 illustre un arbre de certification avec une chaîne de certificats ;
- la figure 3 illustre un système conforme à l'invention dans sa seconde variante.
Description détaillée de modes particuliers de réalisation
On voit, sur la figure 1, un ordinateur personnel PC supposé contenir un logiciel L, dont on veut contrôler l'utilisation. Ce logiciel est associé à une interface logicielle IL, appelée par la suite "MARCHAND", qui communique avec le système de paiement proprement dit. On trouve également un module de paiement W, appelé par la suite "WALLET". A distance se trouve un serveur de paiement SP, relié au module WALLET par une ligne de transmission (non représentée)... L'éditeur du logiciel est référencé E.
Dans la variante illustrée sur la figure 1, lorsque le logiciel L a décidé de demander un nouveau paiement, un message d'offre référencé 1 est émis par l'interface MARCHAND à destination du module WALLET. Ce message d'offre peut contenir : • 1 ' identité de 1 ' éditeur ; • la description de l'offre, texte compréhensible par l'utilisateur explicitant ce qu'il va obtenir moyennant paiement (par exemple : "30 minutes supplémentaires d'utilisation" ou bien "scène 3 : durée 25 minutes") ;
• le prix (montant, unité monétaire, etc.)
• l'heure et la date interne du PC ;
• un aléa interne ;
• une signature par l'éditeur du logiciel de cette offre, sous la forme SE (offreh, prix) où offreh signifie "condensé des données de l'offre".
Le module WALLET recevant ce message va demander à l'utilisateur U s'il est d'accord pour accepter cette offre. Par exemple, une fenêtre est affichée à l'écran, visualisant la description de l'offre, l'heure et la date, le montant et l'unité monétaire à payer, et ce même prix converti en Francs français. Cet affichage est symbolisé par la flèche la sur la figure 1. Si l'utilisateur U est d'accord, il clique par exemple sur une case " accord " (réponse symbolisée par la flèche lb sur la figure 1 ) . Le module WALLET émet alors le message 2 "demande de paiement" à destination du serveur SP. Ce message peut contenir : « un condensé de l'offre^ le prix, la date et l'heure, l'aléa, la signature SE(offreh, prix) ;
• l'identité de l'utilisateur U, et celle de l'éditeur E ; • une preuve que le client est d'accord pour acheter cette offre. La nature de la preuve peut dépendre du mode de réalisation : ce peut être un mot de passe envoyé au serveur de paiement SP, ou un code confidentiel donné à une carte à puce, qui elle-même fournit au serveur SP une preuve cryptographique : signature, etc..
Le fait de transmettre un condensé de 1 ' offre ("offreh") et non l'offre complète permet au client de ne pas révéler au serveur SP ce qu'il sélectionne, sans empêcher les contrôles par le serveur SP.
Le serveur de paiement SP recevant cette demande de paiement 2 effectue alors les opérations suivantes : • contrôle de la preuve donnée par le client,
• conversion en Francs français, si nécessaire,
• contrôle de la consommation de l'utilisateur ; à titre d'exemple, le serveur SP vérifie que le cumul de ce qui a été consommé depuis le début de la période est inférieur au montant d'autorisation attribué à cet utilisateur (cas du post-paiement), ou bien que ce cumul est inférieur à la provision constituée par l'utilisateur à cet usage (cas du pré-paiement) , • enregistrement de la demande de paiement, pour pouvoir réaliser ultérieurement les opérations de paiement ; cet enregistrement comporte au moins : -l'identification de l'utilisateur, -l'identification de 1 ''éditeur du logiciel, -le prix, -l'heure et date, le condensé offreh ,
• constitution du message 3 d'acquittement, qui va prouver au iogiciel et à son interface "MARCHAND" que le paiement a bien été réalisé ; ce message d'acquittement, pour établir une preuve vérifiable, contiendra :
-l'identité du serveur SP,
-la signature SSP (offreh, prix, aléa, date- heure) par le serveur de paiement, Le module WALLET transmet simplement le message reçu à l'interface MARCHAND.
L'interface MARCHAND vérifie la signature
SSP (offre , prix, aléa, date-heure) du message d'acquittement, par rapport aux paramètres de l'offre précédemment envoyée. S'il y a concordance, alors l'exécution du logiciel L peut continuer.
Périodiquement, tous les mois par exemple, le serveur SP calcule le cumul des dépenses engagées par chaque utilisateur, et il provoque, dans le cas d'un post-paiement, le paiement effectif des sommes dues au moyen d'une carte pour lequel la connaissance préalable du numéro de carte du client est nécessaire, ou par prélèvement automatique sur le compte du client.
Pour le pré-paiement, ceci se fait par le rechargement volontaire par l'utilisateur de sa provision chez un intermédiaire.
De même, le cumul par l'éditeur permet de calculer le montant dû à chaque éditeur. Les traits pointillés du dessin de la figure 1 correspondent à ce flux financier du serveur SP vers l'éditeur.
Pour l'établissement des différentes signatures mentionnées ci-dessus, on peut utiliser un système à clé publique avec arbre de certification. Cette solution est en effet l'une des rares qui permettent de concevoir des systèmes simples, sûrs, ouverts et internationalement reconnus.
Les principes de cette technique sont bien connus. La mise en œuvre est schématisée sur la figure 2. Une autorité A définit la "racine" de l'arbre de certification, dans lequel se trouvent les différents acteurs du système :
- les éditeurs de logiciels utilisant ce moyen de paiement,
- les serveurs SP,
- les entités intermédiaires ; dans l'exemple de la figure 2, il pourrait s'agir d'un syndicat d'éditeurs de logiciels d'un pays
(SYND), et d'une autorité nationale de régulation des serveurs INTERNET (SINT).
Ainsi, lorsqu'un logiciel de tel éditeur de logiciel est utilisé par un utilisateur correspondant à tel serveur SP, un ou des certificats joints aux messages 1 et 3 permettent de vérifier les signatures.
Pour le message d'offre (message 1) l'éditeur
E peut adresser au serveur SP un message contenant le condensé offreh, le prix, la date et l'heure, l'aléa, la signature SE(offreh, prix), le certificat de E par SYND, le certificat de SYND par A.
Le serveur SP, qui connaît la clé publique de A, vérifie le certificat de SYND par A, avec la clé publique de A. Il obtient donc la clé publique de SYND, de façon sûre et vérifie le certificat de E par SYND avec la clé publique de SYND. Il obtient alors la clé publique de E, de façon sûre, et peut finalement contrôler la signature SE.
La variante qui vient d'être décrite peut être qualifiée de "en ligne" ("on line") car l'utilisateur doit se connecter, par exemple par le réseau INTERNET, au serveur SP à chaque demande de paiement. Cette version n'est acceptable que pour des paiements peu fréquents (par exemple pour pouvoir recevoir un film sur DVD-ROM qui dure 2 heures ) .
L'invention prévoit une autre variante, qui est mieux appropriée aux paiements répétés. Cette variante est décrite sur la figure 3. Elle suppose l'existence d'un lecteur de carte LC et d'une carte C. Comme la carte constitue un support sûr, elle remplace le serveur SP en ce qui concerne les messages 2 et 3, lesquels circulent alors entre le module W et le lecteur de carte LC. Cette variante peut être qualifiée de "off line" (hors connexion) par opposition à la première. Le paiement de l'éditeur E s'effectue toujours par le serveur de paiement SP, lequel reçoit périodiquement les informations mémorisées dans la carte (ligne PP). S' agissant de la carte C, on peut distinguer deux cas :
• la carte est une carte pré-payée (du type carte porte-monnaie électronique, par exemple) ; la provision financière diminue à chaque fois qu ' un message de demande de paiement est traité ; alors, il n'y a pas de risque d'impayés, car la carte avant de se vider, a du être chargée ; il faut cependant relever les utilisations qui ont été faites, pour pouvoir payer les éditeurs, selon l'utilisation de leurs logiciels ; ceci peut par exemple être fait au moment du rechargement de la carte ;
• la carte est une carte post-payée : le risque existe que les utilisations enregistrées dans la carte ne reviennent jamais à l'intermédiaire, donc que le client ne soit jamais débité, et par voie de conséquence que les éditeurs des logiciels utilisés ne soient pas crédités. La parade à ce problème consiste à limiter les paiements à un certain plafond et/ou à faire payer une caution supérieure à ce plafond, qui dissuade l'utilisateur de faire disparaître sa carte.
Du point de vue des mécanismes précis, cette seconde variante reste très proche de la première, si ce n'est le remplacement du serveur SP par la carte C. Cette carte devra donc contenir un fichier des utilisations qui, comme dans le cas du serveur SP, contiendra les enregistrements des transactions, eux mêmes contenant au minimum les informations suivantes : - l'identification de l'utilisateur,
- l'identification de l'éditeur du logiciel,
- le prix.
Si 1 ' on accepte de sacrifier un peu de sécurité pour ne pas avoir le surcoût du lecteur de carte, la carte pourra être remplacée par un moyen de mémorisation intégré au PC.
Pour que le fichier des demandes de paiement ne soit pas trop facilement altérable ou effaçable, il faut utiliser des techniques de fragmentation/ dissémination sur la totalité du disque, dont la complexité constituera une barrière, certes moins forte que la sécurité physique des cartes à puce, mais suffisante dans bien des cas.

Claims

REVENDICATIONS
1. Système de paiement pour l'utilisation d'un logiciel (L) contenu sur un support, ce logiciel contenant une interface (IL), le système comprenant un module de paiement (W) et des moyens de traitement de messages et de paiement (SP), les fonctions de ces moyens étant les suivantes : l'interface logicielle (IL) est apte à constituer un premier message (1) qui est un message d'offre d'utilisation du logiciel, ce premier message
(1) contenant, notamment, l'identité de l'éditeur du logiciel (E), des paramètres de l'offre, la signature numérique par 1 ' éditeur d ' au moins une partie de l'offre, ce premier message étant adressé au module de paiement (W) ; le module de paiement (W) est apte à recevoir ce premier message (1), à l'afficher (la), à recevoir en retour l'acceptation éventuelle (lb) de l'utilisateur (U) du logiciel, et en cas d'acceptation, à constituer un deuxième message (2) de demande de paiement contenant notamment 1 ' identité de l'utilisateur (U) et celle de l'éditeur (E) ainsi qu'une preuve que l'utilisateur (U) accepte l'offre, ce module (W) étant apte à adresser ce deuxième message
(2) aux moyens de traitement de messages et de paiement (SP) ; les moyens de traitement de messages et de paiement (SP) sont aptes à recevoir le deuxième message (2), à contrôler la preuve qu'il contient, à enregistrer la demande de paiement avec au moins l'identité de l'utilisateur (U) et l'identité de l'éditeur du logiciel (E), le montant à payer et à créditer l'éditeur (E) dudit montant, ces moyens étant aptes en outre à constituer un troisième message (3), qui est un message d'acquittement, ce troisième message (3) comprenant, notamment, l'identité des moyens de traitement et une signature numérique qui constitue la preuve du paiement, ce troisième message étant adressé au module de paiement (W) ; le module de paiement (W) est en outre apte à retransmettre ce troisième message (3) à l'interface logicielle (IL) ; l'interface logicielle (IL) est en outre apte à vérifier la signature des moyens de traitement par rapport aux paramètres de l'offre contenue dans le premier message et, en cas de concordance, à autoriser l'utilisation du logiciel (L).
2. Système selon la revendication 1, dans lequel la signature numérique par l'éditeur d'au moins une partie de l'offre et la signature numérique constituant la preuve du paiement, sont des signatures à clé publique avec arbre de certification, une autorité (A) définissant une racine de l'arbre de certification dans lequel se trouvent les différents acteurs du système, notamment les éditeurs de logiciels
(E) et les serveurs de paiement (SP), un ou des certificats étant joint(s) au premier et au troisième messages (1) (3) pour la vérification des signatures.
3. Système selon la revendication 1, dans lequel les moyens de traitement de messages et de paiement sont constitués par un serveur de paiement distant (SP) relié au module de paiement (W) par un réseau de télécommunications, ce serveur (SP) recevant et traitant le deuxième message (2) et constituant et émettant le troisième message (3), ce serveur de paiement calculant le cumul des dépenses engagées par chaque utilisateur pour tous les éditeurs pour faire payer cet utilisateur, et provoquant le reversement des sommes dues à chaque éditeur par tous les utilisateurs.
4. Système selon la revendication 1 , dans lequel les moyens de traitement de messages et de paiement comprennent des moyens sécurisés (LC, C) contenant au moins l'identité de l'utilisateur (U), ces moyens étant aptes à recevoir le deuxième message (2), à contrôler la preuve qu'il contient, à enregistrer la demande de paiement et à constituer le troisième message d'acquittement (3) avec la preuve de paiement, et comprennent en outre un serveur de paiement distant (SP) apte à créditer l'éditeur (E).
5. Système selon la revendication 4, dans lequel les moyens sécurisés comprennent un lecteur de carte (LC) avec une carte (C) contenant l'identité de l'utilisateur, le lecteur de carte et la carte étant aptes à recevoir le deuxième message (2), à contrôler la preuve qu'il contient, à enregistrer la demande de paiement et à constituer le troisième message d'acquittement (3) avec la preuve de paiement.
6. Système selon la revendication 5, dans lequel la carte (C) est du type pré-payée et contient une provision, la carte étant apte à débiter cette provision à chaque demande de paiement du montant de la demande.
7. Système selon la revendication 6, dans lequel la carte pré-payée (C) formant le message d'acquittement est apte à insérer, dans ce message, une preuve que le montant de la demande dû a été débité dans la carte.
8. Système selon la revendication 6, dans lequel la carte pré-payée (C) est apte à constituer un fichier des demandes acquittées et des montants correspondants, le message d'acquittement n'étant émis avec sa signature qu'une fois la mise à jour de ce fichier effectuée.
9. Système selon la revendication 8, dans lequel la carte pré-payée (C) peut être rechargée, le fichier qu'elle contient étant transféré préalablement au serveur de paiement (SP) lors du rechargement pour reversement aux éditeurs.
10. Système selon la revendication 6, dans lequel la carte pré-payée (C) est du type porte-monnaie électronique.
11. Système selon la revendication 5, dans lequel la carte (C) est du type post-payée.
12. Système selon la revendication 11, dans lequel la carte post-payée (C) est apte à constituer un fichier des demandes acquittées et des montants correspondants, le message d'acquittement n'étant émis avec sa signature qu'une fois la mise à jour de ce fichier effectué.
13. Système selon la revendication 12, dans lequel le fichier de la carte est transféré au serveur de paiement (SP) pour reversement aux éditeurs.
14. Module de paiement (W) pour système de paiement pour l'utilisation de logiciel, caractérisé en ce qu ' il comprend :
• des moyens pour traiter un premier message (1) contenant, notamment, l'identité d'un éditeur de logiciel (E), des paramètres d'une offre d'utilisation, une signature numérique d'au moins une partie de cette offre,
• des moyens pour émettre ce message (la) vers un utilisateur (U), • des moyens pour recevoir une acceptation (lb) dudit utilisateur (U) du logiciel,
• des moyens pour constituer un deuxième message (2 ) de demande de paiement contenant notamment l'identité de l'utilisateur (U) et celle de l'éditeur (E) ainsi qu'une preuve que l'utilisateur (U) accepte l'offre,
• des moyens pour recevoir et traiter un troisième message (3) comprenant une signature numérique constituant une preuve de paiement.
15. Moyens de traitement de messages et de paiement (SP) pour système de paiement pour l'utilisation de logiciel, caractérisés en ce qu'ils comprennent :
• des moyens aptes à recevoir d'un module de paiement (W) un message de demande de paiement contenant notamment l'identité d'un utilisateur (U) et celle d'un éditeur (E) ainsi qu'une preuve que l'utilisateur (U) accepte l'offre d'utilisation d'un logiciel qui lui a été faite,
• des moyens aptes à contrôler cette preuve,
• des moyens aptes à enregistrer la demande de paiement avec au moins l'identité de l'utilisateur et l'identité de l'éditeur (E) du logiciel, le montant à payer et des moyens aptes à créditer l'éditeur (E) dudit montant,
• des moyens aptes en outre à constituer un message (3) d'acquittement, ce message (3) comprenant, notamment, l'identité des moyens de traitement, et une signature numérique qui constitue la preuve du paiement,
• des moyens pour adresέer ce message (3) à un module de paiement (W) .
16. Moyens de traitement de messages et de paiement (SP) pour système de paiement pour l'utilisation de logiciel, caractérisés en ce qu'ils comprennent des moyens sécurisés comprenant un lecteur de carte (LC) avec une carte (C) contenant l'identité d'un utilisateur de logiciel, le lecteur de carte et la carte étant aptes à recevoir un message contenant une preuve que 1 ' utilisateur a accepté une offre et à contrôler cette preuve, à enregistrer une demande de paiement et à constituer un message d'acquittement (3) avec la preuve de paiement.
17. Moyens de traitement de messages et de paiement (SP) selon la revendication 16, dans lesquels la carte (C) est du type pré-payée et contient une provision, la carte étant apte à débiter cette provision à chaque demande de paiement du montant de la demande.
18. Moyens de traitement de messages et de paiement (SP) selon la revendication 17, dans lesquels la carte pré-payée (C) formant le message d'acquittement est apte à insérer, dans ce message, une preuve que le montant de la demande dû a été débité dans la carte.
19. Moyens de traitement de messages et de paiement (SP) selon la revendication 17, dans lesquels la carte pré-payée (C) est apte à constituer un fichier des demandes acquittées et des montants correspondants, le message d'acquittement n'étant émis qu'une fois la mise à jour de ce fichier effectuée.
20. Moyens de traitement de messages et de paiement (SP) selon la revendication 17, dans lesquels la carte pré-payée (C) peut être rechargée, le fichier qu'elle contient pouvant être transféré lors du rechargement.
21. Moyens de traitement de messages et de paiement (SP) selon la revendication 17, dans lesquels la carte pré-payée (C) est du type porte-monnaie électronique.
22. Moyens de traitement de messages et de paiement (SP) selon la revendication 16, dans lesquels la carte (C) est du type post-payée.
PCT/FR2000/001023 1999-04-20 2000-04-19 Systeme de paiment pour l'utilisation de logiciels WO2000063859A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CA002370990A CA2370990A1 (fr) 1999-04-20 2000-04-19 Systeme de paiment pour l'utilisation de logiciels
AU39740/00A AU3974000A (en) 1999-04-20 2000-04-19 Payment system for software use
DE60008091T DE60008091T2 (de) 1999-04-20 2000-04-19 Zahlungssystem für softwaregebrauch
EP00918975A EP1171854B1 (fr) 1999-04-20 2000-04-19 Systeme de paiement pour l'utilisation de logiciels
JP2000612904A JP2002542546A (ja) 1999-04-20 2000-04-19 ソフトウェアプログラムの使用に対する支払システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR99/04963 1999-04-20
FR9904963A FR2792750B1 (fr) 1999-04-20 1999-04-20 Systeme de paiement pour l'utilisation de logiciels

Publications (1)

Publication Number Publication Date
WO2000063859A1 true WO2000063859A1 (fr) 2000-10-26

Family

ID=9544631

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/001023 WO2000063859A1 (fr) 1999-04-20 2000-04-19 Systeme de paiment pour l'utilisation de logiciels

Country Status (7)

Country Link
EP (1) EP1171854B1 (fr)
JP (1) JP2002542546A (fr)
AU (1) AU3974000A (fr)
CA (1) CA2370990A1 (fr)
DE (1) DE60008091T2 (fr)
FR (1) FR2792750B1 (fr)
WO (1) WO2000063859A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4881264A (en) * 1987-07-30 1989-11-14 Merkle Ralph C Digital signature system and method based on a conventional encryption function
WO1995034857A1 (fr) * 1994-06-14 1995-12-21 Smith James P Appareil et procede de surveillance de l'enregistrement, de la licence payee et de l'utilisation comptee de produits logiciels
EP0809221A2 (fr) * 1996-05-23 1997-11-26 Sun Microsystems, Inc. Système et méthode virtuels de vente pour la gestion de la distribution, des licences et de la location de données électroniques
US5769269A (en) * 1994-04-28 1998-06-23 Peters; Steven A. Vending system
JPH10312277A (ja) * 1997-05-13 1998-11-24 Nakamichi Corp ソフトウェア配給方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0695302B2 (ja) * 1983-10-05 1994-11-24 亮一 森 ソフトウェア管理方式
JP3327435B2 (ja) * 1994-12-01 2002-09-24 日本電信電話株式会社 ディジタル情報保護システム及びその方法
JPH10269291A (ja) * 1997-03-26 1998-10-09 Sony Corp ディジタルコンテンツ配付管理システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4881264A (en) * 1987-07-30 1989-11-14 Merkle Ralph C Digital signature system and method based on a conventional encryption function
US5769269A (en) * 1994-04-28 1998-06-23 Peters; Steven A. Vending system
WO1995034857A1 (fr) * 1994-06-14 1995-12-21 Smith James P Appareil et procede de surveillance de l'enregistrement, de la licence payee et de l'utilisation comptee de produits logiciels
EP0809221A2 (fr) * 1996-05-23 1997-11-26 Sun Microsystems, Inc. Système et méthode virtuels de vente pour la gestion de la distribution, des licences et de la location de données électroniques
JPH10312277A (ja) * 1997-05-13 1998-11-24 Nakamichi Corp ソフトウェア配給方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 1999, no. 02 26 February 1999 (1999-02-26) *

Also Published As

Publication number Publication date
EP1171854A1 (fr) 2002-01-16
CA2370990A1 (fr) 2000-10-26
FR2792750B1 (fr) 2004-02-20
FR2792750A1 (fr) 2000-10-27
DE60008091T2 (de) 2004-12-09
JP2002542546A (ja) 2002-12-10
AU3974000A (en) 2000-11-02
EP1171854B1 (fr) 2004-02-04
DE60008091D1 (de) 2004-03-11

Similar Documents

Publication Publication Date Title
EP0865010B1 (fr) Systéme de paiement électronique sécurisé et procédé de mise en oeuvre
US20010034705A1 (en) Payment-based systems for internet music
EP1050025A2 (fr) Procede de transmission d'information et serveur le mettant en oeuvre
EP3195224A1 (fr) Procédés et dispositifs de gestion de transactions composites
EP1171854B1 (fr) Systeme de paiement pour l'utilisation de logiciels
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
FR2863088A1 (fr) Systeme de chargement d'au moins un porte-monnaie electronique
EP1428183A2 (fr) Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d'un utilisateur, une requete aupres d'une entite
EP1983480A1 (fr) Terminal de paiement, procédé et programme associés
FR2816422A1 (fr) Procede pour le paiement de transactions effectuees par exemple sur internet
EP2800072A2 (fr) Procédé de délivrance par un automate de cartes de téléphonie mobile SIM à abonnement prépayé ou postpayé
FR2864663A1 (fr) Echange securise de donnees, notamment de donnees certifiees pour l'affacturage
EP1965342A1 (fr) Procédé pour effectuer une transaction entre un module de paiement et un module de sécurité
EP1452028B1 (fr) Procede de gestion de fourniture d'acces a un contenu crypte destine a etre diffuse sur un reseau, ainsi que systeme et serveur pour la mise en oeuvre de ce procede
WO2023099238A1 (fr) Procédé de réalisation d'une transaction, dispositifs et programmes correspondants.
FR3128344A1 (fr) Méthode pour la mise à disposition immédiate d’un jeton non fongible à partir d’un fichier numérique d’un terminal mobile connecté à un service de chaine de blocs
FR2750275A1 (fr) Procede de gestion dans un systeme telematique distribue et systeme de mise en oeuvre de ce procede
FR2826755A1 (fr) Procede de transaction en ligne
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
WO2003098433A2 (fr) Systemes et procedes pour commander selectivement et comptabiliser l'utilisation effective de logiciels
FR3074946A1 (fr) Methodes et systemes de transaction electronique
FR2804229A1 (fr) Procede d'identification et de paiement
FR2816085A1 (fr) Procede et dispositif pour procurer un produit en permettant de faire evoluer ledit produit
FR2808636A1 (fr) Procede de paiement securise sur le reseau internet et dispositif pour sa mise en oeuvre
FR2828040A1 (fr) Procede de paiement en toute confiance

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA CN IN JP RU US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2000918975

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2370990

Country of ref document: CA

Ref country code: CA

Ref document number: 2370990

Kind code of ref document: A

Format of ref document f/p: F

Ref country code: JP

Ref document number: 2000 612904

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 200108709

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 09926360

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2000918975

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 2000918975

Country of ref document: EP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)