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 accessi- ble over a public network, such as the well-known Internet, and a server means for perform- ing 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 render- ing 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 trustworthiness 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 com- puter 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 re- quest, 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 accounts 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. Fur- thermore, 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 cov- ered 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 earlier 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 verifiable 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 net- work, 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 T1 as sold with a given initial value. The ticket T1 shows several data items TIM, TID, BID, some further items present on the ticket T1 are hidden by a cover COV; when the ticket is used the first time it is"opened"by removing the cover COV in order to reveal further ticket specifications TCO, BCO. In the preferred embodiment, the cover COV 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 COV 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 T1 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 lan- guage.

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.&lt;/form&gt; This HTML code accepts an E-mail address with the variable email adress 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. exe"> Emailadress: <input type="text"name="email adress"> <input type="submit"value="Get new ticket">

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 sample ticket number, amount, customer ticket number and code number, and hands the total data to a transaction application 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 refer- ence 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 application in connection residing on the transaction server may be used in connection with an HTML code like the following 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"&gt; Codenumber <input type="text"name="codenr"&gt; 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"&gt; valid until <input type="text"name="validu"&gt; <input type="submit"value="Charge"&gt; </form> From this HTML dialog, the charge-up application 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 (Code number) is required; this can also be omitted. Suitably, also the charge-up transactions are stored in the data base, re- cording the ticket number and the account data (number, name, etc.) of the credit or bank account, respectively, as well 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 collect one or more remainders to a single account value.

In 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 accu- mulate 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 valid for all 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 allow payments to be done in return for services provided, but the amount thus collected can only be transacted to one or a few other accounts which have been specified beforehand. A further possibility is to allow transactions or certain types of transactions only if the transacted amount and/or the ac- count value of the ticket is above (or below) a respective limit associated with the ticket account, possibly in 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 clients it may be desirable to secure against users which might block off other clients with large requests, and only transactions with very small amounts are allowed 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 call to a service number of the server provider; only after this call 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 will 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 sum-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 well.

In a variant, the issuing process is started by a request from an issuer ISS to the ticket system provider for a number of tickets initially 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 actually initialized. The discount can be equal to or smaller 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 compa- nies operating with the Internet or other data networks, and in particular for so-called E-commerce companies. The invention offers a simple and fast method to effect payment for services presented and/or delivered over Internet. Issuing will be especially 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.

All 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 well 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 collected from the ticket account system. The tickets thus produced can now be sold in 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 third party, even if the issuer himself does not provide any services, thus obtaining an additional income from these advertisements.

In a variant of the ticket account system, the tickets can be bound closer to the respective issuer. In this variant, a ticket issued by a specific issuer is, the first 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.

In this variant, a ticket can still be used for payments with other merchants, which are not related to the issuer. In 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 ac- count 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 supplied 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 third year, all 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 facilitates transactions also between ticket holders which are both primarily acting as customers or merchants.

To facilitate 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 book- keeping purposes, such as a reference to the respective issuing series. For the holder of the ticket, this list of amounts is usually not disclosed unless the ticket owner explicitly 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 small payable amounts (so-called micro payments); -fast propagation due to issuing by various organizations; -easy transferability 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 virtue of the reduced handling overhead costs on the side of the merchants; re-usability of a ticket used for effecting payments in terms of effecting and/or accepting payments, also between consumers/customers ; backtracking of transactions.  

We claim: 1. A method for managing accounts on a server means accessible over a public network, said server means being accessible over a public 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 identifi- cation 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, 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 transaction data comprising the accession data of the accounts involved in the transaction as well as a payable amount, the method comprising 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.

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 first 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 earlier than the time of actual generation of the respective account, the activation time specifying the earliest 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 accounts 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 public 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 established 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 transaction 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 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.

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.