GB2404483A

GB2404483A - Payment for good or services from a computer network

Info

Publication number: GB2404483A
Application number: GB0315127A
Authority: GB
Inventors: Jared Bernstein
Original assignee: PBC INTERNAT Ltd
Current assignee: PBC INTERNAT Ltd
Priority date: 2003-06-20
Filing date: 2003-06-27
Publication date: 2005-02-02
Also published as: GB2404482A; GB0314452D0; GB0315127D0

Abstract

In conducting transactions using a distributed computer network 10, such as the Internet, a user 100 buys a payment identifier (e.g. a PIN on a scratch card) and uses this to pay for an online purchase. The identifiers are produced by a payment administrator which includes a database 300 associating an account with each identifier. The payment identifiers may include restrictions so that particular identifiers (e.g. those for use by children) will only be able to access selected online vendors 200. If an identifier is used to access a streaming service which charges by the amount of time the service is connected or the quantity of information supplied, the payment processing apparatus will periodically check the funds remaining in the account and deduct value from it.

Description

PAYMENT SYSTEM AND METHOD

The present invention relates to a payment system and method, particularly a payment system and method for buying goods, services and data products over a network such as the Internet.

With the rapid growth of the Internet and its development as a commercial hub, much focus has been placed on improving the manner in which Internet users or consumers purchase goods, services and data products from online merchants or service providers.

The most common form of payment is with a credit or debit card. The consumer sends their card account details to the provider across the Internet, and the provider processes the payment in a known manner. Many Internet users are wary of using a credit card to carry out a transaction over the Internet, however, for fear that the transmission will be intercepted, their account details stolen and their credit card used illegitimately. Although encryption and secure data transmission protocols may be used to alleviate these problems, lack of consumer confidence is still an important factor. Another, sometimes problematic issue with credit card payments is that they lack anonymity. Internet users may wish to purchase risque material from a provider without giving any personal information. This is not possible with current credit card payment methods. Furthermore, not all consumers have a credit card, either because they are underage or do not have a sufficiently good credit rating.

Some providers offer consumers a subscription to a service. This could, for example, be an Internet service where the consumer is allowed access to the provider's website provided that a fee is paid monthly 3s or at other regular intervals. However, such subscription services take no account of the frequency with which the user logs onto the website. This is disadvantageous to users who only wish to use a service from time to time. Such users are either forced to pay each month for a service that they rarely use, or otherwise initiate the subscription process each time they require the service, then cancel the subscription before the next payment is due. Clearly, neither solution is satisfactory.

s With such subscription offers, the user is often given a password or account number which they can use to access the provider's website. However, the password or account number can only be used with the particular services offered by that provider such that it would be necessary for a user to open many such accounts in order to use services offered by different providers.

To alleviate this problem, some subscription services are available which allow a user to access a range of services offered by different providers signed up to the joint system. The user is again provided with a password or account number, and those providers signed up to the system will recognise that password and allow access to the user. However, not all of the services available to a user having such an account may be suitable for that user. For example, one provider may offer services suitable for children, while another might offer services suitable only for adults. A parent wishing to allow their children 2s access to one website might be unwilling to open an account with a joint system for fear that their children might also be able to access unsuitable material.

Accordingly, there is a need for an improved payment system and method, especially on the Internet, which permits a user to purchase goods, services and data products in a secure and preferably anonymous manner. There is also a need for an improved subscription service in which payment is related to the use made of the service being subscribed to. A further need is for a joint system through which many providers can offer services to users, but with a level of control built into the system such that users, or parents of a child user, can select the services which can be accessed. - 3 -

Preferred embodiments of the present invention will now be described by way of an example and with reference to the accompanying drawings, in which: s Fig 1 shows a schematic representation of interactions over a network between a user, a provider server, and a central database server; Fig 2 shows an example PIN; Fig 3 shows a data record contained on the central database server for one PIN; Fig 4 shows a schematic representation of a PIN distribution network, Fig 5 shows a schematic representation of transaction software installed on a provider server; Is Fig 6 shows steps taken by the provider server and the central database server when communicating with each other in response to a request for service received from a user at the provider server; Fig 7 shows the PIN verification steps of Fig 6 in more detail; Fig 8 shows the credit amount reduction steps of Fig 6 in more detail; Overview 2s Briefly, and with reference to Fig 1, embodiments of the present invention permit a user 100 to make purchases over a network 10 such as the Internet without divulging credit card details or any personal information. Instead, the user 100 simply supplies a service provider server 200 with an identification number, hereafter referred to as a PIN. PINS are generated and stored on a central database which is controlled by a central database server 300 belonging 3s to an administrator of the payment system. Each PIN has a credit amount associated with it. When the user sends 12 a request for service and a PIN to the provider server 200, the provider server 200 passes 14 the information to the central database server 300 over the network 10 where the validity of the PIN and - 4 - the credit amount associated with that PIN are checked. The central database server 300 sends 16 the results of these checks to the provider server 200 which, if the results are positive, provides 18 the s requested service to the user 100. As can be seen from Fig 1, the communication between the provider server and the central database server 300 is invisible from the perspective of the user 100.

While the user 100 is making use of the service, the central database server 300 reduces the credit amount associated with the user's PIN depending upon the amount of time that the user has been "logged in", and upon the cost of the service. If the user 100 stops using the service, the provider server 200 sends an appropriate message to the central database server 300, which makes a record of the new credit amount associated with the PIN. The user 100 can continue using the service, or a different service, at a later date. If the credit amount associated with the PIN is reduced to zero, the central database server 300 sends an appropriate message to the provider server 200, which suspends the service being provided to the user 100, or alternatively requests that the user 100 enter a different PIN number if they wish to continue.

Networks with which embodiments of the present invention may be used include, without limitation, the Internet or a local area network, mobile phone networks including third generation mobile phones and other wireless and wireless fidelity (wi-fi) networks, and digital television networks.

PIN Generation With reference to Fig 2, PINs 50 are generated in batches with numbers being allocated according to a computerised numbering method. Each PIN 50 is preferably formed as a twenty character alphanumeric string (using letters A to Z and digits O to 9) of which eight characters represent a batch number 52 and the remaining twelve characters represent an encrypted - 5 - identifier 54 within that batch. This gives the possibility of producing 368 batches with 3612 encrypted identifiers per batch. By using a longer string, or by including lower case letters and s additional characters, this pool of available PINs can be increased substantially. The length of the PIN may also be adjusted to improve security and to provide for different services within different countries, or to take account of different hardware and software configurations. Similarly security features and variations in functionality may be achieved by using different character sets for the PIN. For example, a PIN constructed using a hexadecimal character set could be used in hex based ATM keypad machines.

Different character sets may also be used to make the PIN language independent.

The encrypted identifier 54 is obtained by encrypting a non-encrypted identifier 56. As indicated in Fig 3, the non-encrypted identifier 56 preferably includes one or more of the following pieces of data: ID number 58, date of creation 60, PIN type 62, currency 64 and initial credit amount 66. The ID number 58 identifies each PIN 50 within the batch. The date of creation 60 indicates the date of creation in 2s a suitable format such as ddmmyyyy format. The PIN type 62 may be used to associate the PIN 50 with particular services such that the PIN 50 may be used with any available service or with only a limited range of services, as desired. The currency 64 indicates the currency of the country in which the PIN is to be distributed. However, as discussed below, the distributed PIN 50 may be used to pay for services independent of currency. The initial credit amount 66 indicates the initial credit amount associated with 3s the PIN 50. This value may be ú5, ú10, ú20 or any other suitable value in any suitable currency. The credit amount value may also be expressed in terms of time, such as the length of time that the user may access a particular service, for example.

Alternatively, the credit amount may be expressed in - 6 - terms of currency independent accredits''. Other information may be included in the non-encrypted identifier 56, if required.

The encryption of the non-encrypted identifier 56 s to obtain the encrypted identifier 54 is carried out using a hash function. A hash function is an algorithm which can be applied to a string to encrypt the string. The original string can be retrieved only by using a private key 68. As indicated in Fig 3, each batch number 52 is associated with the particular private key 68 which is required to decrypt the encrypted identifier 54.

After generating a batch of PINs, a record 70 is made on the central database. Each record 70 includes the batch number 52, non-encrypted identifier 56, an activation flag 72, a bundle number 74, and the current credit amount 76. Preferably, the PINs 50 are initially recorded as inactive using the activation flag 72. Each PIN is not activated until the distribution stage and, as discussed in more detail below, a distributor communicates the bundle number 74 to the administrator to have the PINs 50 activated.

This is necessary in order to protect the PINs 50 against theft occurring between generation and 2s distribution. The current credit amount 76 is initially set to the same value as the initial credit amount 66 stored as part of the non- encrypted identifier 56, but is reduced as the PIN is used by a user 100 to pay for goods and services. Preferably, the credit amount 76 may not be topped up or regenerated but is instead a single use, pre-paid amount. However, in some embodiments of the invention, a PIN can take a negative or positive value and a user or other party may be permitted to increase or restore 3s the credit amount 76 associated with a particular PIN 50, in which case the record 70 in the central database is updated by the administrator. The credit amount may also be transferred between PINs, with suitable currency, time, or credit conversions being performed where required. The credit amount can - 7 - preferably assume the properties of currency, time or credit dependent on the service with which the PIN is being used. This permits a PIN to be used with a variety of services without any modification. As a PIN s is used, the record 70 is expanded to include comprehensive usage reports and transaction logs which may be accessed as required. Each record 70 may contain additional information, if required. For example, the PIN may be set to expire at a certain time, in which case a specific date of expiry or a length of time following the date of creation 60 may be stored in the record 70.

The private key 68 associated with the batch number 52 is stored securely on the central database, but can be retrieved by the administrator when required by performing a database search.

Generation of PINs is carried out with suitable computer software, which preferably has a user web browser based user interface to improve ease of use.

PIN Distribution With reference to Fig 4, the PINs 50 are distributed to users 100 once they have been generated. In one preferred embodiment, a list of PINS is communicated to a card printer 400 from the central database server 300. Each PIN 50 is printed onto a scratch card having a panel which can be scratched off by the user to reveal the PIN 50. The card printer delivers the printed cards to distributors 500 such as retail outlets in bundles having an associated bundle number 74. On receiving a bundle of cards, the distributor 500 communicates the bundle number 74 to the administrator by email or by some other communication method. The administrator then activates the associated PINs 50 in the central database server 300 by setting the activation flag 72 to the appropriate value. As a further precaution against theft, the card printer 400 may inform the administrator of the identity of the distributor 500 to which a particular bundle of cards was sent. This could be achieved, for example, by associating each distributor 500 with an identifier and storing these identifiers on the central database. The card printer s 400 can then communicate the distributor identifier to the administrator on dispatching a bundle of cards.

When seeking to activate a bundle, the distributor 500 preferably sends an email to the administrator including their identifier. This can be checked against the list of distributor identifiers and the expected distributor identifier. If an invalid or unexpected distributor attempts to activate a bundle of cards, then they will not be activated by the administrator. Once activated, the distributor 500 puts the cards on sale to the public.

The PINs 50 need not be printed onto cards, but may be distributed in other ways. PINs 50 can be distributed electronically by email, over the Internet or some other network, by telephone, by text message to a mobile phone or by any other suitable means. PINs may also be distributed by post. For these alternative forms of communication, the PINs 50 need not be sent to a card printer 400, but may be communicated directly to the distributor 500.

2s A user 100 wishing to purchase a PIN 50 may do so by purchasing a card from a distributor 500, or by requesting that the distributor send then a PIN 50 by some other means. The user 100 pays the distributor for the PIN 50 by any suitable means. As indicated in Fig 4, the central database server 300 remains invisible from the perspective of the user 100.

Distributors 500 may pay the administrator for bundles of received cards/PINs at an agreed time after activation, paying an amount for the cards/PINs which 3s is less than the amount which the retailers will receive through sale of the cards. Alternatively, the distributors 500 may pay the administrator as cards/PINs are sold to the public. It is envisaged that the administrator will make a financial return by taking a mark-up or percentage of all payments made - 9 - using a payment system embodying the present invention.

Provider Sign Up s For a provider to be able to provide services to a user 100 and receive payment, the provider must initiate a relationship with the administrator of the payment system. A provider is assigned a provider identifier which is entered into the central database together with information such as name, address, currency information and so forth, to permit the administrator to direct payment to the provider for services that the provider has given to users. Records are also kept in the central database of the services which the provider offers, the cost of those services, and service identifiers used to identify those services to the central database server 300. This ensures that the correct rates are used when depleting the credit amount associated with a PIN 50.

Furthermore, individual providers may prefer that only certain PIN types 62 be used to pay for some or all of the offered services. For example, a provider may have a range of data products available, some of which are suitable only for an adult audience. The PIN type 62 may include an indication of whether it is a "red" or "adult" PIN, or a "green" or "family" PIN.

With suitable association of the PIN type 62 with the service identifier, restrictions can be placed on the services which may be purchased using a particular PIN. As another example, some providers might prefer that particular PINs be available only for use with the service that they offer, rather than allowing a PIN to be used over a range of services offered by different. In this situation, the PIN type 62 might indicate that the PIN may only be used with services offered by a specific provider, or with a small selection of providers. Again, with suitable association of the PIN type 62 with the provider or providers, suitable restrictions can be put in place. -

The sign up information described above may be modified at any time, and the service identifiers in particular may be modified as the services offered by the provider change.

s As indicated in Fig 5, a provider server 200 may already have suitable software installed to handle payments from users by credit card 210 or by other methods 220. Preferably, PIN transaction software 230 for carrying out transactions embodying the present invention integrates with the software 210,220 already in place on the provider server 200. The administrator of the payment system may arrange and supervise the installation of the PIN transaction software 230 to ensure correct integration. Of course, a provider may prefer to offer only a PIN payment option.

The transaction software 230 preferably includes three modules: a transaction module, an access control module and an integration module. The access control module is used to protect premium content (ie content which attracts a charge) on the provider server or a remote server connected to the provider server. The transaction module keeps track of services requested by users. The integration module acts as a communicator between the access control module and the 2s transaction module and further translates between the protocols used by the provider server 200 and the central database server 300.

User-Provider Interaction From the perspective of a user 100, purchases using PINs are simple and secure. For embodiments of the invention used over the Internet, a user having a PC or other suitable apparatus may access a website of 3s a provider and decide that they wish to subscribe to a service offered on the website, or alternatively decide to purchase goods or data products. If the PIN transaction software 230 has been integrated with other transaction software 210,220, the user may then be redirected to a payment options web page, for example, where they will be given the option of different payment methods such as credit card and "Pay by PIN". If the user 100 selects "Pay by PIN", then they may be redirected to a new web page which S displays a form into which the user is able to enter one or more PINs. A user may wish to enter several PINs if they are aware that the credit amount associated with one PIN iS almost depleted, if the service offered by the provider is expensive, or if they wish to use the service for an extended period of time. Once the required PINS have been entered, the user may send the PIN information to the provider server 200 by selecting a confirm option on the web

page, for example.

From the perspective of the user 100, there will be a brief pause if the "Pay by PIN" option is confirmed while the provider server 200 communicates with the central database server 300 to verify that an acceptable PIN has been entered (see below). The user 100 will then be presented with a suitable message.

The message may indicate that a PIN 50 entered by the user 100 is invalid or has no associated credit, or that the PIN type 62 is not suitable for use with the requested service. Alternatively, the user 100 may 2s receive a welcome message confirming that the PIN 50 has been accepted. The welcome message may further indicate the credit amount associated with the PIN or PINS, an amount of time that the user may make use of the service, and/or a quantity of data that the user may download before their credit is depleted.

As an alternative, the user may enter PIN information on first accessing a home page of the provider's website, or the provider may obtain PIN information from a cookie stored on the user's 3s computer. In this way, the user can browse a website which contains a mixture of premium and non-premium content, accessing and paying for premium content without the need to enter a PIN each time. The access control module of the transaction software 230 controls the users access to premium content. 12

Once "logged in", the user 100 can proceed to use the service offered by the provider. A unique identifier is created for each request for service and is preferably stored as a cookie on the user's s computer and stored in memory on the provider server.

The access control module calls the identifier when the user attempts to access premium content. If no identifier is found, the user is requested to enter their PIN and a new unique identifier is created. The access control module calls this new unique identifier before permitting the user access to the requested service. The unique identifier preferably expires after use.

As the user uses the service, the provider server 200 and central database server 300 communicate with each other invisibly from the perspective of the user to keep track of the credit amount associated with the user's PIN. If, while the user is using the service, the credit amount associated with the previously entered PIN or PINS becomes depleted, the user is preferably presented with a suitable warning message.

The warning message may request that the user supply a new PIN or may state that further access to the service will no longer be provided.

2s If the user finishes using the service, the user may actively "log out" from the website, by pressing a "log out" button provided on the web page they are viewing, for example. At that time, the user may receive a goodbye message informing them of the credit amount remaining on the previously entered PIN or PINs. Alternatively, the provider may monitor the activities of the user to determine when the user leaves the provider's website, or otherwise stops using the service. The user is then able to simply 3s stop using the service rather than actively logging out, but can be confident that the credit amount associated with the previously entered PIN or PINs will not be depleted further.

Several different users may use the same PIN at the same time to pay for different services, or the - 13 same services. If the PIN becomes depleted, then all users using that PIN Will be prevented from accessing the service further. However, a user may prefer that only they be able to use a particular PIN. In this situation, the user can combine the PIN with a password such that the PIN will only be accepted if the correct password is also entered by the user. The password may be stored on the provider server if the user only wishes the password to be used with one particular provider, or may be stored on the central database if the user wishes the password to be usable with different providers.

Provider-Administrator Interaction With reference to Figs 6 to 8 the provider server and central database server 300 open a communication channel over the network 10 each time a user 100 submits a request for service to the provider server.

Figure 6 shows an outline of the steps involved in verifying a PIN 50 entered by a user 100 and depleting the credit amount associated with the PIN 50 while the user 100 makes use of a service provided by 2s the provider. The provider server 200 receives a request for service and a PIN from the user 100 at step 602. The request may be sent when the user 100 clicks a confirm button on a web page of a website of the provider as discussed above, for example.

On receiving the request, the provider server 200 sends transaction details to the central database server 300 at step 604. The transaction details preferably include the PIN 50, the provider identifier to identify the provider to the central database server 300, the service identifier to identify the service requested by the user to the central database server 300, the network address of the provider server and any other information pertinent to the transaction. The transaction details message is created by the PIN transaction software 230 installed - 14 onto the provider server 200. The message may be created in any suitable format. Preferably, however, the message is generated as an Extensible Markup Language (XML) message.

The central database server 300 receives the transaction details at step 606 and verifies that all of the details are correct and that the PIN is valid in step 608.

The verification step 608 is shown in more detail in Fig 7. At step 608a the central database server 300 checks the provider identifier against values stored in the central database. If the provider identifier matches with a known provider, the central database server 300 uses the batch number 52 part of the PIN 50 in order to search the central database for the associated private key 68 at step 608b. If the private key 68 is found, the key is used at step 608c to decrypt the encrypted identifier 54 of the PIN 50 to obtain the non-encrypted identifier 56. If this decryption operation is successful, the central database server 300 searches the central database at step 608d for the non-encrypted identifier 56. If the non-encrypted identifier 56 is found, the central database server 300 checks the activation flag 72 of 2s the record 70 associated with that identifier at step 608e to see if the PIN has been activated. The PIN type 62 is checked at step 608f to ensure that the PIN is not being used to pay for a service not suitable for that PIN type. The current credit amount 76 is checked in step 608g to ensure that the credit amount associated with the PIN 50 is greater than zero.

If any one of the verification steps 608 is not successfully completed, the central database server 300 sends a suitable error message to the provider 3s server 200 at step 638. Preferably the error message indicates to the provider server the type of error that has occurred. More preferably, the error message is an integer value indicating which of a verification steps has been unsuccessful. The provider server 200 receives the error message at step 640 and preferably - 15 - informs the user of the error at stage 650. Depending upon the nature of the error, the provider server may attempt to send the transaction details to the central database server 300 again, or may prompt the user 100 s to enter a different PIN.

If each of the verification steps 608 is successfully completed, then the central database server 300 sends a verification message to the provider server 200 at step 610. On receiving the verification message at step 612, the provider server provides the requested service to the user at step 614. The provider server 200 monitors the actions of the user 100, in particular checking that the user is "logged in" at step 616. While the user is logged in, the provider server sends a debit request message to the central database server 300 at intervals (step 618). These intervals are preferably regular intervals of, for example, one minute or five minutes.

Preferably, the intervals between debit requests are not less than 30 seconds or the provider server and central database server may become overwhelmed with data. The intervals are preferably not longer than one hour or the credit amount may become depleted. The central database server 300 receives the 2s debit request message at

step 620. The debit request message contains information which allows the central database server 300 to reduce the credit amount 76 associated with the PIN being used in the transaction by the appropriate amount at step 622. Furthermore, the central database server 300 retrieves records stored on the central database of the cost of the previously identified service being supplied to the user. For example, the user may be using a service in which they can browse the provider's website at a cost 3s of [5 per hour. This cost information is stored on the central database. The provider server may keep a record the length of time that a user has been using a service, preferably using whole seconds as units of time, although other units of time may be suitable for different services. When sending a debit request, the _ 16 debit request message may indicate expressly the length of time that the user has been using the service. Alternatively, a record of the time that the user logged in may be stored on the central database.

S The central database server 300 can therefore calculate the length of time that the user has been browsing the website. Preferably the central database server 300 takes account of the time taken for the debit request message to be sent to the central database server 300 such that the user does not pay for time they have not used. Using the available cost per time information and the time information, the central database server 300 calculates a cost value and debits this value from the credit amount 76 associated with the PIN being used in the transaction.

As an alternative, the cost information stored on the central database may relate to a cost per number of kilobytes of data downloaded by the user. The debit request message may include an indication of the number of kilobytes of data actually downloaded by the user. The central database server 300 can therefore calculate the cost incurred and debit this cost from the credit amount 76 associated with the PIN 50 being used in the transaction.

2s As another alternative, the cost information may indicate the cost of downloading a single data product, such as a picture file in a suitable format such as JPEG or GIF, or a music file in a suitable format such as WAV or MP3. The debit request information may include an indication of the number of data products that have been downloaded by the user.

Again, the central database server 300 can therefore calculate the cost incurred and debit this cost from the credit amount 76 associated with the PIN 50 being 3s used in the transaction.

The credit amount 76 associated with a PIN and the cost information associated with a service offered by a provider are preferably stored in terms of a particular currency. Preferably, the central database further includes up to date information concerning - 17 currency exchange rates and the central database server 300 can use this information to calculate the correct cost incurred by a user and to debit this cost from the credit amount 76 associated with the PIN s being used in the transaction. A user can therefore use their PIN to purchase goods, services and data products from a provider without considering currency Issues.

Once the credit amount 76 has been reduced by the appropriate value, the central database server 300 checks that the credit amount 76 is greater than zero.

The credit amount checking step 652 is shown in Fig 8.

If the checked credit amount 76 is zero (or less than zero), the central database server 300 sends a negative confirmatory message to the provider server at step 624b. The provider server 200 receives the negative message at step 626b and stops providing the requested service to the user at step 628. The provider server 200 may also prompt the user 100 to enter a new PIN 50 if the user wishes to continue making use of the service.

If the credit amount 76 is greater than zero, then a positive confirmatory message is sent to the provider server 200 at step 624a. The provider server 2s 200 receives the positive message at step 626a and continues to provide the requested service to the user, thereby returning to step 614. Steps 614 to 626 are repeated, with the provider server 200 sending debit requests to the central database server 300 at intervals, until the credit amount 76 associated with the PIN 50 being used in the transaction is reduced to zero or until the user "logs out". It should be noted that these individual steps need not be evaluated in sequence, but may be controlled in an event based 3s system.

The user might "log out" by sending a specific log out message to the provider server 200 (for example by clicking a button on a web page) or simply by closing the session (for example by closing the web browser program on their PC). The provider server 200 - 18 - recognises when a user logs out and proceeds to step 630 where a suitable message is sent to the central database server 300. The central database server 300 receives the logged out message at step 632 and, at step 634, reduces the credit amount 76 associated with the PIN 50 to a final level, effectively closing the record in the central database to prevent further depletion of the credit amount such that the user can make use of the PIN at a later time.

Payment to Provider The central database server 300 maintains a record in the central database of all transactions that occur. The details for each provider are held in a relational database, of which one table holds details of the transactions which have occurred. This table is passed to a bank at intervals such as once a month. The dataflow between the central database server 300 and the bank preferably takes place across a secure virtual private network ( VPN) . The bank credits the provider with the total value of all of the transactions. The provider will also be billed for an agreed percentage of the total value, which will be the payment to the administrator running the central database server.

Alternative Provider-Administrator Interaction In the system described above, the central database server 300 manages all of the calculations and record keeping operations for each PIN distributed to users. However, in some embodiments of the invention, these operations may be performed by individual providers. In such embodiments, the central database server 300 continues to control the generation, distribution and activation of PINs.

However, once a bundle of PINs has been activated, the central database server 300 downloads the PIN information to a provider server 200 where it is - 19 - stored in a suitable provider database. The PIN transaction software 230 installed on the provider server 200 handles the verification and credit amount depletion steps shown in Figs 6 to 8 and the provider server 200 need not communicate with the central database server 300. Payment to the provider may be arranged simultaneously with the download of activated PINs to the provider server 200, with the administrator retaining a proportion of the money taken in selling PINs to users. Alternatively, the administrator may control only the generation of PINs, and the provider then organises distribution and sale of PINS to users. In this arrangement, the provider would arrange for a suitable PIN generation fee to be paid to the administrator.

Examples of Services

Embodiments of the present invention are particularly suitable for use with streaming services where data is delivered to a user 100 by a provider over a broadband connection. Such services are in continued development and offer television of video services to users over the Internet. A user wishing to make use of a streaming service will be able to purchase a PIN as part of a pre-payment system and use that PIN to access the available streaming services.

As the service is used, the provider server 200 and central database server 300 communicate with each other transparently from the perspective of the user to track the cost of using the service against the pre-paid PIN. Once the user's credit has been depleted, the streaming data flow is interrupted.

Other uses of the invention may be in connection with Internet enabled mobile phones. In view of the present limitations of many mobile phones, much of the Internet content that can be accessed is static rather than streaming: pages from newspapers, or sports results, for example. Accordingly, rather than interrupting a data stream once the user's credit is - 20 - depleted, the provider can instead refrain from sending further data to the user until a new PIN which does not have a depleted credit is entered.

s Network and Database Considerations In preferred embodiments of the present invention, the user 100, the provider server 200 and the central database server 300 communicate via the Internet. However, the Internet is not the only network which may be employed when implementing the present invention. Also, Fig 1 indicates that the user 100, provider server 200 and central database server 300 all communicate via the same network 10. This need not always be the case. For example, the user may access an Internet website of the provider, whereas the provider server 200 and the central database server 300 may communicate via a local area network, a wide area network, a wireless network or any other suitable network. Such alternative networks may be particularly desirable if they offer greater security than the Internet. Communication between the provider server 200 and the central database server 300 is preferably carried out using a secure HTTPS protocol 2s over a TCP/IP network.

For embodiments of the invention implemented over the Internet it is preferred that a secure and scalable hardware and software infrastructure is used.

It is preferred that the central database server 300 is configured to support webfarm configurations. In a webfarm two or more servers are used to host the same website. Multiple servers become necessary when a website attracts a large number of users. HTTP requests are routed to each server in the farm in a 3s round-robin fashion to distribute the load and to allow the payment processing system to handle more requests.

Since the central database provides a store of PINs and related information, scaling should be relatively simple to achieve. The use of clustering - 21 technology supports this. In broad terms, a 'cluster' is a group of independent systems working together in a single circle. A user machine such as a PC interacts with a cluster of independent systems as though they were all part of a single server. Cluster configurations are used to address both availability and scalability. In a single system when a cluster fails then the software responds by dispersing the work from the failed system to the remaining systems in the cluster. When the overall load on the systems exceeds the capability of the systems then additional systems may be added to the cluster.

Preferably, the central database server 300 also includes a firewall. The firewall is a combination of hardware and software that provides a security system to prevent unauthorized access from outside to an internal network or intranet. The firewall prevents direct communication between the network and external computers by routing communication through a proxy server outside of the network. The proxy server determines whether it is safe to let the file pass through to the network. The configuration of the method will typically require two ports open in the firewall; port 80 to support HTTP traffic and port 443 to support HTTPS traffic.

It is preferred that Windows 2000 is used on the central database server 300 since Windows 2000 complies with C2 level security requirements. The central database server 300 preferably uses Internet Information Server 5 (IIS5) in order to provide anonymity for purchasers. When a program or process (like IIS5) is run on behalf of the user, it is said to be running under the security context of the user.

The purpose of the security context is to give the process running on behalf of the user no more access to files and resources than users would have if they were running a process locally. When IIS runs on behalf of a user, it is said to be impersonating that user. IIS is designed to handle requests made via the Worldwide Web as an automated service. To do this, IIS - 22 - needs to run under a valid user security context. The system of the present invention will use anonymous requests allowing any purchaser access to the payment application under the security context of the anonymous user account on the server.

The central database server 300 preferably also runs Component Services. This will support and manage transactions through use of COM (Component Object Model) and increases the server performance.

The central database will typically be founded on SQL2000, which is a relational database with full transactional and logging support. SQL2000 is a high performance scalable enterprise database solution.

SQL2000 interacts directly with Windows and provides integrated security implementing two levels of security in that the Windows account must have permission to access the SQL database and that the Windows account must be matched to an SQL user account within the database which itself has table-defined permissions.

Claims

Claims 1. A method of conducting transactions using a distributed computer

network such as the Internet, the method comprising: a payment administrator generating and issuing a plurality of debit identifiers and storing in a database of a payment processing apparatus records of the generated debit identifiers each associated with an individual stored value account; a purchaser of goods and/or services using client computer apparatus to access via a telecommunications network a vendor computer apparatus which hosts a publicly accessible site of a vendor of goods and/or services and the purchaser submitting electronically via the telecommunications network an order for goods and /or services to the vendor computer apparatus along with an issued debit identifier and authorization to debit the value of the ordered goods and/or services from the stored value account associated with the debit identifier; and the vendor computer apparatus and the payment processing apparatus communicating electronically in order that the information stored in the database of the payment processing apparatus can be used to validate the submitted debit identifier and in order that the value of the ordered goods and/or services is deducted from the stored value account associated with the submitted identifier, the vendor computer apparatus further processing the order if the submitted identifier is validated and the associated stored value account has sufficient funds or the vendor computer apparatus rejecting the order if the submitted identifier if the submitted identifier is not validated or if the associated stored value account has insufficient funds; wherein: the payment administrator issues debit identifiers for use in purchase of goods and/or services from a plurality of vendors and stores in the database of the payment processing apparatus restrictions on use of the some of the issued identifiers, restricting use of the identifiers to purchase of goods and/of services of a specified vendor or a specified set of vendors so that subsequently the identifiers can only be used by purchasers in purchasing goods/services from the specified vendor(s).
2. A method as claimed in claim 1 wherein the payment processing apparatus for each validated and approved purchase records a credit in favour of the relevant vendor and the payment processing apparatus instructs payment into a nominated bank account of the vendor funds equivalent to a stored credit or credits for the vendor.
3. A method as claimed in claim 2 wherein the payments to the nominated bank account of the vendor occur periodically.
4. A method as claimed in claim 1 wherein the vendor computer apparatus downloads from the payment processing apparatus the stored details of the generated debit identifiers and associated stored value accounts for the debit identifiers which restrict purchase of goods and/or services to those goods and/or services supplied by the vendor and the vendor computer apparatus validates submitted identifiers using the downloaded information.
5. A method as claimed in any one of the preceding claims wherein the debit identifiers which are restricted to purchase of goods and/or services from a specified vendor or specified vendors are supplied by the payment administrator to the specified vendor(s) for onward distribution to purchasers.
6. A method as claimed in any one of the preceding claims wherein the payment administrator issues some debit identifiers which can be used in purchasing goods and/or services from any vendor recorded by the payment processing means and other debit identifiers which restrict the purchases to those made from the specified vendor(s).
7. A method of conducting transactions using a distributed computer network such as the Internet, the method comprising: a payment administrator generating and issuing a plurality of debit identifiers and storing in a database of a payment processing apparatus records of the generated debit identifiers each associated with an individual stored value account; a purchaser of goods and/or services using client computer apparatus to access via a telecommunications network a vendor computer apparatus which hosts a publicly accessible site of a vendor of a streaming service and the purchaser submits electronically via the telecommunications network an order for the streaming service to the vendor computer apparatus along with an issued debit identifier and authorization to debit the cost of the streaming service from the stored value account associated with the debit identifier; and the vendor computer apparatus and the payment processing apparatus communicating electronically in order that the information stored in the database of the payment processing apparatus can be used to validate the submitted debit identifier and in order that the costs of the ordered streaming service is deducted from the stored value account associated with the submitted identifier, the vendor computer apparatus further processing the order only if the submitted identifier is validated; wherein: the streaming service is charged for in charging units based on elapsed time or on quantity of information streamed and the communication of the vendor computer apparatus and the payment processing apparatus enables on initial request of the streaming service performance of a check that the funds in the stored value account associated with the submitted debit identifier are sufficient for at least one charging unit of the streaming service, with the service being supplied only if the funds are sufficient, and the performance of subsequent checks periodically during delivery of the streamed service to ensure that there are sufficient funds in the stored value account to pay for continued supply of the streaming service, with the stored value account being decremented by the value of the supplied charging units.
8. A method as claimed in claim 7 wherein the vendor computer apparatus communicates with the payment processing apparatus periodically during supply of the streaming service in order to periodically check the level of funds in the relevant stored value account recorded in the database of the payment processing apparatus and so that the stored value account can be decremented.
9. A method as claimed in claim 7 or claim 8 wherein the payment administrator issues debit identifiers for use in purchase of goods and/or services from a plurality of vendors and stores in the database of the payment processing apparatus restrictions on use of the some of the issued identifiers, restricting use of the identifiers to purchase of goods and/or services of a specified vendor or a specified set of vendors so that subsequently the identifiers can only be used by purchasers in purchasing goods/services from the specified vendor(s).
10. A method as claimed in any one of claims 7 to 9 wherein the payment processing apparatus for each validated and approved purchase records a credit in favour of the relevant vendor and the payment processing apparatus instructs payment into a nominated bank account of the vendor funds equivalent to a stored credit or credits for the vendor.
11. A method as claimed in claim 10 wherein the payments to the nominated bank account of the vendor occur periodically.
12. A method as claimed in claim 7 wherein: the payment administrator issues debit identifiers for use in purchase of goods and/or services from a plurality of vendors and stores in the database of the payment processing apparatus restrictions on use of the some of the issued identifiers, restricting use of the identifiers to purchase of goods and/or services of a specified vendor or a specified set of vendors so that subsequently the identifiers can only be used by purchasers in purchasing goods/services from the specified vendor(s); the vendor computer apparatus of each specified vendor downloads from the payment processing apparatus the stored details of the generated debit identifiers and associated stored value accounts for the debit identifiers which restrict purchase of goods and/or services to those goods and/or services supplied by the vendor; and the vendor computer apparatus of each specified vendor carries out the checks on submitted debit identifier validity and on the funds in the associated stored value account locally using the downloaded information.
13. A method as claimed in any one of the preceding claims wherein at least debit identifiers are printed on cards and covered by a removable coating, the cards bearing the debit identifiers are sold by retailers and purchasers buy the cards, remove the coating over the debit identifier and then use the revealed debit identifier to purchase goods and/or services.
14. A method as claimed in claim 13 wherein the cards are supplied in batches to the retailers, each retailer communicate a number associated with each received batch to the payment administrator and the payment administrator activates a debit identifier only after receiving from a relevant number from a retailer.
15. A method as claimed in any one of the preceding claims wherein each supplied debit identifier is associated with a stored value account of an initial level of stored value and at least some identifiers are associated with accounts of greater stored values than others.