WO2002029740A1 - Network oriented payment service - Google Patents

Network oriented payment service 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
Application number
PCT/EP2000/009723
Other languages
French (fr)
Inventor
Michael Marcovici
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 AU2000279140A priority Critical patent/AU2000279140A1/en
Priority to PCT/EP2000/009723 priority patent/WO2002029740A1/en
Publication of WO2002029740A1 publication Critical patent/WO2002029740A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/042Payment circuits characterized in that the payment protocol involves at least one cheque
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/29Payment 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.

Abstract

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 dna 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. Furthermore, by the server means 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. An account is generated by the server by sending of a request from a requesting party to said server means, 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, assignment of an amount to said accountor, as the case may be, each of said accounts according to data specified in the request, and transmittal of the accession data of said account(s) from the server means over said network to the requesting party.

Description

NETWORK ORIENTED PAYMENT SERVICE
Field of the invention and description of prior art
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. Furthermore, by the server means 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.
In connection with so-called E-commerce services, public networks, in particular computer networks such as the so-called Internet, have become an attractive medium for offering, ordering and selling products of various kinds, but also for offering, requesting and rendering services, such as information services, remote bank accounting or professional advice. In particular in cases where 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. According to 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. Apart from the various possibilities of fraud, 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. Furthermore, on each computer on which the digital cash system shall be operated it is necessary to install the virtual money software beforehand.
Another known method is used in connection with the call fee accounting of, for instance, mobile telephones. Here, 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. 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, however, 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. Moreover, the fees involved in effecting a pre-paid transaction are considerable, usually in the range of several 10 % of the amount actually paid.
Summary of the invention
In view of the above-described known methods of payment, 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. In particular, 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.
This aim is met by 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. This makes the circulation of money within the account system attractive and enhances trade. Charges are only taken for money put into or taken out of the system, for instance, to or from (as the case may be) a bank account; these outward payments can be recorded in compliance with the relevant financial law. 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.
In a preferred embodiment of the invention, for each of the generated accounts, a ticket is issued on which the accession data of the respective account are provided. On this ticket, the accession data on the ticket, or at least a part of these data, may be coded as barcodes. Furthermore, 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. Moreover, the ticket may be issued in a design as specified in the issuer's request.
Preferably, 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. This is to ensure that the account values are covered by the corresponding money's worth. Of course, the server means provider may grant a discount to the issuer, if the difference is covered by the provider or another side. In order to exclude premature use of accounts, 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. In a suitable variant, the activation time is initialized with a time value specified in the issuer's request.
As further means of security, the accession data may comprise a debit accession code, which is verifyable in payment transactions for accounts from which a payment is to be debited.
In a variant of the invention which may be attractive for future users of the invention, the 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.
In a variant of the invention, 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. In this case, payments my be restricted to payments with respect to amount data referring to the same requesting party only.
For carrying out the method according to the invention, 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.
In a preferred embodiment of the invention, 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.
Suitably, the server means is accessible over a computer network, such as the Internet. In a variant which is expected to be very attractive for users of the invention, the payments between accounts held in said data base are transacted by the server means free of charges with respect to the accounts involved.
Preferably, 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.
Brief description of the drawings
In the following, the present invention is described in more detail with reference to the drawings, which show:
Fig. 1 a ticket according to a preferred embodiment;
Fig. 2 the ticket of Fig. 1 with removed cover;
Fig. 3 a payment transacted between two tickets.
Detailed description of the invention
The preferred embodiment relates to an account ticket system on the Internet. Of course, it is clear that 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.
The account ticket system is based on tickets, an example of which is shown in Figs. 1 and 2. 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. In the preferred embodiment, 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;
- a 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;
- two barcodes BID,BCO representing the ticket number TID and the ticket code TCO, respectively; 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;
- an issue date ISD and an activation date ACD as described further below.
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. Furthermore, 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 1015 tickets with 22-digit ticket numbers!) or even less - with respect to the quantity of possible ticket numbers.
In order to further enhance the security of access to a ticket account, in particular with respect to debit entries, 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.
To generate the digit strings of the ticket number TID and the ticket code TCO, any method providing a non-predictable sequence of digits may be used. For instance any type of known pseudo-random number generators having a sufficiently repeat cycle can be used. In order to generate long character strings, such as the ticket number, a combination of plural number generators may be used. To generate a 22-digit string for instance, 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. In order to further enhance the random character of the generator, the time of generation in milliseconds may be used as input seed for the pseudo-random number algorithm.
According to the invention, 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.
Referring to Fig. 3, 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. It is noteworthy that, while 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.
As an alternative to acquiring a ticket from a vendor, it is also possible to obtain 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:
<form method="POST" action="https : / /secure . unitx. org/cgi-win/gett . exe">
Emailadress: <input type="text" name=" emailadress" >
<input type="submit" value="Get new ticket"> </form>
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.
For transaction of a payment, which is to be rendered for some merchandise or service (whose nature is not of further interest with the present invention), each party, i.e., the merchant MER as well as the customer CUS (purchaser), need a ticket. In order to ensure that the costumer is authorized to perform the payment with his/her ticket, suitably, 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. For this dialog 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:
<form method="POST" action=" https : / /secure . unitx. org/cgi-win/ticket . exe"> <input type=" hidden" name="merchantticket" value="sampleticketnumber"> <input type=" hidden" name="amount" value="amount"> Ticketnumber: <input type="text " name="customerticketnumber" > Codenumber: <input type="text" name="codenumber" > Amount : amount USDollar <input type="submit" value="Submit Secure ">
</form>
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. Furthermore 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. When changing the ticket code TCD, 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.
As becomes clear from the above, the money value represented by the credits on the ticket accounts can circulate freely from ticket account to ticket account. During the entire credit circulation 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:
<form method ="post" action=https : / /secure . unitex . org/cgi-win/charge . exe>
Ticketnumber <input type="text" name="ticketnr">
Codenumber <input type="text" name="codenr">
Amount <input type="text" name="amount">
Credit card <option name="cc"> <select> Visa Card <select> Mastercard
</option> credit card number <input type="text" name="ccnr"> valid until <input type="text" name="validu">
<input type="submit" value="Charge"> </form>
From this HTML dialog, 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. In the above code, the ticket code ('Codenumber') is required; this can also be omitted. Suitably, also 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. Thus, after charging up of a ticket 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.
Of course, it also possible to transfer the remaining amount from an almost used-up ticket to another ticket, in order to coUect one or more remainders to a single account value.
H order to enhance security of the system with respect to debit transactions from a ticket account, 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.
As another measure to provide security against unauthorized access, 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. For instance, 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.
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. Also 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. In a manner corresponding to the charge-up transaction, 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. Furthermore, it is possible that 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. Furthermore, 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.
H a variant, 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, and in particular the issuing of tickets, 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. Depending on the specifics of trade - such as the trade margin, the turn around, the vending overhead, 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. It is possible that 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. Moreover, 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. Hi this variant, 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. For tickets of this kind, 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.
Hi this variant, 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. As a further advantage, 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. Of course, a del credere has to be suppHed by the ticket account system provider via a deficiency insurance. At regular terms, for instance at the end of a calendar year or every second or thud year, aU open tickets are settled between the issuers and the central ticket account system. It should be noted that, advantageously, 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.
To faciHtate the book-keeping of amounts stemming from different issuers, 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. For the holder of the ticket, 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.
The main advantages of the account system according to the invention are:
- anonymity of the users at least with respect to each other, in particular of a customer towards a merchant;
- paying facility in the Internet also for users who do not have a credit card or do not want to or are not able to use a credit card over the Internet;
- simple handling;
- possibility of handling very smaH payable amounts (so-caHed micropayments);
- fast propagation due to issuing by various organizations;
- easy transferabiHty of accounts/ tickets;
- trust by users by virtue of the presence of a ticket which is present as a physical item, reminiscent of a bank note;
- possibility to offer special reductions, such as a discount for an issuer on an order of a large amount of tickets, or interest;
- lower prices for consumers, by vHtue of the reduced handling overhead costs on the side of the merchants;
- reusabiHty of a ticket used for effecting payments in terms of effecting and/ or accepting payments, also between consumers/ customers;
- backtracing of tiansactions.

Claims

We claim:
1. A method for managing accounts on a server means accessible over a pubHc network, said server means being accessible over a pubHc network and having a data base holding data related to accounts, each of said accounts being accessible by accession data and having an amount datum representing an account value, the accession data comprising an identification code which is unique with respect to the accounts estabHshed on the server means, the data held in said data base including the accession data, and the server means being adapted to perform payment transactions 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 tiansaction data comprising the accession data of the accounts involved in the transaction as weU as a payable amount, the method comprising the steps of: a) sending of a request from a requesting party to said server means, b) estabHshing 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 thud parties.
2. The method of claim 1, wherein for said account or, as the case may be, each of said accounts, a ticket is issued on which the accession data of the respective account are provided.
3. The method of claim 2, wherein at least part of the accession data on the ticket are coded as barcodes.
4. The method of claim 2, wherein the ticket is 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 fust transaction performed with the associated account.
5. The method of claim 2, wherein the ticket is issued in a design as specified in the request of step a.
6. The method of claim 1, wherein 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.
7. The method of claim 1, wherein the accession data 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 specifying the earHest time when a transaction may be performed with the respective account.
8. The method of claim 7, wherein the activation time is initialized with a time value specified in the request of step a.
9. The method of claim 1, wherein the accession data comprise a debit accession code, which is verifyable in payment transactions for accounts from which a payment is to be debited.
10. The method of claim 1, wherein the accession data are independent of personal data of any user of the respective account(s).
11. The method of claim 1, wherein the network is realized as a computer network, such as the Internet.
12. The method of claim 1, wherein the accounts comprise at least one amount datum, each amount datum being associated with a respective requesting party.
13. The method of claim 12, wherein the accotmts are used for payments with respect to amount data referring to the same requesting party only.
14. A server means for performing the method of claim 1, being accessible over a pubHc network and having a data base holding data related to accounts, each of said accounts being accessible by accession data and having an amount datum representing an account value, the accession data comprising an identification code which is unique with respect to the accounts estabHshed on the server means, the data held in said data base including the accession data, the server means being 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, and the server means being adapted to perform payment transactions 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 tiansaction data comprising the accession data of the accounts involved in the transaction as well as a payable amount.
15. The server means of claim 14, further 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.
16. The server means of claim 14, further adapted to transact payments independent of an associated return service.
17. The server means of claim 14, being accessible over a computer network, such as the Internet.
18. The server means of claim 14, further adapted to transact payments between accounts held in said data base free of charges with respect to the accounts involved.
19. The server means of claim 14, further adapted to perform a check with a payment transaction, in that the tiansaction 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.
20. The server means of claim 14, wherein the accounts comprise at least one amount datum, each amount datum being associated with a respective requesting party.
21. The server means of claim 20, adapted to transact payments between accounts with respect to amount data referring to the same requesting party only.
PCT/EP2000/009723 2000-10-05 2000-10-05 Network oriented payment service WO2002029740A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2000279140A AU2000279140A1 (en) 2000-10-05 2000-10-05 Network oriented payment service
PCT/EP2000/009723 WO2002029740A1 (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 (en) 2000-10-05 2000-10-05 Network oriented payment service

Publications (1)

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

Family

ID=8164114

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2000/009723 WO2002029740A1 (en) 2000-10-05 2000-10-05 Network oriented payment service

Country Status (2)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010000884A1 (en) * 2008-07-01 2010-01-07 Visiers Sanz, Irache Method for making secure payment and collection transactions by means of terminals with a data connection

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 (en) * 1998-11-02 2000-05-11 Hsx, Inc. Computer-implemented securities trading system with virtual currency and virtual specialist

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 (en) * 1998-11-02 2000-05-11 Hsx, Inc. Computer-implemented securities trading system with virtual currency and virtual specialist

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010000884A1 (en) * 2008-07-01 2010-01-07 Visiers Sanz, Irache Method for making secure payment and collection transactions by means of terminals with a data connection

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
US6456984B1 (en) Method and system for providing temporary credit authorizations
US7130828B2 (en) Debit purchasing of stored value card for use by and/or delivery to others
US20030004828A1 (en) Prepaid card authorization and security system
US8893963B2 (en) Issuing a value-bearing card associated with only non-personally identifying information
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 (en) Electronic payment system utilizing intermediary account
US7445150B2 (en) Pre-paid credit card
US20030163423A1 (en) Method and apparatus for secure electronic payment
US20080270245A1 (en) System For Processing Stored Value Instrument
AU3108199A (en) A method for using a telephone calling card for business transactions
WO1997019414A1 (en) Computer network value payment system
JP2005519402A (en) Payment card and method
GB2352861A (en) Payment transaction system
WO2007029123A2 (en) System and method for processing transactions
AU774122B2 (en) E commerce system
WO2002029740A1 (en) Network oriented payment service
KR20020006191A (en) A virtual bank management system via internet communication
CA2311190A1 (en) System and method for processing certificates
GB2412777A (en) Electronic voucher system using mobile phones
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