WO2001067407A1 - Electronic commerce payment system - Google Patents

Electronic commerce payment system Download PDF

Info

Publication number
WO2001067407A1
WO2001067407A1 PCT/AU2001/000236 AU0100236W WO0167407A1 WO 2001067407 A1 WO2001067407 A1 WO 2001067407A1 AU 0100236 W AU0100236 W AU 0100236W WO 0167407 A1 WO0167407 A1 WO 0167407A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
identification code
value
monetary value
electronic
Prior art date
Application number
PCT/AU2001/000236
Other languages
French (fr)
Inventor
Raymond Eric Pakalns
Paul Monsted
Original Assignee
Technocash, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Technocash, Inc. filed Critical Technocash, Inc.
Priority to AU2001237145A priority Critical patent/AU2001237145A1/en
Publication of WO2001067407A1 publication Critical patent/WO2001067407A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/28Pre-payment schemes, e.g. "pay before"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/29Payment schemes or models characterised by micropayments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342Cards defining paid or billed services or quantities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/02Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered

Definitions

  • This invention relates to the use of electronic money to purchase goods and services over a computer network such as the Internet.
  • a typical system might incorporate a centralized account holding site which is linked to a number of participating websites.
  • a customer 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.
  • the purchaser purchases an item for a given price and is transferred to the financial website for transaction of the purchase.
  • 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.
  • 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.
  • the monetary value is non-rechargeable.
  • the unique identification code has an associated expiry date after which the identification code is no longer valid.
  • a method of purchasing goods or services using electronic token money 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an electronic cash token including: a monetary value to which a unique identification code is dynamically assignable.
  • said monetary value is non-rechargeable.
  • said electronic cash token further includes data relating to the time and date of the purchase.
  • said unique identification code becomes invalid after a given expiry date.
  • said electronic cash token further includes data relating to the expiry date.
  • 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.
  • a method of issuing an electronic cash token including; issuing an electronic token identification code; and at a selected time, assigning that electronic token identification code to a monetary value.
  • the issuance and assignment of the code is done in response to receiving a payment from a customer.
  • the value of the monetary value to which the code is assigned is at least approximately equal to the value of the payment received.
  • 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.
  • the cash token identification code may already be assigned to a monetary value, but may only be made useable at a selected time.
  • 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
  • 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
  • FIG. 9 shows a general overview of the system of the present invention. Detailed Description of the Preferred Embodiment
  • token 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the identification code may include a further code sequence which will only be accepted at pre-designated stores or merchant sites.
  • FIG. 2 and 3 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.
  • 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).
  • payment options including payment via credit card (31 ), cash on delivery (COD) (32) or via the system of the present invention (33).
  • 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 )
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • a given electronic cash token 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.
  • 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.
  • 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.
  • FIGs 4 to 8 show a preferred method of controlling such token manipulations.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • the source currency ie currency in which the token was originally purchased
  • the destination currency 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).
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • REISSUE 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.
  • 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.
  • FIG 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.
  • the customer may visit a physical location having human staff to provide a face-to-face purchase environment, at 501.
  • 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.
  • a physical format distributor office 502 which provides distributor 501 with sufficient quantities of physical tokens in response to orders made by distributors 501.
  • the distributor bank account 503 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.
  • 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.
  • the administrator 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.
  • the customer may wish to purchase tokens directly from the administrator of the system via cheque 516 or money order 518.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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).
  • 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.
  • POS point of sale
  • 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.
  • 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.
  • an identification code which may potentially have a value of $10 for example.
  • 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.
  • 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.
  • 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.
  • 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.
  • the vending machine appears to the administrator database as just another merchant on the web.

Abstract

A token (400) for an electronic token money transaction system has a monetary value (401) and a unique identification code (405) which is dynamically assignable to it. The invention described above provides a mechanism which allows secure and in one embodiment, completely anonymous, purchase of items over an electronic medium such as the internet. Security is provided by having limited, non-rechargeable monetary values (401) to which identification codes (405) are dynamically assignable. Thus, once the monetary value (401) is expired, the identification code (405) assigned to that value is cancelled and is not able to be used again. The dynamic assignability of the codes also allows features which include the ability to SPLIT, COMBINE and REISSUE electronic cash.

Description

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.

Claims

Claims
An electronic token money transaction system enabling customers to purchase goods and services from merchants in a secure manner, the system including at least one token provider for providing one or more tokens to a customer and at least one participating merchant having goods and/or services to sell, the merchant accepting said tokens as payment for said goods and/or services, wherein each token includes a monetary value to which a unique identification code is dynamically assignable.
An electronic token money transaction system as claimed in claim 1 , in which the monetary value is non-rechargeable.
3. An electronic token money transaction system as claimed in claim 1 or claim 2 in which the unique identification code has an associated expiry date after which the identification code is no longer valid.
4. An electronic token money transaction system as claimed in any one of the preceding claims, 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.
An electronic token money transaction system as claimed in claim 4, wherein 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.
6. An electronic token money transaction system as claimed in any one of the preceding claims, 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.
7. An electronic token money transaction system as claimed in claim 6, wherein the split of the first token into one or more further tokens 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.
8. An electronic token money transaction system as claimed in any one of the preceding claims 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.
. An electronic money transaction system as claimed in claim 8, wherein 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.
10. An electronic token money transaction system enabling customers to purchase goods and services from merchants in a secure manner, the system including at least one token provider for providing one or more tokens to a customer and at least one participating merchant having goods and/or services to sell, the merchant accepting said tokens as payment for said goods and/or services, 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.
11 . A system as claimed in claim 10, wherein 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.
12. An electronic token money transaction system enabling customers to purchase goods and services from merchants in a secure manner, the system including at least one token provider for providing one or more tokens to a customer and at least one participating merchant having goods and/or services to sell, the merchant accepting said tokens as payment for said goods and/or services 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.
13. An electronic token money transaction system as claimed in claim 12, wherein the split of the first token into one or more further tokens Preferably, 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.
14. An electronic token money transaction system enabling customers to purchase goods and services from merchants in a secure manner, the system including at least one token provider for providing one or more tokens to a customer and at least one participating merchant having goods and/or services to sell, the merchant accepting said tokens as payment for said goods and/or services 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.
15. An electronic money transaction system as claimed in claim 14, wherein 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.
16. 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.
17. An electronic cash token including: a monetary value to which a unique identification code is dynamically assignable.
18. An electronic cash token as claimed in claim 17 wherein said monetary value is non-rechargeable.
19. An electronic cash token as claimed in claim 17 or claim 18, further including data relating to the time and date of the purchase.
20. An electronic cash token as claimed in any one of claims 17 to 19 in which said unique identification code becomes invalid after a given expiry date.
21 . An electronic cash token as claimed in claim 20, further including data relating to the expiry date.
22. An electronic cash token as claimed in any one of claims 17 to 21 in which the identification code has a further code sequence which will only allow the electronic cash token to be used at merchant sides accepting that further code sequence.
23. 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.
24. An electronic cash token including a cash token identification code assigned to a monetary value, and in which the token is made usable at a selected time subsequent to the assignment of the identification code to the monetary value.
25. 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.
26. A method of issuing an electronic cash token as claimed in claim 25 in which the issuance and assignment of the code is done in response to receiving a payment from a customer.
27. A method of issuing an electronic cash token as claimed in claim 25 or claim 26 in which the value of the monetary value to which the code is assigned is at least approximately equal to the value of the payment received.
28. An electronic token money transaction system as claimed in any one of claims 1 to 15, substantially as described with reference to the drawings.
29. A method of purchasing goods or services as claimed in claim 16, substantially as described with reference to the drawings.
30. An electronic cash token as claimed in any one of claims 17 to 24, substantially as described with reference to the drawings.
31. A method of issuing an electronic cash token as claimed in any one of claims 25 to 27, substantially as described with reference to the drawings.
PCT/AU2001/000236 2000-03-07 2001-03-07 Electronic commerce payment system WO2001067407A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001237145A AU2001237145A1 (en) 2000-03-07 2001-03-07 Electronic commerce payment system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AUPQ6080 2000-03-07
AUPQ6080A AUPQ608000A0 (en) 2000-03-07 2000-03-07 Electronic commerce payment system

Publications (1)

Publication Number Publication Date
WO2001067407A1 true WO2001067407A1 (en) 2001-09-13

Family

ID=3820184

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2001/000236 WO2001067407A1 (en) 2000-03-07 2001-03-07 Electronic commerce payment system

Country Status (2)

Country Link
AU (1) AUPQ608000A0 (en)
WO (1) WO2001067407A1 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002019234A1 (en) * 2000-08-29 2002-03-07 Chijioke Uzo Method and apparatus for secure electronic payments
FR2840434A1 (en) * 2002-05-31 2003-12-05 Anne Marie Etcheverry AUTHENTICATION AND VIRTUAL AND / OR REAL PAYMENT DEVICE AND IMPLEMENTATION METHOD
WO2004051529A1 (en) * 2002-11-29 2004-06-17 Smart Voucher Plc Electronic processing system
WO2004066223A1 (en) * 2002-12-18 2004-08-05 Thierry Baillie System, access card or prepayment method for internet
EP1484702A1 (en) * 2002-02-25 2004-12-08 Hiroshi Tatsuki Charging method, information system, and program
GB2428126A (en) * 2005-07-08 2007-01-17 Secoren Ltd System for processing transactions
WO2006117695A3 (en) * 2005-01-26 2007-04-19 Heng Kah Choy Fraud-free payment for internet purchases
GB2432031A (en) * 2005-08-30 2007-05-09 Harold Prianne Anura Wijetunge Cash transfer from one mobile phone to another with access to cash instantly.
US8336763B2 (en) 2005-07-08 2012-12-25 Secoren Limited System and method for processing transactions
US20120330846A1 (en) * 2011-06-27 2012-12-27 Accenture Global Services Limited Dynamic electronic money
CN103093360A (en) * 2013-01-09 2013-05-08 费兆雄 Merchandise anti-counterfeiting method and merchandise anti-counterfeiting system
EP3226191A1 (en) * 2016-04-03 2017-10-04 Trinkaus, Hans Alternate instrument of payment, highly personalized, weak personalized or no personalization
EP3369062B1 (en) * 2015-10-30 2022-08-31 ID Loop AB Method for payment with a cash card

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996033476A2 (en) * 1995-04-21 1996-10-24 Citibank, N.A. Electronic-monetary system
FR2747962A1 (en) * 1995-12-19 1997-10-31 Ittah Aaron Method of sending payment over computer networks particularly the internet
US5892827A (en) * 1996-06-14 1999-04-06 Catalina Marketing International, Inc. Method and apparatus for generating personal identification numbers for use in consumer transactions
US5983207A (en) * 1993-02-10 1999-11-09 Turk; James J. Electronic cash eliminating payment risk
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control
WO2001011515A2 (en) * 1999-05-28 2001-02-15 Spendcash.Com, Inc. Method and system for making anonymous electronic payments on the world wide web

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5983207A (en) * 1993-02-10 1999-11-09 Turk; James J. Electronic cash eliminating payment risk
WO1996033476A2 (en) * 1995-04-21 1996-10-24 Citibank, N.A. Electronic-monetary system
FR2747962A1 (en) * 1995-12-19 1997-10-31 Ittah Aaron Method of sending payment over computer networks particularly the internet
US5892827A (en) * 1996-06-14 1999-04-06 Catalina Marketing International, Inc. Method and apparatus for generating personal identification numbers for use in consumer transactions
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control
WO2001011515A2 (en) * 1999-05-28 2001-02-15 Spendcash.Com, Inc. Method and system for making anonymous electronic payments on the world wide web

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002019234A1 (en) * 2000-08-29 2002-03-07 Chijioke Uzo Method and apparatus for secure electronic payments
US6938019B1 (en) * 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
US7734527B2 (en) 2000-08-29 2010-06-08 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
EP1484702A1 (en) * 2002-02-25 2004-12-08 Hiroshi Tatsuki Charging method, information system, and program
EP1484702A4 (en) * 2002-02-25 2005-04-13 Hiroshi Tatsuki Charging method, information system, and program
FR2840434A1 (en) * 2002-05-31 2003-12-05 Anne Marie Etcheverry AUTHENTICATION AND VIRTUAL AND / OR REAL PAYMENT DEVICE AND IMPLEMENTATION METHOD
WO2003102714A2 (en) * 2002-05-31 2003-12-11 ETCHEVERRY, Sébastien Virtual and/or real payment and authentication device and method of using same
WO2003102714A3 (en) * 2002-05-31 2004-04-01 Anne-Marie Etcheverry Virtual and/or real payment and authentication device and method of using same
WO2004051529A1 (en) * 2002-11-29 2004-06-17 Smart Voucher Plc Electronic processing system
US7680712B2 (en) 2002-11-29 2010-03-16 Smart Voucher Plc Electronic processing system
WO2004066223A1 (en) * 2002-12-18 2004-08-05 Thierry Baillie System, access card or prepayment method for internet
CN101189629A (en) * 2005-01-26 2008-05-28 H·K·蔡 Fraud-free payment for internet purchases
WO2006117695A3 (en) * 2005-01-26 2007-04-19 Heng Kah Choy Fraud-free payment for internet purchases
US8740069B2 (en) 2005-01-26 2014-06-03 Heng Kah Choy Fraud-free payment for internet purchases
GB2428126B (en) * 2005-07-08 2010-05-12 Secoren Ltd System and method for processing transactions
GB2428126A (en) * 2005-07-08 2007-01-17 Secoren Ltd System for processing transactions
US8336763B2 (en) 2005-07-08 2012-12-25 Secoren Limited System and method for processing transactions
GB2432031A (en) * 2005-08-30 2007-05-09 Harold Prianne Anura Wijetunge Cash transfer from one mobile phone to another with access to cash instantly.
GB2432031B (en) * 2005-08-30 2010-01-20 Wijetunge Harold Prianne Anura The process for cash transfer from one mobile phone to another with access to cash instantly
US20120330846A1 (en) * 2011-06-27 2012-12-27 Accenture Global Services Limited Dynamic electronic money
CN103093360A (en) * 2013-01-09 2013-05-08 费兆雄 Merchandise anti-counterfeiting method and merchandise anti-counterfeiting system
EP3369062B1 (en) * 2015-10-30 2022-08-31 ID Loop AB Method for payment with a cash card
US11461758B2 (en) 2015-10-30 2022-10-04 Id Loop Ab Method for payment with cash card
EP3226191A1 (en) * 2016-04-03 2017-10-04 Trinkaus, Hans Alternate instrument of payment, highly personalized, weak personalized or no personalization

Also Published As

Publication number Publication date
AUPQ608000A0 (en) 2000-03-30

Similar Documents

Publication Publication Date Title
US8219474B2 (en) Method and system for distributing and activating a non-personalized purchase card
US6330544B1 (en) System and process for issuing and managing forced redemption vouchers having alias account numbers
US8200575B2 (en) Secure electronic payment system and methods
US20030004828A1 (en) Prepaid card authorization and security system
US7464861B2 (en) Partitioned credit system
US20090254484A1 (en) Anon virtual prepaid internet shopping card
US20020111918A1 (en) IC card transaction system, electronic wallet transaction apparatus and IC card therefor
US20070226152A1 (en) System and method for anonymous transactions and conveyances
US8434791B2 (en) Lottery transaction mechanisms
PL179928B1 (en) Method of carrying on open lectronic trade
US20040153410A1 (en) Anonymous payment system and method
CN101790743A (en) Dispose the system and method for multifunction transaction
US7356502B1 (en) Internet based payment system
AU2020102988A4 (en) Payment method and system for pledge-payable online trading
WO2001067407A1 (en) Electronic commerce payment system
US20220027902A1 (en) Decentralized system for fractionalized tokens
US10210715B2 (en) Lottery transaction mechanisms
EA006838B1 (en) Payment card and method
GB2359652A (en) Electronic payment system
GB2360866A (en) Online payment method
KR100473737B1 (en) electronic commerce method utilizing internet
US20020095374A1 (en) Method and apparatus for processing cash payments for electronic and internet transactions
US20160217644A1 (en) Lottery transaction mechainsm
KR20010047113A (en) Method for manufacturing and delivering products printed on paper using internet
JP3527176B2 (en) How to vote and transfer winnings using a debit card

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

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

Ref country code: JP