Language selection

Search

Patent 2217739 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent Application: (11) CA 2217739
(54) English Title: ELECTRONIC PAYMENT METHOD FOR PURCHASE-RELATED TRANSACTIONS OVER A COMPUTER NETWORK
(54) French Title: PROCEDE DE PAIEMENT ELECTRONIQUE PERMETTANT D'EFFECTUER DES TRANSACTIONS LIEES A L'ACHAT DE BIENS SUR UN RESEAU INFORMATIQUE
Status: Dead
Bibliographic Data
(51) International Patent Classification (IPC):
  • G07F 7/00 (2006.01)
  • H04L 9/32 (2006.01)
  • G06Q 20/00 (2006.01)
(72) Inventors :
  • PAYS, PAUL-ANDRE (France)
  • DAHAN, GERARD BEN (France)
(73) Owners :
  • G C TECH (France)
(71) Applicants :
  • G C TECH (France)
(74) Agent: MCCARTHY TETRAULT LLP
(74) Associate agent:
(45) Issued:
(86) PCT Filing Date: 1996-04-03
(87) Open to Public Inspection: 1996-10-17
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): Yes
(86) PCT Filing Number: PCT/FR1996/000500
(87) International Publication Number: WO1996/032701
(85) National Entry: 1997-10-08

(30) Application Priority Data:
Application No. Country/Territory Date
95/04533 France 1995-04-14

Abstracts

English Abstract




A method using an open communication network (10) to which retailer server
stations (20) and customer stations (30) are connected. According to the
method, a retailer server station generates a payment slip for the planned
purchase transaction between the retailer and a customer, which slip comprises
data on the retailer, the customer, the purchased item or service and the
price; the payment slip is transmitted over the network to a payment server
station (40); the payment server automatically checks whether the payment of
said price is authorised for the customer in question, by querying the
client's personal account set up in the payment server for paying small
amounts, or, in the case of larger amounts, by making a query over a banking
network (50) separate from the computer network (10); if the payment is
authorised, the payment server generates a cash voucher comprising at least
some of the data on the payment slip; and the cash voucher is transmitted to
the retailer to enable the purchase to go ahead.


French Abstract

Le procédé utilise un réseau de communication ouvert (10) sur lequel sont connectés des postes serveurs de marchands (20) et des postes clients (30) et comprend: l'élaboration par un poste serveur de marchand d'un ticket de paiement, concernant un achat envisagé entre le marchand et un client, et comportant des informations relatives au marchand, au client, à l'objet de l'achat et à son prix; la transmission du ticket de paiement via le réseau à un poste serveur de paiement (40); la vérification automatique par le serveur de paiement si le paiement du prix est autorisé pour le client concerné, soit par interrogation d'un compte client propre au client, tenu par le serveur de paiement, et destiné au paiement des petits montants, soit par interrogation sur un réseau bancaire (50) indépendant du réseau informatique (10), pour les paiements de montants plus élevés; si la vérification est positive, l'élaboration par le serveur de paiement d'un bon de caisse comportant au moins une partie des informations du ticket de paiement; et la transmission du bon de caisse au serveur de marchand afin d'autoriser la réalisation de l'achat.

Claims

Note: Claims are shown in the official language in which they were submitted.






CLAIMS

1. A method for effecting electronic payments for transactions relating to the
purchase of goods offered by suppliers to customers via a public computer
network, to which are connected supplier servers and customer stations,
characterised by the steps of:
(a) development, by a supplier server connected to the network, of a
transaction authorisation request, or payment ticket, concerning a purchase
envisaged between the supplier and a customer, and comprising information
relating to the supplier, the customer, the purchase object and the price,
(b) transmission of the payment ticket via the computer network to a
payment server which is distinct from the customer station and supplier server,
(c) automatic verification by the payment server if the payment of the price
is authorised for the customer, the verification being effected, according to the
level of the price to be paid, either by interrogation of a customer account of the
customer, held by the payment server and intended for payment of small sums, or
by interrogation of a banking network, independent of the computer network, for
payment of higher sums,
(d) if the verification is positive, development by the payment server of a
transaction authorisation or voucher including at least a part of the payment ticket
information, and
(e) transmission of the voucher to the supplier server via the computer
network, so as to authorise the conclusion of the purchase.

2. A method as claimed in claim 1, characterised in that when a voucher is
transmitted after verification by interrogation of a customer account held by the
payment server, the amount of the purchase is debited from the customer account
and credited to the supplier account of the concerned supplier and held by the
payment server.

3. A method as claimed in claim 1 or 2, characterised in that the verification
by the payment server comprises a preliminary customer authentication phase.

4. A method as claimed in claim 3, characterised in that the authentication is
achieved by recognition of an access key transmitted by the computer network
from the customer station to the payment server.





11

5. A method as claimed in any one of claims 1 to 4, characterised in that it
comprises the development by the payment server of a voucher comprising at leasta part of the information of the payment ticket and certification information.

6. A method as claimed in any one of claims 1 to 5, characterised in that it
comprises memorisation by the payment server of the authorised transactions, by
stocking at least a part of the contents of the voucher.

7. A method as claimed in any one of claims 1 to 6, characterised in that thepayment ticket is transmitted from the payment server to the supplier server by the
intermediary of the customer station.

8. A method as claimed in any one of claims 1 to 7 characterised in that the
voucher is transmitted from the payment server to the supplier server by the
intermediary of the customer station.

9. Electronic payment system for effecting transactions relating to the
purchase of goods offered by suppliers to customers via a public computer
network, the system comprising customer stations and supplier servers,
characterised in that the system further comprises at least one payment
server distinct from the customer stations and the supplier servers and comprising:
-a front unit having means for connecting to the public network,
-a rear unit having means for connecting to a banking network independent
of the public network,
-means for communicating between the front and rear units,
-means for memorising customer accounts and supplier accounts, and
-processing means for verifying, in response to the reception by the front
unit of a transaction authorisation request or a payment ticket, concerning a
purchase envisaged between the supplier and a customer, if the payment of the
price is authorised for the customer by interrogating the customer account or the
banking network, and, if the verification is positive, developing a transaction
authorisation, or voucher in order to transmit the verification to the open network
via the front unit.

12

10. Payment system as claimed in claim 9, characterised in that the payment
server comprises means for memorising authorised transactions.

Description

Note: Descriptions are shown in the official language in which they were submitted.


j CA 02217739 1997-10-08




ELECTRONIC PAYMENT MET~OD FOR PnR~A~F.-RFT.ATFn TRAN~ACTIONS OVER A
COMPUTER N~l~UKK

The present invention concerns an electronic payment method enabling
5 transactions to be carried out relating to the purchase of "goods" offered by
suppliers by means of on-line services via a public co~ ulei telec~.l....l...ir~tinn
nGlwulh to which are ~ttache(l suppliers' seners and clients' stations. Here, "public
colll~lllel teleco.l....l..)ir~tion nGlwolhl' is intenflP~ to mean a network to which
persons or co...p~.-ies can freely connect themselves so long as they have an
lû address, for example the "Tlll~ t". "Goods" is intPn-lP(l to mean products orservices, which are delivered outside the network after the transaction has beenconcluded, as well as non-m~tçri~l goods, such as information, which can be
delivered via the co~ ulGr network.
Various electronic payment methods have been proposed, and some are
15 already operational.
Several methods are based on a new form of currency. They involve an
electronic reprçsçnt~ti~>n~ sometimes called a "token", which can be purely
embodied in software or can be partly physical, for example a "smart card". T~hese
methods neces~il;.~e circulation of the ~;UllGllCy on the colllpulGr network, which
20 plcselll~ difficult security problems regarding the creation of false CU11G11~;Y.
Other known electronic payment methods ~ece~ le a direct relation with
a bank or a banking network. These are typified by methods used in the credit
card ll~,Lw~Jl~; such as well-hnown methods ~ltili7.ing point-of-sale tçnnin~l~
linked to a bank card circuit as well as methods employing electronic cheques
25 using an electronic signature to ~lthpnficate the purchaser. This is a form of
engagement letter issued by a purchaser, returned to the seller and accepted andrecognised by a bank.
There are certain inconveniences associated with methods which
n~c~s~ilalt;, at one time or another during a transaction, a relationship with a30 traditional banking system and the effecting of a transaction in such a system.
R~nkin~ system transactions have a real cost which becomes prohibitive when the
amount of the purchase is very low, for example, an amount based on a query to adata base. And computer nGLwolhs are well adapted to the sale of low-priced
goods, in particular informational goods, since the delivery can be carried out
35 through the network itself. Moreover, access to a banking network or a bank card
network must have high levels of security, which, in practical terms, excludes the


_

~ CA 02217739 1997-10-08

-


possibility of access through a public co~ ult;r llelwolh, sueh as the ~r..~ , to
which potential purchasers can connect themselves.
An object of the invention is to provide a method which avoids the
problems of the known methods - in particular, a method p~....;lli..g a simple and
5 reliable way of accomplishing transactions relating to the purchase of goods on a
CO~ e~ lwolh, without the need to circulate electronic cullcncy~ for goods of
high price req 1irinp~ ~llt~ riC~tion from a traditional banking system, as well as for
goods of low to very-low price.
The object is achieved by a method of the type defined at the begi..~ of
10 the present ~esc~iption and COlll~ lg, according to the invention, the steps of:
-creation, by the server of a supplier connected to the llt;lwulh, of a
tr~n~ction authorisation request or "payment ticket", conceming a pulcllase
envisaged between the supplier and a customer, and ~;o...~,. ;~;.1~ information
relating to the supplier, the customer, the purchased object and the price;
-~ c~ si~n of the payment ticket via the colllpuler network to a payment
server which is distinct from the customer station and the supplier server,
-automatic verifir~tion by the payment server of whether the payment of
the price is authorised for the customer involved, the v~rifir~tion being effected,
according to the level of the price to be paid, either by interrogation of an ~Ccol~nt
20 of the customer, held by the payment server and int~.n~led for payment of smaller
sums, or by interrogation on a banking network, inflepen-lent of the colllpul~
network, for payment of higher sums;
-if the verification is positive, creation by the payment server of a
transaction authorisation or voucher including at least part of the payment ticket
25 inforrn~tion; and
sion of the voucher to the supplier server via the colll~ult;
network, to authorise the conclusion of the purchase.
Thus, the procedure according to the invention is nott;~o,lhy in that it
nrc~csil~e~ neither the creation of electronic currency nor the circ~ tion of
30 electronic currency over the colllpul~l network.
The control of the transactions is effected by a payment server which alone
can access a banking network or a bank card nelwolk, and which m~n~ges non-
bank c~-.ctomer accounts from which small sum transactions can be effected.
The payment server also manages non-bank supplier accounts used for
35 small sum ~ cl ;ons. In this way, when a voucher is tr~ncmittecl after
verification by interrogation of a customer account held by the payment server, the

CA 02217739 1997-10-08




amount of the purchase is debited from the customer account and credited to the
account of the co~.r~ d supplier and held by the payment sener, a procedure
which does not produce high procescinp~ costs.
Each customer has available his own identity to enable use of the payment
5 method. He must also have available a real bank account, plGfGl~bly one which
can be operated by means of traditional bank cards. The verification by the
payment server can include a preliminary phase of validating the identity of thecustomer from the CO11lG11lS of the payment ticket. The identity validation precedes
access to the customer account (if the sum of the ~u~ ce is low) or access to the
10 bank network (if the amount involved in the yul~;llase is higher). The paylllclll
server preferably includes means, for example a data base, for storing the
relationship between the customer identities used for tr~nc~ctions on the Co~ ulGi
network and the bank identities (bank account or credit card numbers) used for
transactions on the bank ~lGlwu~h. In that way, the circulation of banking i~ientiti~c
15 on the Co...yulG. ~elwc ~h can be avoided.
An implementation of the invention will now be described, as a non-
limitin~ example, with reference to the accompd~ying drawings, in which:
-Figure 1 is a general sc-h~m~tic view of an electronic ydylllG..l system
accol~lh.g to the invention;
-Figure 2 is a lepl~s~ ion in the form of a block sr~ c ~ grAm of a
payment server of the system of Figure 1;
-Figure 3 illustrates the progression of operations relating to a purchase
using the system of Figure 1; and
Figures 4A to 4C are flow charts showing srhem~tically the operations
carried out by the payment server.
Figure 1 lGylGse~ sr-hrln~tically a co,,lyulel telec(l.-.. ication nGlwo-h
10 to which are connected supplier servers 20, customer stations 30 and at leastone payment server 40.
The COI11YUlG1 llelwolh 10 is an open or public network, for example the
30 network known as the "r..le~ t". The supplier servers 20 are units such as those
currently used for on-line services connrctecl to the rnt~rnet, for example, units
o,~ i.ce~l around UNIX-based multi-processor m~rhines. The customer st~ti~mc
30 are basically microcomp.lle.~ which are provided with means for connecting tothe Tnternrt network 10, for example, in the form of a "Web" interface. The
35 supplier servers 20 and the customer stations 30 may use, for example, known

CA 02217739 1997-10-08




software protocols commonly known ~ the "World Wide Web" ("WWW")
employing the HITP protocol.
The payment server 40, shown in more detail in Figure 2, comprises front
and rear units l~s~e.;lively 41 and 42 both connected to the Tnt--rnet 10. The front
5 unit 41 has an ar hitcçt--re similar to that of a standard server conn~cte~l to a
network such as the rntçrn~t The rear unit 42 in~ltlcles a proc~ssing unit 43
co~ .i"i"g one or more processors, a data base 44 cn,,~ information relatingto the suppliers and customers subscribing to the payment system, a tr~n~ction
register 45, an intc.rf~re unit 46 for connectin~ with a banhing ll~lw~Jlh or with a
10 bank card network 50, and a communication bus 47 or similar other link enabling
connection between the dirr~G~lL con~tituçnt parts of the unit. A secure connection
48 enables bi-directional communication between the front unit 41 and the
plocessi~g unit 43. Colll,,,unication with the network 10 is controlled by the front
unit 41 while m~n~gement of the data base 44 as well as the control of the
15 col~ tion with the banking ll~ilwulh are assured by the rear unit 42.
The data base 44 colll~i"s information relating to the customers and to the
suppliers who have subscribed to the payment system. For each customer, the database 44 CO~t~illS the system identity ("CId") ~ ign~rl when the customer initially
subscribes to the system, a customer account or electronic wallet ("PME") for
20 payment of small sums, a banking identity such ~ an account number of a real
account or a credit card number, possibly as well as the customer's own access
p~~wo,.l or "key". For each supplier, the data base 44 colll~ s the system identity
of the supplier/merchant ("MId"), which is a~.~igne(1 when the supplier initially
subscribes to the system, a supplier account, or electronic cash register (' l ~ ) for
25 receipt of small sums and a banking identity such as a bank account number.
Figure 3 shows schematically the dirrt;~t;lll stages of a transaction relating
to the purchase of goods by a subscribing customer from a subscribing supplier. It
can be a case of m~tçrizll goods, for which delivery to the customer will take place
after conclusion of the tr~n~action, or non-m~tçri~l goods (such ~ information)
30 which can be provided to the customer over the co",pult;r network as soon as
electronic payment has been effected.
(1) Consultation by the customer
After connl-cting to the Internet 10, a customer can consult the catalogue or
"window" of any supplier on-line by ~ccç~ing the supplier's server 20 and
35 viewing the supplier's wares on the screen of the customer station 30. On
pl~sç.~ tion of the customer's system identity CId, the supplier's server 20 can

CA 02217739 1997-10-08




present to the customer particular ~ l conditions (for example a discount)
applicable tQ the potential tr~n~ction.
(2) Purchase demand
Once the customer has chosen a commodity (object) O, his choice is
5 ~ to the supplier's server in the fomm of a message col.l;.i"il~ an identity
OId of the commodity and the identity CId of the customer. When nr~s~ry, for
example, for the eventual delivery of the commodity chosen, the supplier's server
can request supplementary i~r(J~ lion such as an address arld ~lGr~ ;id deliverytime. This may co~ .liently be done through use of an electronic fomm sent over
10 the network to be filled in by the customer.
When the purchase envisaged represents a large sum or is subjected to legal
conditions, a prelimin~ry ~l~thPntication of the customer may be desired. As will
be seen in detail in the following, the ~nthrntication of a customer is effected by
the payment server 40. Also, the ~uthelttication clem~n~l coming from a supplier is
15 advantageously issued in the fomm of a payment ticket of no value which is
h...~ l to the payment server over the colll~ l network via the ~;u~rlolllel
station and, in the case of ~osilive ~ttthl~ntication~ provokes the retum of a voucher
from the payment server to the supplier server, always by way of the customer
station. The procedure for the establisl.llle.l~ of a payment ticket and for the20 lr~lll ip of a voucher are described in greater detail in the following.
The pulcllase d~-nn tn~l issued by the customer can relate to a single
commodity or to several goods to be provided as a group "basket purchase".
(3) Development of the payment demand
In response to a pulcllase deTn tn-l, the supplier server develops a payment
dcnn~ntl~ which can include the following infommation:
-Identity of the supplier ("MId");
-Description of the commodity ordered, or, in the case of grouped
purchases, each of the goods in the basket;
-Type of tr~n~ction (single or basket);
-Identity of the customer ("CId");
-Identity of the commodity or collection of goods of the basket ("OId");
-Price of the commodity ("Oid");
-Value Added Tax, VAT, (if applicable),
-Date and time of the issue of the payment ticket (hour and date ~lall.pillg
by the supplier server);
-Period of validity of the payment ticket; and

CA 02217739 1997-10-08




-Serial number in the sales register of the supplier (particularly in the case
when the l.~ l;on has inrlllderl a preli...i~-,..y ~thl-ntication stage).
The combination of the above infonn~til-n is coded as a series of bytes
which are ~~ hled in the hidden ch~nnel of a payment ticket (or URL of an order
S of a commodity, URL being the initials of "Uniform Resource Locator" used in
WWW software with the HITP protocol), as follows:
URL http:<SP>cdesc . ;l,lion of the ordeD,
where SP is the ~..I~...~t address of the payment server. The payment ticket is
addressed to the customer station. It is completed by two logical "anchors" which
10 enable the customer either to cancel or to confirm.
(4) Sending the payment order
The payment order is ~ d to the payment server simply by
validation by the customer of the URL of the payment order. As will be
appre~ te~l, the payment ticket only passes in transit through the customer station.
(5) Issue of the voucher
Upon reception of a payment order, the payment server 40 ~lec~es the
payment order, ~uth~nticates the customer and invçstig;~tes whether the pdyllltllt
can be ~uthori~e~l before rGllll..i..g either a voucher or a payment refusal. The
c~lol~cl ~llth~ntir~ti~n and payment ~lth~ri~tion operations will be described in
greater detail with reference to Figure 4.
When the verification process does not permit authorisation of payment, an
explanatory refusal notification (referring, for example, to insufficient funds in the
account, to the passing of a limit authorised for the customer, etc.) is sent to the
customer by the payment server. When the veri~lcation does permit ~lthori~tion
of payment, the information cont~inecl in the payment ticket is completed with aseAal number in the llallsa~;lion register 45, a time stamp, a validity time limit
(typically some tens of seconds) and the seal of the payment server co~ l;--g
certification information. The combination of this information, possibly after
being digitally signed through use of a private key portion of a public key/private
key encly~lion system belonging to the payment server (which ensures the validity
and the integrity of the payment authorisation) is encoded in a series of bytes
which cn- -~ the hidden ch~nn~l of a voucher or delivery URL:
URL http:<M><description of the voucheD,
where M is the rntçrn~t address of the supplier.
(6) Delivery request

CA 02217739 1997-10-08




The voucher is ~ cl to the supplier server via the customer station.
This can be efl~ected auloll~tir~lly by the software installed in the r~-st-)mer station
using the re-routing possibility of the URL-s, well-known to those skilled in the art
to which the invention pertains. The supplier server decodes and verifies the
5 lGc~ivt;d voucher before ~llfhori~in~ delivery of the commodity. This veriffcation
includes using the private key of the payment server, v~liryhlg that the validity
time limit has not passed and co~p.~ the co..~r~ of the voucher w*h the
payllle.~l cleSn~n-l
(7) Delivery of the commodity
When the voucher has been validated by the supplier server, this server can
effect delivery directly to the customer station, in the case where the commodity
being purchased is inform~tion, or address to the customer station a document
permitting the collection of the commodity and, notably, specifying the place ofdelivery and the name of the recipient.
It will be noted that, in the case of a grouped or basket purchase, the
supplier server creates an object with allocation of a unique identity, a list of the
U~Ls of each of the goods contained in the basket. It is this object which is
indicated in the URL commodity order and which enables the details of the
purchased goods to be recorded in the tr~n~ctinn register of the payment server.Figures 4A to 4C show the operations carried out by the payment server 40
in response to the reception of a payment order.
In the front unit 41(Figure 4A), the payment order is decoded (stage 61)
and its validity is e~minrd (test 62) notably from the point of view of the validity
period. If the result of the cx;....i~ ion is negative, a refusal notification is sent to
25 the customer station (stage 63). If the result of the ~i....;..~tion is positive,
customer authentication follows (stage 64). The details of this operation are
described further with reference to Figure 4C. If the authentication is negative (test
65), a refusal notification is sent to the customer (stage 63). If the a~lthrntication
produces a positive result, the payment order (possibly limited to the ~;u~lome~30 identity CId, the supplier identity MId and the price) is tr~n~mittecl via the
col"",u"ication stage 68 to the rear unit 42 of the payment server shown in Figure
2 (stage 66). The col~lec~ion 48, as mentioned above, is a secure connection
p~ c;lllillg access to the rear unit by persons connected to the network 10.
The front unit 41 then waits for the rear unit to clete, . . . i . .~ whether or not to
35 authorise the payment (stage 67). If the payment is not authorised, (test 68), a
refusal notification is sent to the customer station (stage 63). If the payment is

CA 02217739 1997-10-08




authorised, a voucher is ~p~llcd (stage 69) usirlg the information recorded in stage
62. The voucher is saved in a memory of the front unit 41 (stage 70) and is sent to
the supplier server via the customer station (stage 71).
~ the rear unit 42 (Figure 4B) of the payment server, a newly received and
5 ~uth~nticated payment order is ~mine~l to ~ "~ whether this order should
be ~uth(>ri~ed from the customer account PME or through the banking ~lc;lwolh. In
this respect, the price is colllpdlGd with a ~ ... threshold (test 72). Thisthreshold is, for example, some tens of French francs.
If the threshold is exceeded, a request for effecting the payment operation is
10 sent to the banking network (stage 73) using the banking identity co,,c;spollding to
the customer identity CId as obtained from consultation of the data base 44. Thepositive or negative response from the banking network (stage 74), when received,
is l.~...c...il~e-l to the front unit 41 (stage 75).
If the threshold is not exceeded, the payment can be effected from the PME
15 customer account.
In this event, the customer ~Ccount iS ~x;tlll i..ed to ~let~-- .. . i..~. whether it has
sufficient funds (test 76). If it does not, a refusal of payment authorisation is sent
from the rear to the front unit (stage 75). If it does, the price is debited from the
PME customer account, the TCE supplier account collc;s~onding to the identity
MId is credited with the same sum (stage 77), the transaction is inscribed in the
transaction register 45 (stage 78), and the payment authorisation - in other words,
a positive response - is lldnslllilled to the front unit 41 with the indication of the
serial number of the inscription in the tr~n~ction register (stage 75).
The authentication procedure in the payment server (Figure 4C~, at the
stage 64 of Figure 4A, comprises sending to the customer station, preferably in
secure (encrypted) form, a ~leln~n-l for an access key, or pdS~WOld (stage 641).Upon reception, in secure form, of the access key (stage 64), a COlll~dliSOll iSeffected between corresponding information contained in the data base 44 (test
643). If the col"palison is negative, and a lll~illlUlll number of ~In~ucc~ssf~ll
dlk;lll~l~ has not been reached (test 644), the process returns to stage 641. If this
mi.x;.~,.. number has been reached, the failure to authorise is noted, and an alert
is produced (stage 645) and a negative response is sent to the customer station
(stage 646). The alert can comprise cancellation of the PME account or
surveillance of this account in order to detect new usage ~ ;",~ f the test at
step 643 is positive, the ~uthent;cation is recorded (stage 647) and a positive
response is provided (stage 648).

CA 02217739 1997-10-08




Dirr~ilG~ nr~1ing tç~hni~ e.s for p~....;ll;..~ secure ~ m of
numeric information in a colll~ulel network are well known, notably for the
request and sçn~lin~ of access keys.
The authentication procedure disclosed herein permits a prel i . . . ; . .. . y
S ~lth~ntication of a customer to be effected when necessary before the
establishment of a payment deln~n~l by the supplier's server. For this
~lth--ntir~tion, it is ~nfficient to create a payment ticket in which the price
indicated is zero, as indicated above.
The recording of the voucher in the front unit permits the cnctomer~ and the
suppliers to carry out controls and, possibly, to obtain copies of these. The
ccol~lillg of tr~n~ctions in the rear unit enables records of the transactions to be
conserved for possible use when needed later, for example, in the case of a dispute
arising belwt;till a customer and a supplier.
The balance in the customer accounts PME m~n~ge~d by the payment
server is limited in size and, according to the pl~;rt;llt;d embodiment of the
invention, these accounts do not receive interest payments (the payment system
being separate from the b~nkin~ world). Replenishment by a customer of his PME
~c~ount can be effected from his bank account, by placing an order with his
banking establishment.
The supplier accounts TCE m:~n~g~o~l by the payment server are ~c~oci~ted
with real bank accounts of the suppliers, into which they are, for example, emptied
daily.
Although there has been described above one way of putting into effect the
method according to the invention in an Internet ellvho~ lent and with WWW
software using the HITP protocol, a person skilled in the art will readily
appreciate that the method can be put into effect with a network other than Internet
or further with supplier servers and customer station software which does not use
the HITP protocol of WWW. Furthermore, secure ~thrntication methods using
a~dldllls such as smart card readers or voiceprint recognition means can be
foreseen in the place of access keys. These and other variations which will occur
to those skilled in the art are within the spirit and scope of the present invention.

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date Unavailable
(86) PCT Filing Date 1996-04-03
(87) PCT Publication Date 1996-10-17
(85) National Entry 1997-10-08
Dead Application 2000-04-03

Abandonment History

Abandonment Date Reason Reinstatement Date
1998-04-03 FAILURE TO PAY APPLICATION MAINTENANCE FEE 1998-06-02
1999-04-06 FAILURE TO PAY APPLICATION MAINTENANCE FEE

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Application Fee $300.00 1997-10-08
Reinstatement: Failure to Pay Application Maintenance Fees $200.00 1998-06-02
Maintenance Fee - Application - New Act 2 1998-04-03 $100.00 1998-06-02
Registration of a document - section 124 $100.00 1999-01-13
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
G C TECH
Past Owners on Record
DAHAN, GERARD BEN
PAYS, PAUL-ANDRE
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Cover Page 1998-01-20 2 68
Abstract 1997-10-08 1 26
Description 1997-10-08 9 512
Claims 1997-10-08 3 100
Drawings 1997-10-08 5 73
Representative Drawing 1998-01-20 1 4
Assignment 1999-01-13 4 128
PCT 1997-10-08 34 1,372
Assignment 1997-10-08 3 104
Correspondence 1997-12-23 1 32
Fees 1998-06-02 1 47