Electronic Commerce Payment System
Technical Field
This invention relates to the use of electronic money to purchase goods and services over a computer network such as the Internet.
Background to the Invention
With the increasing spread in popularity of the Internet, the popularity of purchasing goods and services through this medium from the multitude of merchants available, has continued to increase as well. Numerous websites offer goods and services which may be accessed and used by customers from the comfort of their own home using a personal computer. For example, a particular web-site may be selling books which are advertised through the seller's web-site. A consumer wanting to buy a book will access the known website and can view the listing of books available. If the customer wishes to purchase one or more of the books, the customer can purchase and order the desired books for delivery to the home. This is accomplished by providing the merchant with the customer's financial details and effecting a financial transaction to the value of the purchased goods. Traditionally, this is carried out through the provision of credit card details.
Major concerns exist among the purchasing community as to the safety of providing one's personal and credit card details over a relatively insecure medium such as the Internet. To overcome such concerns, various encrypting and other security provisions have been developed to allay the customer's fears of providing personal and credit card details over the Internet. While relatively successful, no such system is fail safe and credit card details are still vulnerable to unscrupulous hackers.
Furthermore, there is a degree of concern in relation to an individual customer's privacy in that an individual may not wish to be identified when purchasing products or services over the Internet. Current methods of payment, for example, via credit card, require that the purchaser be identified to the merchant site.
Additionally, a large proportion of customers over the Internet are children who do not have access to credit cards who may legitimately require some form of payment over the Internet. Items such as toys and books are legitimate products which are often bought by children who require their parents to do the purchasing using their credit card or are otherwise unable to obtain the products from the Internet. Some adults also do not possess credit cards and accordingly are not able to use the services available to them on the Internet.
Other forms of fraud using credit cards are also a risk. For example the merchant may either deliberately or inadvertently overcharge the credit card once credit card details are available to the merchant, or may repeat charges after initial purchase of the products. These risks are greater in newly-formed websites which have not developed a reputation and which may easily close once a number of fraudulent transactions have been made.
Discussion of the Prior Art
A number of systems exist which allow purchase of products over the Internet without the use of credit cards. A typical system might incorporate a centralized account holding site which is linked to a number of participating websites. When joining this system, a customer will provide the financial web-site with personal and financial details and open an account having a specific amount of money in the account. In return, the customer is given a user ID and password for use during the purchase transaction. At the merchant site, the purchaser purchases an item for a
given price and is transferred to the financial website for transaction of the purchase. At the financial website, the customer enters his or her user name and password to effect the transaction and once authorised, the financial site returns the customer to the purchasing site for delivery of the product. Such systems are relatively more safe than using credit cards, in that the number of sites containing personal and credit card details are limited to one. However, the risk of that site being illegally accessed still exists and the customer is not anonymous to this website.
It is an object of the present invention to provide an improved financial transaction system and method, so as to improve security and privacy for purchasers.
Summary of the Invention
According to a first aspect of the present invention, there is provided an electronic token money transaction system enabling customers to purchase goods and services from merchants in a secure manner. The system includes a token provider for providing one or more tokens to a customer and a participating merchant having goods and/or services to sell, the merchant accepting said tokens as payment for said goods and/or services. The token includes a monetary value to which a unique identification code is dynamically assignable.
Preferably, the monetary value is non-rechargeable.
Preferably, the unique identification code has an associated expiry date after which the identification code is no longer valid.
According to a second aspect of the present invention, there is provided a method of purchasing goods or services using electronic token money, the method including, selecting a good or service from a merchant for purchase at a predetermined cost,
providing to the merchant an identification code of the money token, deducting the predetermined cost from a current monetary value to which is assigned the identification code, transferring the deducted value to an account of the merchant, and reassigning the identification code to the remaining value.
According to a third aspect of the present invention, there is provided a system wherein a first token, having a first monetary value to which is assigned a first identification code, may be combined with at least a second token, having a second monetary value, to which is assigned a second identification code, different from said first identification code, to provide a new token having a value at least approximately equal to the sum of said first monetary value and said at least second monetary value.
Preferably the combination is effected by; unassigning said first and second identification codes from said first and second monetary values; generating a new identification code; assigning said new identification code to said greater value and, cancelling said first and second identification codes.
According to a fourth aspect of the present invention, there is provided a system wherein a first token having a first monetary value to which a first identification code is assigned, may be split into one or more further tokens having a further monetary value to which a further identification code, different from said first identification code is assigned.
Preferably, said splitting is effected by; determining the number of further tokens to be produced;
determining a new monetary value to be associated with said at least one further tokens; generating at least one further identification code; assigning said at least one further identification code to said new monetary value; deducting at least the approximate value of said new monetary value from said first monetary value to produce a reduced value; and reassigning said first identification code to said reduced value.
According to a fifth aspect of the present invention, there is provided a system wherein a first token having a first monetary value to which is assigned a first identification code, may be reissued to provide a reissued token having at least the approximate value of said first monetary value, to which is associated a second identification code, different from said first identification code.
Preferably, said reissue is effected by; unassigning said first identification value from said first monetary value; generating said second identification value; assigning said second identification code to at least the approximate value of said first monetary value; and cancelling said first identification code.
According to a sixth aspect of the present invention, there is provided an electronic cash token including: a monetary value to which a unique identification code is dynamically assignable.
Preferably, said monetary value is non-rechargeable.
Preferably, said electronic cash token further includes data relating to the time and date of the purchase.
Preferably, said unique identification code becomes invalid after a given expiry date. Preferably, said electronic cash token further includes data relating to the expiry date.
Optionally, the identification code may have a further code sequence which will only allow the electronic cash token to be used at merchant sides accepting that further code sequence.
According to a seventh aspect of the present invention, there is provided a method of issuing an electronic cash token, the method including; issuing an electronic token identification code; and at a selected time, assigning that electronic token identification code to a monetary value.
Preferably, the issuance and assignment of the code is done in response to receiving a payment from a customer.
Preferably, the value of the monetary value to which the code is assigned is at least approximately equal to the value of the payment received.
According to an eighth aspect of the present invention there is provided an electronic cash token including a cash token identification code and a monetary value, wherein said cash token identification code is only assigned to said monetary value, at a selected time.
Alternatively, the cash token identification code may already be assigned to a monetary value, but may only be made useable at a selected time.
A Brief Description of Drawings
Figure 1 shows one physical embodiment of the electronic money token of the present invention;
Figure 2 shows a preferred purchase cycle in purchasing goods using the system of the present invention;
Figure 3 shows a preferred sequence of events of a part of the purchase cycle of figure 2;
Figure 4 shows a general flow chart of a preferred method of manipulating the electronic cash tokens of the invention;
Figure 5 shows a sub-process used in the procedure of figure 4, relating to the
SPLITS feature of the preferred invention;
Figure 6 shows another sub-process used in the procedure of figure 4;
Figure 7 shows another sub-process used in the procedure of figure 4, relating to the COMBINE feature of the present invention;
Figure 8 shows another sub-process used with the procedure of figure 4, relating to the REISSUE feature of the present invention;
Figure 9 shows a general overview of the system of the present invention.
Detailed Description of the Preferred Embodiment
Physical Format of Electronic Cash Token
Although it will be understood that the essence of the invention lies in the allocation of a unique code to a non-rechargeable monetary value to provide an electronic cash token, one physical embodiment of the token will be in the form of a cardboard or plastic card 400 as illustrated in Figure 1. It will be understood however, that the term "token" need not be restricted to a physical element, but may equally refer to a piece of data in electronic or other form.
Various markings may appear on card 400 including the actual monetary value of the token printed in space 401 . In addition to this, there may be a series of physical serial numbers 402 being the token bar code. A printable version of the bar code data may appear underneath the bar code at 403. Further data including the 16 digit identification code will appear in boxes designated by 405 along with a printed record of the expiry date in hours, minutes, seconds, day, month and year at 406. Preferably, a security film 404 consisting of a once-only removable opaque label which reveals the token code and expiry dates by scratching away the film may be provided. Thus, only the valid owner of the electronic cash token will have access to this information, which will be required to use the token in making purchases over the Internet.
As will be seen below, in use, the data at 402 and 403, is transmitted from the distributor system administration area and represents the validation search key. The data at 405 and 406 is used by the customer in providing authentication of use of the electronic cash token.
Electronic Cash Token
The codes assigned to the monetary value of the cash token are preferably 16 digit characters, derived from a random physical process. This may take the form of a
physical event interrupting a pseudo-random number generating process to generate a stream of digits according to the time at which the program was interrupted. However, it will be understood that any random or pseudo random number generating process will be feasible to generate the identification codes of the present invention. The characters may be either alphabetic or numeric, or both.
A new electronic code is only generated upon demand (for example through one or more of the processes discussed later). Thus, there is no database on which is stored a collection of "to be used" codes. Once generated, a scan algorithm can check the new code to ensure that it is "sufficiently" different from any existing code, be it expired or currently in use.
New codes may be generated as new electronic cash is bought into being (ie a new electronic cash token is purchased), or during execution of a number of features of the present invention, such as SPLITS, COMBINES and REISSUES as discussed later.
When a customer who wishes to purchase one or more electronic cash tokens submits a payment (see later for methods of purchasing the electronic cash tokens), details relating to place, time and method of purchase are entered into the administration database by the token seller, and a new identification code is generated as described above and assigned to the purchased value of the electronic cash token. This assignment is done by "tagging" the monetary value with the new code in any conventional manner. When the customer wishes to spend the electronic cash, he or she will provide the identification, and the administration system will manipulate the electronic cash in various ways as described later.
While it is important that no two identification codes are the same, it will be appreciated that expired identification codes may be reissued once expired, by allocating to that code a new expiry date and different "purchase" information such as date and time of purchase. This effectively means that the old code can not be
reused in its original format since the "allocated" peripheral information is different, thus maintaining security.
It will be noted that it is possible to provide a different type of electronic cash for adults, where it will be required to show evidence of age to purchase the tokens. Electronic cash of the adult variety may be differentiated from normal electronic cash via a given code sequence in the identification code. Payment using this electronic cash will act as evidence of age and allow access to otherwise restricted sites.
This concept may also be extended to limit the use of a given cash token to a particular merchant, or group of merchants. Such an application may be used for gift vouchers, where a customer buys a cash token from a particular store to give to a friend as a gift voucher, to be used at that store. To effect this selection, the identification code may include a further code sequence which will only be accepted at pre-designated stores or merchant sites.
Purchase Cycle
An example of a preferred method in which a customer may make a purchase from a merchant website is shown in Figures 2 and 3. The customer (10) accesses the desired participating merchant website (20) to view the goods or services available from that site in the normal manner. Once the customer (10) has selected the desired items for purchase, the customer is given a number of payment options (30), including payment via credit card (31 ), cash on delivery (COD) (32) or via the system of the present invention (33).
If the chosen payment option is via credit card or COD, then the transaction is conducted in the normal manner. If customer (10) elects to use the electronic cash option of the invention (33), the customer is prompted to provide the identification code that has been assigned to the particular monetary value. The merchant then
initiates the token payment procedure by supplying to the system administrator the relevant transaction information (43) including the merchant identification number, the value of the purchase and purchase date and time. This information is transferred to the administrator by way of a secure link (50, 201 ) Once received by the administrator, the merchant code is analysed for authenticity (202). This involves checking checksum properties and matching the ID to those stored on the administration database. If the merchant ID code is found to be authorised, the appropriate identification code of the electronic cash amount is obtained (100). This sequence is described in more detail below. If the merchant ID code is found to be incorrect or false, then the transaction is cancelled (203) and a message to that effect is transmitted (214) to the merchant website (20).
If, as described above, the merchant ID is authenticated at 202 the cash identification code is obtained at 100 (see below). If the sequence is unsuccessful, a further two attempts are made to obtain the correct code (204), (again, see below). If the attempt is successful, the cash identification code is considered for validity (205). If the result of this consideration is negative, a further attempt to obtain the correct code (at 100) is made as discussed above. If the identification code obtained is deemed to be valid, a consideration is made regarding whether or not the actual monetary value to which the given code has been assigned is at least equal to the required purchase price of the goods being bought (206). If the monetary value is not sufficient to cover the purchase cost, a temporary debit log for that code is created (207) and an attempt to obtain another electronic cash (having another identification code) is made as discussed. If at any time, a transaction is unsuccessful, the temporary debit log is cancelled at 208.
In the event that the given identification code does cover the purchase price, then the monetary value to which that code is assigned is reduced to reflect the remaining amount (209). For example, if a chosen code is assigned to a value of $50, and the
purchase price of the goods is $34.95, then the code will be re-assigned to a value of $15.05 which may be used for subsequent purchases.
Once this has been done, a confirmation of temporary debits is carried out (210), together with a confirmation that the transaction has been successfully completed (21 1 ). This confirmation is then transmitted to the merchant via e-mail for example (212). If the customer (10) has opted to receive confirmation e-mails (213), then a copy of this confirmation will be sent to the customer.
The actual transaction is made in real time through a secure link through servers 50 and 201. Upon successful completion of the transaction, and confirmation of the merchant web site, a transaction log 40 is created to reflect the details of the transaction, and if the transaction is paid (41 ), a message (42) is created to confirm that delivery of the goods be effected, by any appropriate means.
The process within block 100, relating to obtaining the actual cash identification code is now discussed with reference to Figure 3. The procedure begins with an input of the identification code of the electronic cash required at 101 , followed by an establishment of the amount of money to which the input identification code has been assigned (102). At 103, an enquiry is made as to whether currency conversion is required. For example, if goods are being purchased in American dollars using electronic cash bought in Australia, having an Australian dollar value, then an appropriate conversion will need to be made to enable the system to deduct the equivalent Australian dollar amount from the value of the electronic cash.
If it is determined that a currency conversion is required, then knowing the desired code (103) and accessing merchant currency units (106), a conversion may be executed (104). At 105, an amount may be deducted from the converter amount to cover any conversion fees. At 107, the resulting currency matches that of the
merchant. The appropriate code is obtained to proceed to step 204 described above. If no currency conversion is required (i.e. the purchase is made using the token currency that is the same as the currency of the goods), then the input code is checked to make sure that it is a valid code (108). If a valid code is not entered, or no code is entered, the sequence will move on to step 208 described above and the transaction is cancelled.
Before proceeding with the transaction, a check is made (1 10) to determine whether this is the first attempt at entering the code. This may be due to the fact that the code was entered incorrectly, (see 108 above), or that the same code has been used previously to expend a portion of the value to which it has been assigned. If it is the first time, and the code is correct, then the process moves on to step 204 above (see Figure X). If it is not the first attempt at entering the code, a determination is made (1 1 1 ) to see if it is the second attempt at entering the code. A unique security feature of the present invention now comes into action. As well as requiring the customer 10 to enter the required code, the system also prompts the customer 10 to enter further information (1 13). This information may consist of a random part of the expiry date of the electronic cash which is marked on the actual token itself. If the code and the extra data match, then the entry is accepted and the process moves on to block 204.
If the code is being entered for the nth time (1 12), then the customer 10 is prompted for even more information (1 14), such as another part of the expiry date, or the time and place of initial purchase of the token. If all the entries match, then the process moves on to block 204. If not, then the transaction is not continued. Thus, it is possible for a given electronic cash token to be used any number of times (eg to make many small purchases), until the non-rechargeable value is reduced to zero, or the assigned code itself expires. For each subsequent use however, more and more information is required to allow a successful transaction.
This extra safeguard drastically reduces the chances of somebody attempting to use a pre-used code, such as a merchant (who is in possession of the identification code) attempting to use any remaining value on the electronic cash of a customer.
To be able to properly enter the required extra data, the user will need to be in possession of the actual token which can only be the valid initial purchaser or validly transferred owner unless the token itself has been stolen. In such a case, the valid owner of the token may contact the administrator's web facility to reissue a new code to report the theft and the code can be deassigned to prevent a thief from using the stolen code.
Electronic Cash Manipulations
One of the unique features of the present invention is that, like normal cash, a number of electronic cash tokens, each having unique identification codes, may be combined to make a larger desired total. For example, if goods to the value of $1 15 are being purchased, three tokens, each having a value of $50 may be combined to meet the required total. Two of the tokens will be completely spent, while the third will have a resultant value of $35, as described above, for subsequent use for another purchase.
Figures 4 to 8 show a preferred method of controlling such token manipulations. In Figure 4, there is shown a general procedure for managing these manipulations. This procedure is invoked when a customer accesses the system administration website or either directly or through a web site merchant. At 300, the customer enters and a determination is made as to whether or not currency conversion is required (301 ). If conversion is required, the customer is prompted to enter the identification code and the currency with which the goods are to be purchased (302). Next, a determination is made (303) relating to whether the total value of the electronic cash is to be converted, or only a partial amount. This may be the case if the customer is purchasing a product in a foreign currency which does not exhaust
the total value of the electronic cash and the customer would like to retain the remaining portion in its home currency. If the full amount is to be converted, then the conversion is carried out (304) as described above, minus a conversion fee. This part of the procedure is then terminated (305), to take the customer back to the main flow to be given further options.
If only a portion of the amount is to be converted, then a determination (306) is made as to whether the conversion is to be made according to the source currency (ie currency in which the token was originally purchased) or of the destination currency (of the goods being purchased). If destination currency is selected, the customer is prompted to enter the amount to be converted (307). If this amount is able to be converted, the conversion is carried out at (309) and proceeds to the main flow of the process to (312). If the desired amount cannot be converted (308), the customer is prompted to reenter a value for conversion (307).
If conversion by source is required, again the customer is prompted to enter the amount required for conversion (310). A determination is then made (31 1 ) as to whether or not the desired amount for conversion is less than the total value available of the given electronic cash. If the amount entered is greater than that available, the customer will be prompted to enter another value at (310). If the amount is available, then the currency is converted (309) and the process returns to the main flow at (312).
In the event that a partial conversion is made, the remaining unconverted value will be assigned a new identification code. Thus, two separate electronic cash "tokens" will now exist, each with its own unique identification.
At (312), a determination is made as to whether or not SPLITS are required. This is done by the customer specifically specifying his or her desire to "SPLIT" an electronic cash token. The SPLITS feature of the invention allows a given token to be "split" into two or more tokens of lesser value, which when combined, add up to
the original value minus any fees. For example, if a customer has a token for $50 and desires to "split" this into one of $30 and one of $20 (assuming no fees), then a new identification code is generated, which is assigned to the value of $30 and reassigning the original token code to a value of $20. Splitting may be desirable if the customer wishes to pay the merchant the exact amount of the purchase and not provide to the merchant an identification code having any remaining value. This enhances the security of the system, since once used, the identity code assigned to the given value can never be reused. Alternatively, the customer may wish to give a gift to a friend, of a portion of his or her electronic cash. This may be done by "splitting" the electronic cash to provide a new identification code assigned to the gift value and e-mailing the relevant details of the new electronic cash to the friend for use on the internet.
If a SPLIT is desired, the system advances to block 313, which is now described in more detail with reference to Figure 5.
Upon initiating this SPLIT process, the customer is prompted to enter the token identification code at 341 , as well as the number of SPLITS required at 342. The actual "splitting" process is then initiated, as shown in Figure 6, beginning at 3160. For the first SPLIT, the customer is prompted to enter the dollar value for the newly- split token (3161 ). A new electronic cash identification code is generated at 3162 and is assigned to that new value leaving the original identification code with the remaining value (minus any applicable fees). The details of this process are then displayed on the customer's screen at 3163. Blocks 3164 to 3169 provide the customer with an email confirmation of the SPLITS if desired, a hard copy printout if desired, as well as a file copy if needed.
At 3170, an option is given to the customer to assign a "lock" password for extra security for the newly-created electronic cash. This may be in the form of a password which is prompted for at 3171 . To reduce the risk of the customer
forgetting the password, the customer may enter a word or number which would trigger his or her memory to remember the password. This "clue" is entered in at 3172 and may be displayed to the customer at a later date when the password is required. The splitting process then ends at 3173 and the process returns to block 343 in the general SPLIT process. At this point, the system determines whether or not all desired SPLITS have been made. For example, if the customer entered the number "3" at 342 in figure 5, the start SPLIT process (blocks 3160 to 3174) will be run until 3 new electronic cash "tokens" have been generated, with the original identification code being assigned to a value being the difference between the original value and the sum of the newly created cash tokens (minus any applicable fees).
Once all desired SPLITS have been performed, the process will proceed to block 314 to return to the main flow of Figure 4.
At this point, or if no SPLITS are required, the customer is asked whether he or she requires any COMBINES. The COMBINES feature of the present invention allows the customer to consolidate two or more smaller-valued electronic cash tokens into a single, larger-valued electronic cash token. For example, a customer may have four $5 tokens which he or she may decide to "combine" to form a new single $20 token.
If the COMBINE feature is selected at 315, the process as illustrated in Figure 7 is commenced at block 316. Referring now to Figure 7, from block 316 the process proceeds to block 322 where the customer is prompted to enter the identification code of two or more electronic cash tokens to be combined. At block 323, the system determines whether or not the last entered identification code is the final code to be entered for combination. This is done by the customer indicating so.
If another token code is to be entered, the system cycles back to block 322 to prompt the customer to enter a subsequent code, otherwise the system proceeds to block 324 which adds together all the values of the electronic cash tokens entered
previously. At block 325, the system determines whether or not one of the existing identification codes of the combined electronic cash tokens is to be temporarily assigned to the summed value existing, or whether a new code should be issued and assigned to the total summed value immediately. These are alternative routes, the former is preferable, but both are viable. If an existing identification code is to be temporarily assigned to the amount, the customer is prompted to nominate which of the codes should be assigned to the new value at 326.
The transfer is then conducted at 327 and the remaining unused codes, whose values have been added together are then expired at 328. This is done by recording on the system database that any electronic cash tokens having these identification codes are invalid. The system is then forwarded to block 329 to continue the process. In the event that the option used by the system does not assign one of the existing codes to the summed dollar amount, the system expires all of the identification codes whose monetary values have been combined at 329, and then generates and assigns a new identification code to the summed total at 330. Effectively, a new electronic cash "token" is issued. As a part of this process, similar options to those described in relation to Figure 6 relating to the forwarding of e-mail, print out or file copy may be available.
This then returns us to the main flow of Figure 4 and onto block 318 which considers the aspect of REISSUE. REISSUing refers to a feature of the present invention whereby an existing electronic cash can be changed into a new electronic cash. This REISSUE maybe useful in the case where a particular electronic cash "token" is stolen and the customer may then contact the administrator through its website, cause new token identification code to be generated and assigned to the value to replace the original code. The original code is then cancelled. Thus, if the thief attempts to purchase goods using the stolen electronic cash having the original code, the transaction will be unsuccessful since the old code will have been cancelled and replaced by a new one.
The system prompts the customer as to whether or not he or she requires a reissue at 318. If the answer to this is yes, the process proceeds to 319 which initiates the procedure as illustrated in Figure 8. From 319, the customer is prompted to enter the identification code of the electronic cash to which the customer wishes to have a new code assigned at 331 . At 332, the original code is disassociated from the value of the electronic cash, and a new code is generated and assigned to the value, effectively issuing a new electronic cash "token". Once again, various options relating to e-mail, print outs and file copies are available as discussed above with reference to Figure 6. After issuing the new code to the value, the old code is marked as expired on the system at 333. The system then returns to the main flow of Figure 4 at block 320 to complete the manipulation process at block 321.
System Overview
Figure 9 provides a schematic overview of the elements of a preferred form of the present invention, and illustrates how a customer can purchase tokens according to the invention by various means. The customer 500, desiring to purchase one or more electronic cash tokens according to the present invention will have a number of purchase options for the tokens. Firstly, the customer may visit a physical location having human staff to provide a face-to-face purchase environment, at 501. At such a distribution centre, the customer will purchase one or more electronic cash tokens which may be presented to them in the form of a card such as that described above in relation to Figure 1 . It is envisaged that, for example, a customer may purchase a $50 token for $52.00, the $2.00 being administration and profit charges. In contact with the distributor 501 , is a physical format distributor office 502 which provides distributor 501 with sufficient quantities of physical tokens in response to orders made by distributors 501.
Connected to the physical format distributors office is the distributor bank account 503 which is in turn connected to the bank account of the administrator of the
present invention 504. Money paid for tokens by the customer at 501 is provided to the physical format distributor office 502 which is stored in the distributor's bank account 503 for subsequent transfer to the administrator's bank account 504. A portion of the money stored in bank account 504 is used to fund the costs of manufacturing and distributing the physical tokens. Upon direction by the administrator, computer and database section 505, instructions are provided to a printing press company 506 to provide the actual physical tokens. Once prepared, these tokens are delivered by a postal courier service 507 to the physical format distributor office 502.
The route shown by e-mail box 512 indicates the option of electronic cash being delivered purely in electronic form to the customer's home PC. In this event, upon receipt of order and payment by the customer, the administrator will transmit the required token identification code together with any other peripheral information to the customer. Once in possession of this code, the customer may make purchases on the internet to the value to which the identification code has been assigned.
Alternatively, the customer may wish to purchase tokens directly from the administrator of the system via cheque 516 or money order 518. In this event, the customer will send the cheque or money order to the administrator in the normal manner, who will, upon receipt of the cheque or money order, process the order at 517, transfer the money from the cheque or money order to its bank account 504 and direct that the ordered tokens be delivered to the customer as discussed above or alternatively, issue an electronic version through e-mail.
If the customer wishes to purchase electronic cash via direct debit authority 519, the central database 505 will communicate with the customer's bank account 523 to extract payment for the electronic cash. Again, the payment will be placed in the administrator's bank account 504 and the delivery of the electronic cash as described above will be effected. A further option is for the customer to purchase the
tokens directly from the administrator from its Internet web-site 513 and payment may be effected by normal means such as credit card payment 514 involving the credit card bank account 515.
A customer may also wish to purchase electronic cash in the form of a gift voucher. The purchase may be made as described above, and the gift voucher, bearing the required identification code and details may be delivered to the intended recipient via mailing house 51 1 and postal/courier service 510.
When purchasing goods from a particular Internet merchant, using the tokens of the present invention, the customer may access the merchant's Internet website 520 which is connected to the merchants central computer 521 and places his or her order and pays for the order using the electronic cash present as discussed previously.
Another scenario for purchasing goods, may be via telephone purchase where a consumer may have seen an advertisement for a product for sale from a Tele- vending company. Customer 500 then contacts the Tele-vending telephone customer service 525 via telephone which then accesses the merchant computer to place the order for the goods and pay via electronic cash. The purchase instructions and data are then transmitted via the merchant computer 526 through the administrator's Internet web-site 524 and payment for the products is deposited in the merchant's bank account 527.
In addition to the method of purchasing electronic cash in electronic form as detailed above, the present invention allows electronic cash to be purchased in electronic form by other means. This is shown in figure 9 at box 528, together with "Other Registers". Examples of distributors of electronic cash are as follows:
1 . Real-Time with single copy printing in addition to cash register (Type A).
2. Real-Time with only dual copy printing (Type B).
3. Internet terminal without link to cash register (Type I).
4. Manual distributor selling "ready to use" electronic cash (Type M).
5. Validity distributor that reports serial numbers of the electronic cash token (Type V).
Type A
A distributor outlet where the point of sale (POS) function is combined with a computer that can also print out electronic cash directly. The store is Real-Time and the electronic cash print out is done on demand after the cash has been collected. Thus, the value of the electronic cash bought is assigned its identification code just prior to printing. A cash register receipt is used as a back up to provide the serial number of the electronic cash and allow for reprinting the electronic cash if the print out fails.
Type B
A distributor outlet where the point of sale (POS) function is limited to a single print out function having typically a carbon copy or dual print out. Since a preferred aspect of the present invention is that the buyer of the electronic cash remain anonymous, it is undesirable for the distributor outlet to retain a carbon copy of the print out since this may contain details which may identify the purchaser. If the dual copy mode can be inhibited, or both copies given to the customer, then it becomes a Type A distributor (ie one with a single copy output in addition to a cash register).
Type I
A distributor outlet where the point of sale (POS) function is separate from the internet provided terminal. This relies on the operator manually, entering the electronic cash information to provide a print out with an identification code which is given to the customer. This assumes that the operator is responsible for the cash
going into the till and subsequently logging on and identifying the monetary value to the administrator.
Type V
A distributor outlet where the point of sale (POS) function has identification codes that are not already assigned to any monetary value and are physically present to hand over to the customer at the counter. If these are stolen, no benefit will be derived by the thief, since the identification codes have not yet been assigned to any monetary value and are accordingly worthless. Once payment by their customer is made, the Real-Time cash register scans a serial number associated with the particular non validated identification code. The administration system then assigns that particular code to the monetary value paid and the electronic cash is bought into being and issued to the customer.
A related aspect of this is in the provision of an identification code in a magazine for example, as a promotional exercise. The magazine may contain a page advertising the system of the present invention, and include an identification code which may potentially have a value of $10 for example. To "activate" the code and make it useable, the customer may enter the administration website and may be prompted to enter details such as a bar code of the magazine, and/or place and time of purchase. The system will then "assign" the identification code to the value, thereby "activating" the code, and allowing use of the token.
Electronic Cash Tokens used in conjunction with Smart Cards
A smart card or any other data carrier can act as a transport and access media to the electronic cash tokens of the present invention. Each smart card can deliver and accept multiple token codes for use in the system of the invention.
For example, a smart card may be inserted into a vending machine which is able to talk to the smart card and is able to access the identification codes stored thereon.
The vending machine also needs to be connected to the administration web-site to have the administration central database provide the transaction update and payment of the owner of the goods sold.
The system of the present invention is flexible enough to enable small amounts of money such as 20 cents or $1 , to be traded, allowing the vending machine to sell low cost goods such as confectionery or other snack foods. The smart card may hold a multitude of separate identification codes, each being to a value of $1 . If for example, if the purchase price of the desired good is $2, the smart card can issue one payment (i.e. one identification cash worth $1 ) followed by a subsequent electronic cash "unit" also valued at $1 to complete the transaction. Once used, the particular identification code is marked as expired and is unusable.
It is also possible that the smart card is able to participate in its own Internet sessions and reconfigure itself with the features of the present invention including COMBINES and SPLITS, to allow it to reconfigure existing electronic cash "units" to provide a single electronic cash "unit" having the desired purchase total. This parallels the user logging onto the administration web-site and using the same COMBINE and SPLIT features to generate the needed transaction amount. In practice, the vending machine appears to the administrator database as just another merchant on the web.