[go: up one dir, main page]

WO2002029740A1 - Systeme de paiement oriente reseau - Google Patents

Systeme de paiement oriente reseau Download PDF

Info

Publication number
WO2002029740A1
WO2002029740A1 PCT/EP2000/009723 EP0009723W WO0229740A1 WO 2002029740 A1 WO2002029740 A1 WO 2002029740A1 EP 0009723 W EP0009723 W EP 0009723W WO 0229740 A1 WO0229740 A1 WO 0229740A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
accounts
account
server means
ticket
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2000/009723
Other languages
English (en)
Inventor
Michael Marcovici
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
QENTIS HOLDING GmbH
Original Assignee
QENTIS HOLDING GmbH
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 QENTIS HOLDING GmbH filed Critical QENTIS HOLDING GmbH
Priority to PCT/EP2000/009723 priority Critical patent/WO2002029740A1/fr
Priority to AU2000279140A priority patent/AU2000279140A1/en
Publication of WO2002029740A1 publication Critical patent/WO2002029740A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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
    • G06Q20/042—Payment circuits characterized in that the payment protocol involves at least one cheque
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/29—Payment schemes or models characterised by micropayments

Definitions

  • the present invention relates to a method for managing accounts on a server means accessible over a public network, such as the well-known Internet, and a server means for performing such a method.
  • the server means is accessible over a public network and has a data base holding data related to accounts, each of these accounts being accessible by accession data and having an amount datum representing an account value.
  • the accession data comprise an identification code which is unique with respect to the accounts established on the server means, the data held in said data base including the accession data.
  • payment transactions are performed between accounts in accordance with transaction data received over an interactive surface presented by the server means on at least one terminal of said network, the transaction data comprising the accession data of the accounts involved in the transaction as well as a payable amount.
  • public networks in particular computer networks such as the so-called Internet
  • public networks in particular computer networks such as the so-called Internet
  • services such as information services, remote bank accounting or professional advice.
  • the service is performed over the Internet, e.g. by means of an E— mail or HTML transmission, the problem arises how the payment is done in exchange for the service rendered.
  • One usual method of payment is done via a credit card of the customer, wherein the credit card number is transmitted to the provider of the service in a secure connection.
  • This method bears a considerable potential of risk for the owner of the credit card since both the quality of the connection and the trastworthiness of the seller often cannot verified by the customer. Therefore, many users of the Internet which would be potential customers of services offered over the Internet are not willing to use credit cards or similar means of payment over the Internet even if that means that they do not use the service offered at all. Moreover, due to the considerable overhead, this method of payment is not suitable for services for which the fee unit is small.
  • a known method for performing payments between computer stations connected to a computer network is the so-called digital cash system.
  • this method to a computer of a potential customer virtual coins are distributed, and upon payment for a service of a seller, virtual coins are transferred to the seller.
  • a main advantage of this system is that the virtual money is located on a computer; moreover, if there is a failure of the computer, all virtual coins are lost.
  • the digital cash system shall be operated it is necessary to install the virtual money software beforehand.
  • a mobile user can charge the phone account of his/her mobile phone by means of a so-called pre-paid card which is acquired at a given price and which contains a code.
  • the mobile user Upon dialing a service number of the mobile telephone provider, the mobile user states this code - e.g. by entering the code over the key pad of his/her phone - and is then credited an amount of call units to the mobile phone account in correspondence with the price that was previously paid for the pre-paid card.
  • This method is only working between one or more customers to a single provider; the pre-paid card can only be used for the service of the provider.
  • the fees involved in effecting a pre-paid transaction are considerable, usually in the range of several 10 % of the amount actually paid.
  • an aim of the present invention is to offer a way to perform a payment between users of a public network avoiding the mentioned disadvantages.
  • a money worth shall freely flow between a plurality of users without a devaluation by, e.g., transaction fees.
  • a further aim of the invention is to offer anonymity of the users of the payment system as far as possible within the framework of financial law, while ensuring that transactions involving amounts transferred into or out of the system can be traced back to the benefiting person or organization.
  • a method as mentioned in the beginning comprising, according to the invention, the steps of: a) sending of a request from a requesting party to said server means, b) establishing of at least one account, including the accession data associated therewith, by the server means, the number of accounts generated being in accordance with said request, c) assignment of an amount to said account or, as the case may be, each of said accounts according to data specified in the request, and d) transmittal of the accession data of said account(s) from the server means over said network to the requesting party, whereupon said account(s) as represented by the respective accession data are distributable by the requesting party to third parties.
  • the requesting party is, in the following, also referred to as the issuer since it is usually this party that will distribute and issue the accounts to the third parties. Possibly, there may be more than one issuer involved in the system according to the invention.
  • the issuer distributes the accounts obtained from the server means, e.g. by way of selling, to third parties who then have the right to dispose with the accounts and the account values associated thereto.
  • This solution represents a simple way of generating accounts from which payments can be effected wherein the users are independent of the use of a given terminal or computer client station, due to the provision of accounts held on a central station, viz., the server means.
  • the money which is represented by the account values can flow freely between a plurality of accounts without any depreciation by transaction fees as long as the money worth circulates within the set of accotmts held by the server means.
  • the participants in the account system only need to know their respective account accession data, but need not know any specifics about trade partners with whom they engage in payment transactions according to the invention; in particular, they are anonymous to each other.
  • a ticket is issued on which the accession data of the respective account are provided.
  • the accession data on the ticket, or at least a part of these data may be coded as barcodes.
  • the ticket may be provided with a cover rendering unrecognizable at least part of the accession data present on the ticket, the cover adapted to be removed to unveil said data before the first transaction performed with the associated account. Tickets of this kind are used as a supportive device for the transactions done with the accounts, in particular as a representative device for the account itself.
  • the ticket may be issued in a design as specified in the issuer's request.
  • steps c and d are not performed until a payment in accordance with the number of accounts generated and the amounts to be assigned to said accounts is effected in favor of a party associated with the server means.
  • the server means provider may grant a discount to the issuer, if the difference is covered by the provider or another side.
  • the accession data may comprise an activation time which is assigned in step b with a time value not earHer than the time of actual generation of the respective account.
  • the activation time specifies the earliest time when a transaction may be performed with the respective account.
  • the activation time is initialized with a time value specified in the issuer's request.
  • accession data may comprise a debit accession code, which is verifyable in payment transactions for accounts from which a payment is to be debited.
  • accession data are independent of personal data of any user of the respective account(s).
  • a realization of the invention which is particularly useful is operating on a computer network, such as the Internet.
  • the accounts may comprise at least one amount datum, each amount datum being associated with a respective requesting party (issuer), in order to "tie” the respective amounts to the issuer and facilitate backtracing of money flow.
  • payments my be restricted to payments with respect to amount data referring to the same requesting party only.
  • a server means of the type as mentioned in the beginning is suitable which, according to the invention, is adapted to generate accounts upon reception of a specific request sent from a requesting party, namely, to establish accounts, including the accession data associated therewith, the number of accounts generated being in accordance with said request, to assign to each account thus generated an amount according to data specified in the request, and to transmit the accession data of said account(s) from the server means over said network to the requesting party, whereupon said account(s) as represented by the respective accession data are distributable by the requesting party to third parties.
  • this server means is also adapted to transact payments in return for a service provided over the network from a service provider associated with a first account towards a customer associated with a second account. It may be further adapted to transact payments independent of an associated return service.
  • the server means is accessible over a computer network, such as the Internet.
  • a computer network such as the Internet.
  • the payments between accounts held in said data base are transacted by the server means free of charges with respect to the accounts involved.
  • the server means performs a check with a payment transaction, in that the transaction is effected only if the account value of the account from which the payment is to be effected is not smaller than the payable amount.
  • Fig. 1 a ticket according to a preferred embodiment
  • Fig. 3 a payment transacted between two tickets.
  • the preferred embodiment relates to an account ticket system on the Internet.
  • the invention is not restricted to the Internet; for instance, any data network connectable with or accessible from the Internet can be used as well.
  • Fig. 1 shows a ticket Tl as sold with a given initial value.
  • the ticket Tl shows several data items TIM,TID,BID, some further items present on the ticket Tl are hidden by a cover CON; when the ticket is used the first time it is "opened” by removing the cover CON in order to reveal further ticket specifications TCO,BCO.
  • the cover CON is realized as a scratch stripe, and the ticket is "opened” by scratching off the stripe in order to reveal the data TCO,BCO printed on the area CON' under the cover COV.
  • the appearance of the opened ticket T2 is shown in Fig. 2.
  • the account ticket T1,T2 has the following features according to the invention:
  • an initial amount TIM in a given currency such as U.S. dollars or Euros, representing the initial amount of money which is associated with the ticket Tl when it is put into circulation for the first time
  • the initial amount TIM is suitably printed on the cover stripe COV and is removed when the ticket is opened
  • a ticket number TID which consists of a sequence of, e.g., 22 digits and is a unique code for identifying the ticket and the associated account
  • ticket code TCO or ticket password which consists of a sequence of, e.g., 6 digits; the ticket code is initially covered by the cover stripe COV and becomes visible when the ticket is opened;
  • the ticket code barcode BCO is initially covered by the cover stripe as is the case for the ticket code TCO and becomes visible when the ticket is opened;
  • the ticket number TID is generated by any method which produces a pseudo-random sequence of numbers. This prevents hackers from systematic attack which would be possible if the ticket numbers were a consecutive sequence of numbers. To ensure uniqueness of the ticket number, the number is checked upon generation whether it is already present in the data base; if this is the case (which is very unlikely for a suitable algorithm such as the MD5 algorithm cited below), the number is discarded and another number is generated.
  • the length of the ticket number TID e.g. 22 digits, is arbitrary but chosen such that the quantity of possible ticket numbers is sufficiently (i.e., by several orders of magnitude) greater than the number of tickets issued. Thus, it is sufficiently improbable that a ticket number is accessed by simple try and error.
  • the length of the ticket number TID can be increased at a later time when it is regarded necessary, for instance, when the number of issued tickets reaches a predetermined threshold - e.g., 0.001% (corresponding to about 10 15 tickets with 22-digit ticket numbers! or even less - with respect to the quantity of possible ticket numbers.
  • a predetermined threshold e.g., 0.001% (corresponding to about 10 15 tickets with 22-digit ticket numbers!) or even less - with respect to the quantity of possible ticket numbers.
  • each ticket is provided with the already-mentioned ticket code which serves as a password for every transaction with the ticket and the associated account.
  • the ticket code consists, e.g., of a string of 6 digits; in other variants, the ticket code may contain alphanumeric characters, possibly including special characters.
  • any method providing a non-predictable sequence of digits may be used.
  • any type of known pseudo-random number generators having a sufficiently repeat cycle can be used.
  • a combination of plural number generators may be used.
  • two generators each producing a 12-digit number may be used; from both numbers thus generated, one digit is deleted (e.g., the first and the third digit, respectively), and the two 11-digit strings thus obtained are then combined into a 22-digit sequence.
  • the time of generation in milliseconds may be used as input seed for the pseudo-random number algorithm.
  • account tickets can be offered by any vendor interested, such as a store, a gas station, a post office or a vending office of an E-commerce company.
  • a person who wants to acquire an account ticket pays the price of the ticket according to the amount TIM printed on the ticket, and thus becomes the owner of the ticket.
  • the ticket owner can then use the ticket as a means of payment via Internet or telephone. Due to the fact that the initial value of a ticket is rather low, e.g. 20 dollars or 25 Euros, it is not necessary that the buyer of a ticket must disclose his/her identity and thus can remain anonymous with respect to the ticket account system.
  • the ticket data are held and managed in a data base DAB residing on a transaction server TAS which is realized as a computer server accessible over Internet IPN, for instance via a web site, and operated by the provider of the ticket account system.
  • TAS Transaction server
  • IPN Internet
  • the preferred embodiment relates to an implementation of the ticket account system on the Internet wherein the users have access over, e.g., computer terminals using the TCP/IP protocol and graphic representation coded in a known mark-up language such as HTML
  • the invention can also be realized in other networks, such as a mobile phone network, wherein the messages transmitted are realized using, e.g., the known WAP language.
  • the data base holds the data of the accounts associated with a ticket, such as the ticket number, the ticket code (including an "addon” code, if present, as explained below), the current account balance ('amount') and the currency.
  • Further data which are suitably stored with an account are an issue time/ date stamp ISD, representing the time of issuance of the respective ticket, and an activation date ACD, which states a date not earlier than the issue time and which serves to define a date since when the ticket may be used ("is active").
  • the activation date may be used with, e.g., tickets which are produced well before the intended time of vending, in order to rule out non-authorized usage before the tickets are put into circulation on the day stated as activation date.
  • a further suitable element associated with a ticket account is an 'active' entry, stating whether the account is allowed to be used in transactions; this item is set upon issuance or, if applicable, on the day specified in the activation date and can be reset upon specific request, e.g., if the ticket was stolen.
  • Another possible item is a number of failures count, which is increment with each failed trial of access to the ticket account; after a given number of failures, e.g. three or five, the ticket is frozen, e.g. by resetting the 'active' entry to non-active.
  • a ticket over the Internet from a web site associated with the data base of the ticket account system and provided by the server TAS.
  • the web site is, e.g., implemented using the following HTML code:
  • This HTML code accepts an E-mail address with the variable emailadress from the user of the web site and, when the user clicks the button "Get new ticket", sends the total data to a ticket supply application located at the transaction server and cited in the action argument of the form command (first line of the above code).
  • the ticket supply application triggers generation of a new ticket account, and generates a web site containing the accession data of the new ticket account, in particular the ticket number and the ticket code.
  • the application then sends to the E-mail address of the user an E-mail message containing a link to this web site.
  • the user can then obtain the ticket data from the web site thus specified; if desired, he can print a copy of the ticket from the graphical representation on the web site.
  • the ticket thus obtained has an initial value of zero, and must be "charged up” before first use as described hereinafter.
  • the ticket data are not sent in an E-mail or like message since this would bear too high a risk for diversion of the data to a "hacker" or other unauthorized person.
  • the web site is discarded after the data were read by the user, and for each ticket account requested over Internet a new web site with a unique address is generated, in order to rule out possible fraud or unauthorized access to the ticket data.
  • each party i.e., the merchant MER as well as the customer CUS (purchaser)
  • the ticket code TCO pertinent to his/her ticket is required for the transaction; the merchant's ticket code need not be specified.
  • the payment is done over the Internet with reference to a web site provided by the transaction server TAS.
  • the customer enters the ticket number and the ticket code of his/her ticket with the web site dialog, and the merchant enters his/her ticket number and the amount of the payment.
  • a secure socket layer is opened in order to ensure a secure exchange of the data relevant to the transaction.
  • the secure socket layer is, for instance, implemented using the following HTML code:
  • This HTML dialog produces a form that accepts the data for the transaction, stores them into the variables sampleticketnumber, amount, customerticketnumber and codenumber, and hands the total data to a transaction appUcation located at the transaction server and cited in the action argument of the form command (first line of the above code).
  • the transaction application subtracts the amount from the ticket account of the customer's ticket and credits the amount to the ticket account of the merchant.
  • the completion of the transaction is then notified to the merchant. For the transaction, no charges are billed by the side of the transaction server.
  • Each transaction is logged in the data base, for instance with a date/time stamp, the two ticket numbers (i.e., of the merchant's and customer's tickets), the payment amount and the currency.
  • a transaction type can be stored with the transaction, which type denotes whether the transaction was credited to a ticket or to a bank account or a credit card account.
  • the server also offers the possibility for the owner of a ticket to change the ticket code TCD.
  • the change of the code is handled over a web site provided by the server and is performed like a change of password known from other systems.
  • the ticket owner is allowed to enter a new code which need not be restricted to the original 6 digits, as in this embodiment, but can choose a code of increased length of up to, e.g., 12 characters, and/ or including alphanumeric and special characters.
  • the money value represented by the credits on the ticket accounts can circulate freely from ticket account to ticket account.
  • the users of the ticket account system stay anonymous as long as the credit sums remain within the system since only the ticket numbers are recorded, but no further reference to the identity of the user.
  • a ticket can be used as long as its current state of account is positive (i.e., greater than zero). When the ticket has been used up, it may be destroyed. Alternatively, a ticket may be charged up again from a credit card, by means of a bank transfer, or the like. For charging up, a charge-up appHcation in connection residing on the transaction server may be used in connection with an HTML code like the foUowing with respect to credit-card charge-up:
  • the charge-up appHcation obtains the relevant data, checks back with the pertinent credit institute, and if this check is affirmative the amount is credited to the ticket account.
  • the ticket code ('Codenumber') is required; this can also be omitted.
  • the charge-up transactions are stored in the data base, recording the ticket number and the account data (number, name, etc.) of the credit or bank account, respectively, as weU as the date/ time stamp.
  • the owner of the ticket - or, more exactly, the person providing the money amount - is not anonymous to the ticket account system provider any more insofar as the owner is identifiable via the bank or credit card account; more important, though, is that anonymity towards other users of the ticket account system is maintained.
  • the ticket code can be expanded with an "addon code" containing digits, alphanu- meric characters or characters including special characters.
  • the length of the addon code e.g. 3, 6 or 9 characters or variable-length, is chosen accordingly to the degree of additional security needed.
  • the addon code is stored in the data base with the ticket code and can be changed by the owner of the ticket in the same way as the ticket code is changed. This feature is important for merchants who will run a high count of transactions and/ or accumulate high money amounts to their ticket accounts, since such an account would otherwise be a likely and lucrative target for a third person to attempt to break the code.
  • the access to a ticket may be restricted to a part or region of the network, for instance, by specifying a given set of IP addresses from which the access must be negotiated.
  • the restriction can be vaHd for aU access types, or only for debiting access.
  • the ticket account of a service provider may be open to credit access from any site, in order to aUow payments to be done in return for services provided, but the amount thus coUected can only be transacted to one or a few other accounts which have been specified beforehand.
  • a further possibility is to aUow transactions or certain types of transactions only if the transacted amount and/ or the account value of the ticket is above (or below) a respective limit associated with the ticket account, possibly H combination with the condition that the transaction refers to a site in a defined part or region of the network. For example, with a given account used for payment of services offered to a wide range of cHents it may be des ⁇ able to secure against users which might block off other cHents with large requests, and only transactions with very smaU amounts are aUowed regardless of the site of transaction, including debiting and crediting transactions; otherwise the transaction and the corresponding service is denied.
  • a further possibility to verify a debit transaction for a large amount is to demand that in the case that the amount is larger than a limit as specified in the account data, the debitor is requested to make a phone caU to a service number of the server provider; only after this caU the transaction is effected.
  • a credit amount present on a ticket account it is, of course, also possible to disburse a credit amount present on a ticket account, entirely or any part of it, to an account of a credit institute, e.g. a bank or a credit card company.
  • the disbursement transaction wiU lift anonymity of the user to the ticket account system provider, but maintains anonymity towards other users of the ticket account system.
  • the ticket owner specifies his/her ticket data including the ticket code and the account data of the credit or bank account to which the specified stun - after deduction of a provision of, e.g. 1% or 10%, charged in favor of the provider of the ticket account system - is to be transferred.
  • the ticket system provider entrusts one or more separate organizations ISS with the issuing of tickets.
  • the pertaining ticket numbers and codes are generated by the provider and distributed from there to the issuers ISS, in order to ensure that the ticket system is coherent, but the further process of production of tickets, initial charge-up and further distribution to vendors and/ or customers and/ or merchants can be taken over by the issuers.
  • relevant information relating to the issuers such as name, address and quantity of issued tickets, may advantageously be recorded in the data base as weU.
  • the issuing process is started by a request from an issuer ISS to the ticket system provider for a number of tickets initiaUy charged with a specified amount, sent e.g. as an E- mail message over the Internet IPN.
  • the issuer then transfers the total amount resulting from the number of tickets and the initial amount, to a bank account of the provider.
  • the provider then generates and loads a desired quantity of ticket accounts and distributes them to the issuer.
  • the provider may grant the issuer a discount on the price of the tickets with respect to the amount with which the tickets are actuaUy initialized.
  • the discount can be equal to or smaUer than the provision with a transaction to a bank or credit card account.
  • the present invention offers advantages to companies operating with the Internet or other data networks, and in particular for so-caHed E-commerce companies.
  • the invention offers a simple and fast method to effect payment for services presented and/ or deHvered over Internet. Issuing will be especiaHy attractive since credit amounts earned via, e.g., E-commerce services can be used again for new tickets to be issued.
  • design of the tickets e.g., with additional advertisements
  • the issuers may obtain special discount conditions with the ticket system provider.
  • AU transaction relating to tickets are logged with the data base. This feature ensures control over the account transactions to the users of the system, merchants (debitors) as weU as customers (creditors). Moreover, the invention offers a high security against fraud since the recipient of a disbursement is known.
  • the aspect of the invention relating to issuing represents an important side of the invention.
  • Companies such as E-commerce providers or bank institutes may act as issuers.
  • An issuer produces tickets initialized with a starting amount; the pertinent ticket account data have, beforehand, been coUected from the ticket account system. The tickets thus produced can now be sold H shops or outlets of the issuer like coupons.
  • the issuer adds to the ticket a specific design which may, for instance, have a commercial or advertising content or comprise information relating to the services or an Internet web site of the issuer.
  • an issuer can add advertisements for the service of a tt ⁇ rd party, even if the issuer himself does not provide any services, thus obtaining an additional income from these advertisements.
  • H a variant of the ticket account system
  • the tickets can be bound closer to the respective issuer.
  • a ticket issued by a specific issuer is, the fust place, to be used for payments done with the issuer or associated parties like, for instance, when a customer accepts a service over a web site of the issuer and pays by means of a ticket (or a number of tickets) issued by this issuer; the payment is then transacted between the customer's ticket and an account of the issuer's as described above.
  • An issuer may additionally provide some or all of his tickets with special conditions, such as an automatic discount on services provided from the issuer (or an associated party) to a customer.
  • the issuer does not necessarily have to pay the starting amount of a ticket to the provider of the ticket account system, since the ticket is primarily intended for payments with the issuer anyway.
  • a ticket can stiH be used for payments with other merchants, which are not related to the issuer.
  • Hi a payment transaction between the merchant and the customer holding a ticket of a "foreign" issuer the ticket account system acts as a mediator between accounts relating to different issuers. Now, however, the ticket account system has to account for amounts which flow between different issuers. For this, a provision may be charged, e.g. as a 5% fee on the payment done, payable by the customer or the merchant (or the issuer associated with the merchant) depending on the actual agreements.
  • the advantage of this variant is that it incurs no organizational overhead to the issuer as long as the customers holding tickets of the issuer use these tickets for payments with the issuer. There is the option of an additional source of income when his tickets are used for payments with other merchants/issuers.
  • the issuer receives the takings arising from the sale of the tickets immediately. Potential compensation transactions with other issuers or the ticket account system acting on behalf of the other issuers is delayed.
  • a del notebookre has to be suppHed by the ticket account system provider via a deficiency insurance.
  • aU open tickets are settled between the issuers and the central ticket account system.
  • a ticket can be used not only for effecting a payment, but also for accepting a payment. This faciHtates transactions also between ticket holders which are both primarily acting as customers or merchants.
  • an account may have a number of account amounts, rather than a single amount as considered so far.
  • Each amount is then associated with a respective issuer and, possibly, other data used for bookkeeping purposes, such as a reference to the respective issuing series.
  • this Hst of amounts is usually not disclosed unless the ticket owner expHcitly requests a detailed information. In the usual case, however, only the total sum of the amounts is of interest and is, therefore, displayed.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de gestion de comptes sur un moyen serveur accessible par un réseau public, tel que le célèbre Internet, et un moyen serveur pour mettre en oeuvre un tel procédé. Le moyen serveur est accessible par un réseau public et comporte une base de données contenant des données relatives à des comptes, chacun de ces comptes étant accessible par des données de consultation et contenant une quantité de données représentant une valeur de compte. Les données de consultation comportent un code d'identification unique pour les comptes établis sur le moyen serveur, les données contenues dans ladite base de données comportant les données de consultation. De plus, des transactions de paiement sont effectuées entre des comptes par l'intermédiaire du moyen serveur selon des données de transaction reçues sur une surface interactive présentée par le moyen serveur sur au moins un terminal dudit réseau, les données de transaction comportant les données de consultation des comptes impliqués dans la transaction ainsi qu'un montant à payer. Un compte est créé par le serveur par envoi d'une demande d'un tiers au moyen serveur, établissement d'au moins un compte, intégrant les données de consultations associées à ce compte, par le moyen serveur, le nombre de comptes créés étant fonction de ladite demande, attribution d'un montant à ce compte ou, le cas échéant, à chacun de ces comptes selon des données spécifiées dans la demande, et transmission des données de consultation dudit/desdits compte(s) à partir du moyen serveur sur ledit réseau au tiers.
PCT/EP2000/009723 2000-10-05 2000-10-05 Systeme de paiement oriente reseau Ceased WO2002029740A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/EP2000/009723 WO2002029740A1 (fr) 2000-10-05 2000-10-05 Systeme de paiement oriente reseau
AU2000279140A AU2000279140A1 (en) 2000-10-05 2000-10-05 Network oriented payment service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2000/009723 WO2002029740A1 (fr) 2000-10-05 2000-10-05 Systeme de paiement oriente reseau

Publications (1)

Publication Number Publication Date
WO2002029740A1 true WO2002029740A1 (fr) 2002-04-11

Family

ID=8164114

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2000/009723 Ceased WO2002029740A1 (fr) 2000-10-05 2000-10-05 Systeme de paiement oriente reseau

Country Status (2)

Country Link
AU (1) AU2000279140A1 (fr)
WO (1) WO2002029740A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010000884A1 (fr) * 2008-07-01 2010-01-07 Visiers Sanz, Irache Procédé pour effectuer des transactions sécurisées de paiement et d'encaissement au moyen de terminaux avec une connexion de données

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5671364A (en) * 1993-02-10 1997-09-23 Turk; James J. Method and system for commodity-based currency for payment of accounts and elimination of payment risk
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5801365A (en) * 1996-07-08 1998-09-01 Katz; Richard B. Fund raising by discounted collection on special issue checks
US6014646A (en) * 1995-06-08 2000-01-11 France Telecom Process for making a payment using an account manager
WO2000026745A2 (fr) * 1998-11-02 2000-05-11 Hsx, Inc. Systeme informatique destine au commerce de valeurs boursieres, avec devise virtuelle et specialiste virtuel

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5671364A (en) * 1993-02-10 1997-09-23 Turk; James J. Method and system for commodity-based currency for payment of accounts and elimination of payment risk
US6014646A (en) * 1995-06-08 2000-01-11 France Telecom Process for making a payment using an account manager
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5801365A (en) * 1996-07-08 1998-09-01 Katz; Richard B. Fund raising by discounted collection on special issue checks
WO2000026745A2 (fr) * 1998-11-02 2000-05-11 Hsx, Inc. Systeme informatique destine au commerce de valeurs boursieres, avec devise virtuelle et specialiste virtuel

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010000884A1 (fr) * 2008-07-01 2010-01-07 Visiers Sanz, Irache Procédé pour effectuer des transactions sécurisées de paiement et d'encaissement au moyen de terminaux avec une connexion de données

Also Published As

Publication number Publication date
AU2000279140A1 (en) 2002-04-15

Similar Documents

Publication Publication Date Title
US8676707B2 (en) Credit cards system and method having additional features
US8019690B2 (en) Method and system for transacting an anonymous purchase over the internet
US6405182B1 (en) System for dispensing prepaid debit cards through point-of-sale terminals
US7130828B2 (en) Debit purchasing of stored value card for use by and/or delivery to others
US6456984B1 (en) Method and system for providing temporary credit authorizations
US8893963B2 (en) Issuing a value-bearing card associated with only non-personally identifying information
US20030004828A1 (en) Prepaid card authorization and security system
US20090327133A1 (en) Secure mechanism and system for processing financial transactions
US20020026418A1 (en) Method for providing pre-paid anonymous electronic debit card compatible with existing network of credit cards
US20010037209A1 (en) Pre-paid payment system and method for anonymous purchasing transactions
KR20020006625A (ko) 중간계정을 이용하는 전자 지불 시스템
US20030163423A1 (en) Method and apparatus for secure electronic payment
AU3108199A (en) A method for using a telephone calling card for business transactions
WO1997019414A1 (fr) Systeme de paiement monetaire par reseau informatique
US20080270245A1 (en) System For Processing Stored Value Instrument
JP2005519402A (ja) 支払カード及び方法
GB2352861A (en) Payment transaction system
US7445150B2 (en) Pre-paid credit card
AU774122B2 (en) E commerce system
WO2002029740A1 (fr) Systeme de paiement oriente reseau
WO2007029123A2 (fr) Systeme et procede de traitement de transactions
CA2311190A1 (fr) Systeme et methode de traitement de certificats
GB2412777A (en) Electronic voucher system using mobile phones
HK1115215A (en) Transaction system and method
MXPA00009080A (en) A method for using a telephone calling card for business transactions

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP