AU773105B2 - An on line system for selling goods and services - Google Patents

Description

S&FRef: 536239

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT

ORIGINAL

Name and Address of Applicant: Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha 30-2, Shimomaruko 3-chome, Ohta-ku Tokyo 146 Japan Hiren Patel and Sue-Ken Yap Spruson Ferguson St Martins Tower,Level 31 Market Street Sydney NSW 2000 An On Line System for Selling Goods and Services ASSOCIATED PROVISIONAL APPLICATION DETAILS [33] Country [31] Applic. No(s) AU PQ5852 [32] Application Date 25 Feb 2000 The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5815c

'I

-1- AN ON LINE SYSTEM FOR SELLING GOODS AND SERVICES Technical Field of the Invention The present invention relates generally to the field of on-line systems for sale and purchasing of goods and services and in particular, to token based transaction systems.

Background Art Present systems supporting sale and purchase of goods and services by electronic means typically do not provide the purchaser with a physical token evidencing a purchase. (The term "goods" will hereinafter be used to denote either goods or services, unless explicitly noted otherwise.) In the event that the vendor of the goods provides the goods directly to the purchaser, this is generally acceptable, since the purchase record is available at the point of distribution of the goods. In the event, however, that the goods are provided by a third party (hereinafter referred to as the "purveyor"), then details of the purchase record must be conveyed by the vendor to appropriate purveyors. If transfer of "the appropriate information by the vendor to the purveyors is inaccurate, or delayed, then .ooo•i the purchaser can be faced with a failure of service when attempting to take delivery of .o goods.

Purchase of goods using the aforementioned method also has the disadvantage o.

that the purchaser, having no physical proof of purchase, has a perception of being at a disadvantage, and this acts as an impediment to the growth of electronic commerce.

Furthermore, present systems for selling goods electronically are inflexible, and S-do not provide the purchaser with the flexibility to alter an order when taking delivery of the purchased goods.

the purchased goods.

180101; 12:46; 12/02/01;03:07 PM 536239AU.doc -2- Disclosure of the Invention It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

According to a first aspect of the invention, there is provided a system for token s based pre-purchase and purveying of specific goods from a plurality of types of goods, said system comprising: a payment token receiving means for receiving, by a vendor from a purchaser, a payment token for said specific goods; a rights token provision means, responsive to receipt of the payment token by the payment token receiving means, for providing to said purchaser, a smartcard upon which has been programmed a rights token unit which represents a specific right to said specific pre-purchased goods; purveyor processing means comprising a smartcard reader adapted to (i) interface with said smartcard and (ii) provide a user interface by means of which said S 15 corresponding rights token unit can be selected, wherein upon selection of said corresponding rights token unit, said pre-purchased specific goods corresponding to said S•selected rights token unit are purveyed.

According to another aspect of the invention, there is provided a system for S token based, on-line pre-purchasing and purveying of specific goods, in which said 20 specific goods are transferred throughout said system between at least a vendor of a right e to said goods, a purchaser of said specific goods, and a purveyor of said specific goods, said system comprising: a network supporting data communications between the purchaser and the vendor; (ii) vendor processing means comprising: 010304 536239au.doc -3payment token receiving means for receiving a payment token in exchange for said specific goods being pre-purchased by said purchaser; and rights token unit transmitting means for transmitting, to said purchaser, a rights token unit representing a right to said specific pre-purchased goods; (iii) purchaser processing means comprising: payment token transmitting means for transmitting a payment token corresponding to said specific pre-purchased goods; rights token unit receiving means for receiving, from the vendor, said rights token unit representing the right to said specific pre-purchased goods; and smartcard recording means for recording said rights token unit on a programmable smartcard; and (iv) purveyor processing means comprising a smartcard reader adapted to interface with said smartcard, and further adapted to authenticate a correspondence i between a user selected rights token unit and corresponding said specific pre-purchased 15 goods, whereby upon a positive authentication, the purveyor purveys said specific prepurchased goods to the purchaser.

According to another aspect of the invention, there is provided a method for token based pre-purchase and purveying of specific goods from a plurality of types of goods, said method comprising steps of: 20 receiving, by a vendor from a purchaser, a payment token for said specific goods the specific goods thereby being pre-purchased; providing to said purchaser, a smart card upon which has been programmed a rights token unit which represents a specific right to said specific pre-purchased goods; interfacing, by a smart card reader with said smart card; and 010304 536239au.doc purveying, upon selection of said corresponding rights token unit, said specific pre-purchased goods specifically corresponding to said selected rights token unit.

According to another aspect of the invention, there is provided a method for token based, on-line pre-purchase and purveying of specific goods from a plurality of types of goods, in which method said specific goods are transferred throughout said system between at least a vendor of a right to said goods, a purchaser of said goods, and a purveyor of said goods, said method comprising: pre-purchasing, by the purchaser, of specific goods purchasable from said vendor, said pre-purchasing being performed using a network supporting data communications between the purchaser and the vendor; communicating, by the purchaser to said vendor, of a payment token in exchange for said specific pre-purchased goods; conveying, by the vendor to the purchaser, of a rights token unit representing a •specific right to said specific pre-purchased goods; 15 programming, by the purchaser, of the rights token unit onto a programmable smartcard configured as a rights token unit carrier; 1. "1 presenting, by the purchaser to the purveyor of said pre-purchased goods, of a selected rights token unit; #Zof authentication, by the purveyor, of the selected rights token unit in respect of °o 20 corresponding said specific pre-purchased goods; and purveying, by said purveyor to said purchaser, upon a positive authentication, of said pre-purchased goods.

According to another aspect of the invention, there is provided a rights token unit carrier for use in a system for on-line pre-purchase and purveying of specific goods from 010304 536239au.doc a plurality of types of goods, the rights token unit carrier being a programmable smartcard comprising: an electronic apparatus, adapted to interface with a smartcard programmer/reader, said apparatus being capable of storing, and communicating a rights token unit; and one or more icons, visibly printed on a surface of the smartcard, said one or more icons comprising pictorial representations of corresponding rights token units; wherein the rights token unit is conveyed to the smartcard dependent upon a payment token in respect of pre-purchasing a specific one of a plurality of goods being received by the system and adapted to be selected by a purveyor processing means, dependent upon selection of a corresponding one of the icons, to enable the specific pre-purchased goods to be purveyed.

According to another aspect of the invention, there is provided a computer ol• readable memory medium for storing a program for a system which performs token based 15 pre-purchase and purveying of specific goods from a plurality of types of goods, said o :program comprising: o0 code for a receiving step for receiving, by a vendor from a purchaser, a payment token for a specific one of the plurality of goods, the specific goods thereby being preo:00 purchased; S 20 code for a providing step for providing to said purchaser, a smart card upon 0•o• which has been programmed a rights token unit which represents a specific right to said specific pre-purchased goods; code for an interfacing step for interfacing, by a smart card reader with said smart card; and 010304 536239audoc 010304 536239au.doc -6code for a purveying step for purveying, upon selection of said corresponding rights token unit, said specific pre-purchased goods specifically corresponding to said selected rights token unit.

According to another aspect of the invention, there is provided a computer readable memory medium for storing a program for apparatus which performs on-line pre-purchasing and purveying of goods, in which said goods are transferred throughout said system between at least a vendor of a right to said goods, a purchaser of said goods, and a purveyor of said goods, said program comprising: code for a pre-purchasing step for pre-purchasing, by the purchaser, of specific goods purchasable from said vendor, said pre-purchasing being performed using a network supporting data communications between the purchaser and the vendor; code for a communicating step for communicating, by the purchaser to said vendor, of a payment token in exchange for said specific pre-purchased goods; code for a conveying step for conveying, by the vendor to the purchaser, of a S 15 rights token unit representing a right to said specific pre-purchased goods; 0 code for a programming step for programming, by the purchaser, of the rights 6.

token unit onto a programmable smartcard configured as a rights token unit carrier; code to support a presenting step for presenting, by the purchaser to the purveyor 0:oo of said pre-purchased goods, of a selected rights token unit; 20 code for a authentication step for authentication, by the purveyor, of the selected rights token unit in respect of corresponding pre-purchased goods; and code to support a purveying step for purveying, by said purveyor to said purchaser, upon a positive authentication, of said pre-purchased goods.

010304 536239au.doc -6a Brief Description of the Drawings A preferred embodiment of the present invention will now be described with reference to the drawings, in which: Fig. 1 shows a block diagram of a system in accordance with a preferred embodiment of the invention; Fig. 2 depicts a business process flow representation applicable to the system in Fig. 1; Figs. 3 and 4 depict an arrangement by which the business process flow of Fig. 2 can be practiced; Fig. 5 depicts a process for crediting tokens on a smart card; *o *000 010304 536239au.doc -7- Fig. 6 depicts a process for debiting tokens on a smart card; Fig. 7 shows a smartcard which can be used in the embodiment of Fig. 1; Fig. 8 shows an embodiment of a smartcard reader; and Fig. 9 is a schematic block diagram of a general purpose computer upon which the preferred embodiment of the present invention can be practiced.

Detailed Description including Best Mode Where reference is made in any one or more of the accompanying drawings to steps and/or features which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including" and not "consisting only of'. Variations of the word comprising, such as "comprise" and "comprises" have corresponding meanings.

Fig. 1 shows a block diagram of a system in accordance with a preferred .,.embodiment of the invention in which three parties being a purchaser 102 of goods, a vendor 108 of goods, and a purveyor 116 of goods, are able to communicate electronically by means of a network 100, to which they are connected by communication paths 128, 126 and 124 respectively. From a commercial perspective, the purchaser 102 is able to purchase a right to specified goods from the vendor 108, and can take delivery of the specified goods from the purveyor 116. The vendor 108 and the purveyor 116 are, for generality, depicted as separate entities in the figure, however both the vending and the purveying functions can reside within a single entity.

The purchaser 102 has at his disposal a personal computer or equivalent customer premises equipment 104, by means of which communications can be 180101; 12:46; 12/02/01; 03:07 PM 536239AU.doc -8established with a corresponding PC 110 belonging to the vendor 108. The PC 104 can equivalently be replaced by another device such as a television set-top-box (TV-STB), an Intemrnet appliance, a mobile telephone, and so on, if the device is provided with suitable interfaces. The vendor's PC 110 supports a database (not shown) containing data describing goods for sale, and associated details such as price, delivery time and so on.

The vendors PC 110 is connected to a smartcard reader 112.

As already noted, the vendor 108 can in one case, sell a right to the goods, and also supply the goods. Alternatively, the vendor 108 can sell the right to the goods, while a purveyor supplies the goods. These alternatives are depicted by boxes 114 and 122.

The purchasers PC 104 is connected to a smartcard printer/programmer 106.

The purchaser 102 views, or browses, the vendor database (not shown), and can select designated goods by giving appropriate commands by means of the purchaser PC 104, which conveys these commands to the vendor's PC 110 using the network 100, and the network connections 128 and 126. A certification process (not shown) is preferably incorporated into the system, in order to ensure that the customer is, in fact, viewing the •goods and services made available by the vendor, and is not instead viewing goods and o 0services offered for sale by a third party who is (fraudulently) misrepresenting themself electronically as the vendor. The purchaser 102 also "makes payment" by providing a 0.0 payment token, using the same communication means. Such payment tokens can, for 20 example, comprise credit card details and passwords etc. provided to the vendor 108. The vendor 108 thereafter provides relevant commands by means of the vendor PC 110, these o: commands being communicated to the purchaser's PC 104 by means of the network 100 .o and network connections 126 and 128. These aforementioned vendor commands result in a "rights token" being provided to the purchaser 102, by transfer of data to a smartcard which has been inserted previously into the purchaser's smartcard printer/programmer 180101; 12:46; 12/02/01;03:07 PM 536239AU.doc -9- 106. A non-repudiation process (not shown) is preferably incorporated into the system, in order to ensure that the vendor cannot deny having provided the rights token. Nonrepudiation can typically be provided by ensuring that the rights token data is encrypted by the vendor using his private key. In such a case, the vendor is prevented from denying his previous provision of the rights token, since application by the purchaser of a corresponding public key to the encrypted rights token "proves" that the vendor did, in fact, provide the rights token. Summarising at this point, the purchaser 102 has purchased the right to specified goods from the vendor 108, and has "paid" for these goods by providing a payment token. The vendor 108 has in turn provided a rights token to the purchaser 102, this rights token being programmed onto a smartcard by means of the purchasers PC 104.

In the case where the vendor 108 does not provide the goods themselves, the purveyor 116 performs this function. The purveyor 116 has a PC 118 connected by means of a connection 124 to the network 100, and accordingly is able to communicate electronically with the vendor 108. The purveyors PC 118 is connected to a smartcard reader 120, and the purveyor 116 has actual possession of the specified goods as depicted :by a box 122.

Once the rights token has been printed onto the purchaser's smartcard, the •oooo S purchaser is able to take possession of the goods by inserting the programmed smartcard 20 into one of the smartcard readers, 112, 120 the choice of which reader being dependent 00 upon who provides the goods, the vendor 108 or the purveyor 116. In the event that the vendor 108 provides the goods, the purchaser 102 inserts the smartcard into the reader .i 112, and thereafter takes possession of the goods 114 from the vendor 108. If, however, the goods are held by the purveyor 116, then the purchaser 102 inserts the smartcard into the reader 120, and thereafter takes possession of the goods 122 from the purveyor 116.

180101; 12:46; 12/02/01;03:07 PM 536239AU.doc Payment by the purchaser 102 to the vendor 108 can be made in a number of different ways. For example, payment can be made at the point of acquisition of the goods, by means of a credit card or cash transaction. In this event, payment is made when the purchaser 102 inserts his smartcard into one of the smartcard readers 112, 120.

Alternately, payment can be made by transfer of credit card details at the time of purchase of the right to the goods as previously described. In yet a further example, payment can be made using a pre-established account, or via prepayment registered on the smartcard.

Accordingly, it is seen that a wide variety of payment mechanisms are possible, the aspect of payment able being linked, or alternatively decoupled, as desired, from the rights token itself, which is programmed onto the smartcard.

The purchaser 102 can make multiple purchases from different vendors in a single purchasing session. In this event, the vendor 108 in Fig. 1 is regarded as a plurality of vendors, and similarly the purveyor 116 is regarded as a plurality of purveyors. The purchaser 102 can successively establish contact with each of the plurality of vendors 15 108, and make a series of transactions, in which a rights token in respect of each completed transaction is programmed onto the purchasers smartcard by means of the i :purchaser's smartcard printer/programmer 106. For example, the purchaser can purchase an airline ticket, a taxi voucher, a hotel room and meals, each being represented by a .ooooi corresponding rights token programmed onto a single smartcard. In a preferred 20 embodiment, icons corresponding to each of these goods are printed on the card, and furthermore, rights token information is programmed into the card itself. This is discussed in more detail in regard to Fig. Although the above description considers the purchaser 102, the vendor 108 and the purveyor 116 all interacting over the network 100, an alternate arrangement can be implemented. In this case the purchaser 102 is able to present a smartcard, as shown by a 180101; 12:46; 12/02/01; 03:07 PM 536239AU.doc -11dashed arrow 130, to the vendor 108, which in this case is a vending machine. The vending machine has a visual display (not shown) of various goods and services, from which the purchaser 102 can make selections. Payment can be made by the purchaser as described previously in relation to Fig.l, and rights tokens can be transferred to the purchaser's smartcard. The purchaser can, thereafter, use the rights token on the smartcard to take delivery of the purchased goods and services from one or more purveyors as already described in relation to Fig. 1.

Fig. 2 depicts a business process flow representation applicable to the system described in Fig. 1. The Figure depicts three parties, namely a customer 200, a vendor 202, and a purveyor 228 of goods. The customer 200 in a first sub-process 204 views and considers goods and services for sale using a browser on a PC 104 as previously described. Thereafter, in a sub-process 206 the purchaser 200 purchases a right to a specific item. In the present embodiment, the customer 200 then transmits a payment token in a sub-process 208, where this can be accompanied by a provision of a personal identity number (PIN) 210. Details of the goods selected, payment and PIN details are oooo° •conveyed to the vendor 202 as depicted by arrows 236, 232 and 234 respectively.

Thereafter, the vendor 202 transmits a corresponding rights token to the customer as depicted by a sub-process 212. The vendor 202 instructs the purveyor of goods 228 to •eeo• reserve the specified goods as indicated by a sub-process 230. The rights token 20 transmitted by the vendor 202 is credited, ie. programmed onto, the purchasers smartcard by a sub-process 214. This is described in more detail in relation to Fig. 5. To summarise at this point, the purchaser 200 has "gone shopping" for goods, selected and paid for a selection thereof, and has received rights tokens in a physical (ie electronic) form, on a smartcard in the customer's possession.

180101; 12:46; 12/02/01;03:07 PM 536239AU.doc -12- At some later time, the purchaser 200 inserts the programmed smartcard into a smartcard reader at a location where the goods are being taken delivery of as depicted by a sub-process 216, and selects an appropriate icon thereby presenting a corresponding rights token to the purveyor. The purveyor 228 verifies and authenticates the rights token in conjunction with verifying a PIN 220 provided by the customer 200 as shown in a subprocess 218. Thereafter, the purveyor 228 debits the appropriate rights tokens on the smartcard in a sub-process 222 (as described in more detail with reference to Fig. 6) while the smartcard is in the smartcard reader 112, 120, and delivers the appropriate goods in a sub-process 224. The purchaser 200 takes possession of the desired goods in a subprocess 226.

Figs. 3 and 4 depict an arrangement by which the business process flow of Fig. 2 can be practiced. Fig. 3 shows a first fragment 800 of the aforementioned process, and it is noted that the process 800 involves interaction between a customer 802 and a vendor 804. In a first step 808, the customer 802 logs into a vendor site, typically using a web browser application running on the PC 104 (see Fig. The vendor 804 would typically maintain a site on the World Wide Web, either on the vendor PC 110 (see Fig. or alternatively on a web server maintained by an Internet service provider used by the vendor 804. The vendor 804 would use the aforementioned site to present goods and ••ooo S: services for sale, and also to provide additional information of use to potential and actual customers.

After the customer 802 logs on to the vendor site in the step 808, the customer 802 selects a desired item in a step 810, after which the customer 802 sends an item ID code to the vendor 804 in a step 812. From a practical perspective, the customer 802 selects the item in the step 810 typically by pointing to the desired item using a pointing device such as a mouse, and clicking a mouse button in order to perform the selection.

180101; 12:46; 12/02/01;03:07 PM 536239AU.doc -13 Furthermore, the customer 802 would typically send the item ID code in the step 812 by using the pointing device to point to a "BUY" icon on a displayed shopping page on the vendor web site, and again clicking the mouse button to indicate that the customer 802 actually intends to purchase the particular selected item.

After the customer 802 has sent the item ID code to the vendor in the step 812, this ID is received by the vendor 804 in a step 814. The customer 802 also sends credit card details in a step 816, these details typically comprising a credit card number, a credit card expiry date, and a dollar amount which is appropriate to cover the selected item. The vendor 804 receives the aforementioned credit details in a step 818.

Once the vendor 804 has received both the item ID code, and the associated credit card details, the vendor 804 correlates the item ID and the dollar amount in a step 820. Assuming that the correlation is positive, ie. that no inconsistencies are identified in the step 820, the vendor 804 formats an appropriate rights token in a step 822, after which the rights token is transmitted to the customer 802 in a step 826. The customer 802 15 receives the rights token in a step 824, after which, as depicted by the arrow 238, the S:"i rights token is credited to the customer's smartcard, as depicted in more detail in regard to :Fig. Fig.4 shows a second fragment 900 of the business process depicted in Fig. 2, 0 and in particular that part of the process which commences when the customer (now designated by the reference numeral 902) enters the smartcard into a smartcard reader, as depicted in a step 908. It is noted that the step 908 is shown in dashed format, to indicate .that this is a physical process rather than a data processing step. The smartcard reader, in 0* 0 the present instance, belongs to a purveyor 906, and the smartcard reader reads smartcard data from the inserted smartcard in a step 910. Thereafter, in a step 914, the purveyor 906 (ie. the smartcard reader being used by the purveyor) reads PIN (Personal Information 180101; 12:46; 12/02/01; 03:07 PM 536239AU.doc 14- Number) information which is provided by the customer 902 in a step 912. In the step 914 the purveyor 906 reads the PIN and authenticates the PIN with respect to the smartcard data which has been read in the step 910.

The customer 902 sends the item ID code in a step 916, and in a step 918, the purveyor 906 receives the item ID code. The customer 902 would typically send the item ID code in the step 916 by pressing on an appropriate icon on the smartcard which has been inserted into the smartcard reader 120 (see Fig. 1).

On the assumption that the authentication process has proved satisfactory and that the received item ID code is appropriate (ie. the ID is consistent with a corresponding reserved stock item), the purveyor 906 adjusts a stock level entry in the relevant purveyor accounting system (not shown) in a step 920. Returning, for a moment, to Fig. 2 it will be recalled that the goods and/or services purchased by the customer 200 were reserved in a step 230, thereby ensuring that the purveyor 906 has the necessary stock in order to satisfy the customer when the customer sends the item ID code in the step 916.

After the purveyor 906 has adjusted the stock level in the step 920, the purveyor ooo.

•906 debits the rights token in a step 222 (see Fig. 6 for more detail). Thereafter, in a step 924, the purveyor 906 sends a delivery notice to the store where the desired item is physically kept, instructing the store to prepare to prepare the item for physical transfer to the customer 902. Thereafter in a step 926 the purveyor 906 sends delivery details (ie.

displays the address of the store) to the customer 902, after which the customer 902 withdraws the smartcard from the reader in a step 928.

S. The step 928 is shown in dashed format to indicate that this is a physical rather than a data processing step. The customer 902 then physically goes to the store to take delivery of the desired item.

180101; 12:46; 12/02/01;03:07 PM 536239AU.doc Fig. 5 depicts a process for crediting tokens on a smartcard. The process 214 (see Fig. 2) is depicted in Fig. 5 by a dashed box 214, and commences with a step 600 in which prices for goods and/or services purchased by the purchaser are confirmed.

Thereafter, in a step 602, the payment provided by the purchases is confirmed, and checked against the aggregate price for the selected goods and services. In a following step 604, rights token data is prepared, this data reflecting the goods and/or services purchased. It is noted that each rights token is individually associated with the corresponding specific goods and/or services, as described in more detail with reference to Fig. 7. Thereafter, in a step 606, the rights tokens are written to the smartcard, thereby crediting the rights tokens to the smartcard for use by the purchaser. The crediting process continues, as depicted by a dashed arrow, to a step 216 as shown in Fig. 2.

Fig. 6 depicts a process for debiting tokens on a smartcard. The debiting process 222 (see Fig. 2) is depicted by a dashed box in Fig. 6, and commences with a step 700 in which the price for selected goods and/or services is confirmed. As previously noted in respect to Fig. 2, the desired goods and/or services are selected by the purchaser pressing ooooe •appropriate icons which represent the desired goods and/or services. Thereafter, in a step 702, the particular rights token selected by the user is checked for conformance with the selected goods and services. Thereafter, in a step 704, the rights token associated with the o••oo selected goods and/or services are deleted from the smartcard.

Fig. 7 depicts a smartcard which can be used in the embodiment described in go Figs. 1 to 4. The smartcard 300 is seen to comprise printed icons 302 on its upper face, and has a microprocessor and associated memory 304 embedded on an opposite face of S-the card. When the purchaser 200 has purchased specified goods, the vendor 202 transmits an appropriate rights token in a sub-process 212 (see Fig. and in addition sends information relating to a visual aspect of each icon to the purchaser 200. The 180101; 12:46; 12/02/01;03:07 PM 536239AU.doc -16purchasers PC 104 runs a software application which prints the icons 302 onto the smartcard 300, and the application also programs the rights token information into the microprocessor 304, these operations being performed by the smartcard printer/programmer 106. The icons 302 comprise either text, or preferably, graphic information representing the corresponding purchase. Accordingly, purchase of an air ticket results in the icon 302 being a graphic representation of a plane and so on. In the preferred embodiment, the purchaser 102 inserts the smartcard 300 into a smartcard reader 112, 120 at the point of acquisition of the goods. Icons 302 on the card 300 are visible through a transparent cover of the smartcard reader 112, 120 (see the description relating to Fig. 8 for more detail). By touching the transparent cover above the appropriate icon, the purchaser indicates a particular service to be acquired, this service already having been purchased. As noted in regard to Fig. 2, PIN information can be required and provided at this point in the proceedings.

Each of the various rights tokens are individually associated with corresponding specific goods, and are also typically associated with a specific icon on the upper face of o ooe •the smart card 300. Accordingly, the icon 302 is associated with an air ticket which the purchaser has purchased, and is also associated with a corresponding rights token for the air ticket. On the other hand, the icon 306 is associated with a three night hotel booking •eo•¢ which the purchaser has purchased, and is also associated with a corresponding rights token for the hotel booking. A rights tokens is not a fungible medium of exchange like cash, but is, in, contrast associated in a fixed manner to specific goods. Cash is a fungible medium of exchange which can be applied equally to the air ticket and the hotel booking provided that the air ticket costs the same as the hotel booking. Even if such price equality exists however, the rights token for the air ticket cannot be applied to the hotel booking, and neither can the rights token for the hotel booking be applied to the air ticket.

180101; 12:46; 12/02/01; 03:07 PM 536239AU.doc -17- Turning to Fig. 8, the smartcard 300 is inserted as depicted by an arrow 406 into a smartcard reader 400 through an aperture slot 402. The reader 400 is provided with a transparent upper window 404 through which the icons 302 are visible. The transparent window 404 is touch sensitive, and when the purchaser presses on the window 404 above the icon 302, the reader 400 is able to identify which icon is being pressed, by communicating with the smartcard microprocessor 304.

The flexibility of the disclosed embodiment can be illustrated by the following example. A purchaser 102 has established a connection by means of the network 100 (see Fig. 1) to a vendor 108 who is a travel agent. The purchaser 102 buys a travel package comprising a three night hotel stay on Hamilton Island, with air travel being provided by Ansett Airlines. The purchaser 102 also subscribes to a diving course for the first day of the holiday, and a paragliding course for the second day. The purchaser 102 is, however, undecided as to whether to purchase further optional aspects of the travel package, and requests an option to purchase such items at the time of use. The vendor 108 conveys rights tokens to the purchasers PC 104 and thereafter to the purchaser's smartcard 300, •°°oo °these rights tokens providing additional icons which can be used to purchase the optional too

S

services at the hotel (which is a purveyor 116 of some of the services).

Upon arriving at the hotel, the purchaser 102 elects to have breakfast delivered to the room by selecting a breakfast icon 302, after inserting the card 300 into the card reader 400, this reader being situated in the hotel room. Later in the day, at the diving companies office (this company being another purveyor 116 of other services 116), the purchaser 102 decides not to take a four hour extension diving course, and accordingly oo does not select the appropriate icon on the smartcard 300. The purchaser 102 does, however, elect to purchase photographs from the preliminary diving course, and does so by selecting the appropriate icon 302, after the smartcard 300 has been inserted into a 180101; 12:46; 12/02/01;03:07 PM 536239AU.doc -18reader 400 at the diving office. Provided that the purchaser purchased the rights token for the four hour extension diving course as an option, the purchaser is able to obtain a refund from the vendor for the unused rights token. If, as is likely on the other hand, the rights token for the three night hotel stay on Hamilton Island has not been purchased as an option, then the purchaser will not be able to obtain a refund for the three night hotel stay if the purchaser decides to stay at a different hotel.

The method of on-line token based sale and purchasing is preferably practiced using a conventional general-purpose computer system 500, such as that shown in Fig. 9, wherein the processes of Figs. 2-6 can be implemented as software, such as an application program executing within the computer system 500. In particular, the steps of on-line token based sale and purchasing are effected by instructions in the software that are carried out by the computer. The software can be divided into two separate parts, one part for carrying out the on-line token based sale and purchasing procedures, and another part to manage the user interface between the latter and the user. The software can be 0:0 0006 stored in a computer readable medium, including the storage devices described below, for oooee °example. The software is loaded into the computer from the computer readable medium, O°O0o *o% and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the #oo0o9 0 computer program product in the computer preferably effects an advantageous apparatus to,20 for on-line token based sale and purchasing in accordance with the embodiment of the 0 invention.

ss The computer system 500 comprises a computer module 501, input devices such 0S 0o es as a keyboard 502, mouse 503 and smartcard reader 530, output devices including a smartcard programmer/printer 515 and a display device 514. A Modulator-Demodulator (Modem) transceiver device 516 is used by the computer module 501 for communicating 180101; 12:46; 12/02/01; 03:07 PM 536239AU.doc -19to and from a communications network 520, for example connectable via a telephone line 521 or other functional medium. The modem 516 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer module 501 typically includes at least one processor unit 505, a memory unit 506, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output interfaces including a video interface507, and an I/O interface513 for the keyboard502 and mouse503 and optionally ajoystick (not illustrated), and an interface 508 for the modem 516. A storage device 509 is provided and typically includes a hard disk drive 510 and a floppy disk drive 511. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 512 is typically provided as a non-volatile source of data. The components 505 to 513 of the computer module 501, typically communicate via an interconnected bus 504 and in a manner resulting in a conventional mode of operation of the computer ooooo 15 system 500 known to those in the relevant art. Examples of computers on which the S"embodiments can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom.

Typically, the application program of the preferred embodiment is resident on the hard disk drive 510 and read and controlled in its execution by the processor 505.

Intermediate storage of the program and any data fetched from the network 520 may be accomplished using the semiconductor memory 506, possibly in concert with the hard disk drive 510. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 512 or 511, or alternatively may be read by the user from the network 520 via the modem device 516.

Still further, the software can also be loaded into the computer system 500 from other 180101; 12:46; 12/02/01; 03:07 PM 536239AU.doc computer readable medium including magnetic tape, a ROM or integrated circuit, a magneto-optical disk, a radio or infra-red transmission channel between the computer module 501 and another device, a computer readable card such as a PCMCIA card, and the Intemrnet and Intranets including email transmissions and information recorded on websites and the like. The foregoing is merely exemplary of relevant computer readable mediums. Other computer readable mediums may be practiced without departing from the scope and spirit of the invention.

The method of on-line token based purchasing may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of on-line token based purchasing. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

Industrial Applicability ooooo 15 It is apparent from the above that the embodiment of the invention is applicable S"to general manufacturing and service industries, and indeed to any industry where goods and/or services are purchased and/or sold.

The foregoing describes only one embodiment of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiment being illustrative and not restrictive.

180101; 12:46; 12/02/01;03:07 PM 536239AU.doc

Claims (12)

1. A system for token based pre-purchase and purveying of specific goods from a plurality of types of goods, said system comprising: a payment token receiving means for receiving, by a vendor from a purchaser, a payment token for said specific goods; a rights token provision means, responsive to receipt of the payment token by the payment token receiving means, for providing to said purchaser, a smartcard upon which has been programmed a rights token unit which represents a specific right to said specific pre-purchased goods; purveyor processing means comprising a smartcard reader adapted to (i) interface with said smartcard and (ii) provide a user interface by means of which said corresponding rights token unit can be selected, wherein upon selection of said corresponding rights token unit, said pre-purchased specific goods corresponding to said selected rights token unit are purveyed.

2. A system according to claim 1, further comprising: a network supporting data communications between at least one of the purchaser, the vendor and the purveyor; wherein at least one of: 20 the provision of the payment token by the purchaser to the payment token receiving means; (ii) the provision of the rights token unit from the rights token provision means to the smartcard; and (iii) the interfacing with said smartcard by the purveyor processing means; is performed electronically over the network. 010304 536239au.doc 22

3. A system for token based, on-line pre-purchasing and purveying of specific goods, in which said specific goods are transferred throughout said system between at least a vendor of a right to said goods, a purchaser of said specific goods, and a purveyor of said specific goods, said system comprising: a network supporting data communications between the purchaser and the vendor; (ii) vendor processing means comprising: payment token receiving means for receiving a payment token in 0 exchange for said specific goods being pre-purchased by said purchaser; and rights token unit transmitting means for transmitting, to said purchaser, a rights token unit representing a right to said specific pre-purchased goods; (iii) purchaser processing means comprising: payment token transmitting means for transmitting a payment token 5 corresponding to said specific pre-purchased goods; rights token unit receiving means for receiving, from the vendor, said rights token unit representing the right to said specific pre-purchased goods; and smartcard recording means for recording said rights token unit on a programmable smartcard; and 0 (iv) purveyor processing means comprising a smartcard reader adapted to interface with said smartcard, and further adapted to authenticate a correspondence between a user selected rights token unit and corresponding said specific pre-purchased goods, whereby upon a positive authentication, the purveyor purveys said specific pre- purchased goods to the purchaser. C 4@@ a. S a a S a a* S S C 010304 536239au.doc 23

4. A system according to any one of claims 1-3, wherein said smartcard, being configured as a rights token carrier, comprises: an electronic apparatus, adapted to interface with a smartcard programmer/reader, said apparatus being capable of storing, and communicating information relating to rights token units and spatial coordinate information describing spatial location information for one or more corresponding icons; and said one or more icons, visibly printed on a surface of the smartcard, said one or more icons comprising pictorial representations of the corresponding rights token units.

5. A system according to any one of claims 1-3, wherein said rights token unit consists of one or more of: a description of the specified goods; a reference to the specified goods; •0 an indication that the specified goods have been purchased; 0 15 a description of the vendor; 000.0: "a reference to the vendor; a description of the purchaser; a reference to the purchaser; .Personal Identification Number (PIN) information; 20 a description of the purveyor; oo a reference to the purveyor; and icon information, comprising one or more. of a pictorial representation of the rights token unit for printing on a surface of the smartcard, and spatial coordinate information describing the spatial location of the icon. 010304 536239au.doc 24

6. A system according to any one of claims 1-3, wherein said payment token comprises at least one of: credit card information enabling said purchaser to debit an account of the purchaser; and prepaid smartcard information enabling said purchaser to debit a prepaid smartcard account, said debit being balanced by decrementing prepaid credit information on the purchaser prepaid smartcard.

7. A method for token based pre-purchase and purveying of specific goods from a plurality of types of goods, said method comprising steps of: receiving, by a vendor from a purchaser, a payment token for said specific goods the specific goods thereby being pre-purchased; providing to said purchaser, a smart card upon which has been programmed a •rights token unit which represents a specific right to said specific pre-purchased goods; S• 15 interfacing, by a smart card reader with said smart card; and ooooo S•purveying, upon selection of said corresponding rights token unit, said specific S: pre-purchased goods specifically corresponding to said selected rights token unit. S.o.

8. A method for token based, on-line pre-purchase and purveying of 20 specific goods from a plurality of types of goods, in which method said specific goods are go• transferred throughout said system between at least a vendor of a right to said goods, a purchaser of said goods, and a purveyor of said goods, said method comprising: pre-purchasing, by the purchaser, of specific goods purchasable from said vendor, said pre-purchasing being performed using a network supporting data communications between the purchaser and the vendor; 010304 536239au.doc communicating, by the purchaser to said vendor, of a payment token in exchange for said specific pre-purchased goods; conveying, by the vendor to the purchaser, of a rights token unit representing a specific right to said specific pre-purchased goods; programming, by the purchaser, of the rights token unit onto a programmable smartcard configured as a rights token unit carrier; presenting, by the purchaser to the purveyor of said pre-purchased goods, of a selected rights token unit; authentication, by the purveyor, of the selected rights token unit in respect of corresponding said specific pre-purchased goods; and purveying, by said purveyor to said purchaser, upon a positive authentication, of said pre-purchased goods. A rights token unit carrier for use in a system for on-line pre-purchase 15 and purveying of specific goods from a plurality of types of goods, the rights token unit ooooo carrier being a programmable smartcard comprising: an electronic apparatus, adapted to interface with a smartcard programmer/reader, said apparatus being capable of storing, and communicating a rights token unit; and 20 one or more icons, visibly printed on a surface of the smartcard, said one or more oo icons comprising pictorial representations of corresponding rights token units; wherein S• the rights token unit is conveyed to the smartcard dependent upon a payment token in respect of pre-purchasing a specific one of a plurality of goods being received by the system and adapted to be selected by a purveyor processing means, dependent 010304 536239au.doc 26 upon selection of a corresponding one of the icons, to enable the specific pre-purchased goods to be purveyed. A computer readable memory medium for storing a program for a system which performs token based pre-purchase and purveying of specific goods from a plurality of types of goods, said program comprising: code for a receiving step for receiving, by a vendor from a purchaser, a payment token for a specific one of the plurality of goods, the specific goods thereby being pre- purchased; code for a providing step for providing to said purchaser, a smart card upon which has been programmed a rights token unit which represents a specific right to said specific pre-purchased goods; code for an interfacing step for interfacing, by a smart cardreader with said 0. smart card; and ooo* S 15 code for a purveying step for purveying, upon selection of said corresponding S.. rights token unit, said specific pre-purchased goods specifically corresponding to said selected rights token unit.

11. A computer readable memory medium for storing a program for oooo 20 apparatus which performs on-line pre-purchasing and purveying of goods, in which said o*o goods are transferred throughout said system between at least a vendor of a right to said goods, a purchaser of said goods, and a purveyor of said goods, said program comprising: 5555 code for a pre-purchasing step for pre-purchasing, by the purchaser, of specific goods purchasable from said vendor, said pre-purchasing being performed using a network supporting data communications between the purchaser and the vendor; 010304 536239au.doc -27- code for a communicating step for communicating, by the purchaser to said vendor, of a payment token in exchange for said specific pre-purchased goods; code for a conveying step for conveying, by the vendor to the purchaser, of a rights token unit representing a right to said specific pre-purchased goods; code for a programming step for programming, by the purchaser, of the rights token unit onto a programmable smartcard configured as a rights token unit carrier; code to support a presenting step for presenting, by the purchaser to the purveyor of said pre-purchased goods, of a selected rights token unit; code for a authentication step for authentication, by the purveyor, of the selected rights token unit in respect of corresponding pre-purchased goods; and code to support a purveying step for purveying, by said purveyor to said purchaser, upon a positive authentication, of said pre-purchased goods.

12. A system for token based, sale and purchasing of goods substantially as 15 described herein with reference to any one of the embodiments, as that embodiment is oooo• S•shown in the accompanying drawings. o•

13. A method of token based, sale and purchasing of goods substantially as described herein with reference to any one of the embodiments, as that embodiment is o 20 shown in the accompanying drawings. *.oo

14. A rights token unit carrier substantially as described herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings. 010304 536239au.doc -28- A computer readable memory medium for storing a program for apparatus which performs token based sale and purchasing of goods substantially as described herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings. DATED this fifth Day of March, 2004 Canon Kabushiki Kaisha Patent Attorneys for the Applicant SPRUSON FERGUSON i 010304 536239au.doc