AU729758B3 - Electronic commerce system and method - Google Patents

Description

AUSTRALIA

PATENTS ACT 1990

ORIGINAL

COMPLETE SPECIFICATION PETTY PATENT Invention Title: ELECTRONIC COMMERCE SYSTEM AND METHOD Name of Applicant: PETER NAGEL and CARLYLE NAGEL The following statement is a full description of this invention, including the best method of performing it known to me/us: 2 ELECTRONIC COMMERCE PAYMENT SYSTEM AND METHOD Field of Invention The present invention relates to a method and system for enabling payment for goods/services (which will hereinafter be termed "products") and, particularly, but not exclusively, to a method and system for facilitating product transactions taking place over a computer network.

Background of Invention One of the main hurdles to the uptake of commerce over a computer network such as the Internet, is the perceived lack of security. This leads to a reluctance to, for example, provide credit card details or other account details across the Internet, for fear of misappropriation by unauthorised persons and subsequent fraud. This is a great barrier to electronic commerce. Indeed, by far the vast majority of commerce is still carried out in the standard way. The vast potential for electronic commerce is, as yet, unrealised.

Many technical solutions to this perceived security problem have been attempted. These include digital signatures, complex encryption software, electronic cash, etc. The problem with such proposed solutions is that they are technical solutions and they are therefore always going to be vulnerable to persons who have the time and the intelligence to overcome the security provided. Even if such technical systems were totally secure, the public perception is always that they are going to be vulnerable.

People will therefore still be reluctant to take the risk of putting their account information on a public network.

Summary of Invention The present invention provides a system for 1 facilitating transactions for products taking place over a Lw L-7 3 computer network between vendors and users, the system comprising a trust entity computing system connectable to the computer network and including a database storing user delivery requirement information pre-specified to the trust entity by users, and user payment processing information associated with each user, and wherein to facilitate a transaction between a vendor and a user, the trust entity computing system is arranged to receive a user identifier from a vendor and to locate the delivery requirement information associated with the user identifier, whereby to enable delivery of the product the subject of the transaction in accordance with the delivery requirement information, and to locate the user payment processing information associated with the user identifier whereby to enable processing of payment to the vendor for the transaction, wherein, in order to enable delivery of the product in accordance with the delivery requirement information, the trust entity computing system is arranged to make the delivery requirement information available to the vendor providing the user identifier information.

The pre-specified delivery requirement information is preferably a delivery destination pre-specified by the user, and the requirement is for the product to be delivered to the pre-specified. delivery destination.

Preferably the identifier is a token, which preferably does not include any payment information or information on the delivery destination specified by the user, and which can be used by the user to facilitate a transaction for a product with any vendor who wishes to use the system. The identifier may be a simple code number. It may also be any other type of identifier, such as a retinal scan, finger print or voice print, for example. Any identifier which can be used with the system may be applied.

bIn use, the system user wishing to purchase products rom a vendor, provides the vendor with the identifier. The endor will then provide the identifier to the trust entity 4 computing system, note that the vendor may in some cases be the same as the trust entity. In an alternative embodiment, the trust entity is a separate third party and the user provides the identifier to a separate vendor who then separately provides the identifier to the trust entity computing system over a computer network. In a further embodiment the system is useful for a vendor managing a "portal" site on the Internet, acting as a portal to a plurality of vendors subscribing to the portal (known as a "colony"). In this case the portal vendor may be the same entity as the trust entity, and may manage the trust entity computing system.

Wherever the vendor is positioned, once the trust entity computing system is provided with the identifier, the system then locates the delivery destination information which has been pre-specified to the system by the system user (ie when the system user first subscribes to the system they are provided with the identifier in exchange for their delivery destination information, which is preferably kept securely within the system). The system then facilitates delivery of the product provided by the vendor to the specified destination. This may be done either by providing the address of the delivery destination to the vendor, (unnecessary in the case where the vendor is also the manager of the trust entity computing system).

The advantage of this system is that the product which is ordered by the system user will only be delivered to the specified delivery destination. If the identifier should be misappropriated by a non-authorised person, therefore, use of the identifier to facilitate a product transaction will only result in the product being delivered to the destination associated with the identifier. That is, the misappropriator will gain no advantage. The product will still be delivered to the authorised user of the Osystem. The authorised user can thus return the Smisappropriated product to the vendor, resulting in no damage to either party. Further, being aware of this system, there is no incentive for a thief to misappropriate the identifier. The system preferably does not allow the delivery destination to be altered for a transaction, so that a misappropriator cannot redirect a product to themselves. It is possible that delivery information could be changed, but only via a secure process which ensures that the user must be correctly identified before the information will be changed.

Preferably the system is arranged to operate to facilitate transactions occurring over the Internet.

Preferably, the system is Web-enabled. The identifier is preferably a token which can be provided over the Internet e.g. to a vendor website.

It is envisaged that the present system will promote Internet commerce. The system user is not concerned about security of the identifier, as misappropriation of the identifier does no good to the misappropriator. Of course, security is preferably applied, but is not essential.

In return for the provision of an identifier, the system also enables payment to the vendor utilising prestored user payment processing information (also accessible by way of the user identifier). The system may store credit card details of the user associated with the identifier, for example, to facilitate a credit card transaction by which the vendor is paid. This has the advantage that the user does not have to provide any payment details. They are kept securely by the system.

Both the payment information of the user and the user's identity may remain hidden from the vendor, so that an unscrupulous vendor cannot misappropriate credit card details.

The delivery requirement information may specify other delivery requirements than a delivery address to which a product is to be delivered. For example, a requirement may be that when the product is delivered to 6 the user, the user must provide the deliverer with a password which can be checked against the password provided by the trust entity to the deliverer. This would be particularly useful for the case where a user has ordered entertainment tickets and wishes to pick them up from the theatre, for example. Unless the password or other identifier provided by the user is correct, the user will not receive the product. An alternative requirement for the system would be to contact the user before confirming to the vendor that the transaction will be carried out.

A number of separate delivery requirement options may be stored by the system. For example, one delivery requirement option may be to deliver to a pre-specified delivery address, and another delivery requirement option may be for the user to provide a password before receiving the product. During a transaction, the system user may specify the particular delivery option to be used for the transaction. This may be done by, for example, providing a delivery requirement option identifier, such as an integer or or in addition to the user identifier. Any token may be provided to specify the delivery requirement option. The system may be arranged to automatically determine which delivery requirement option should be chosen. For example, if the product is an entertainment ticket, such as a theatre ticket, the system may automatically require that the delivery requirement option of the user providing a password to receive the product, should be implemented.

Where the user identifier is used over a computer network such as the Internet, it essentially acts as a "net identity", identifying the user for the purposes of all transactions taking place over the Internet. It provides security for the user as the "net identifier" cannot effectively be fraudulently used. The users "net identity" therefore remains secure to themselves. If somebody else attempts to misuse it, it will give them no advantage.

Where the delivery requirement information includes a delivery destination address to which the user wishes the product to be sent, there may be a plurality of delivery address options. The user may have available a delivery address option identifier in order to instruct the system to select between the delivery addresses.

Similarly, different payment options may be specified by a system user, eg. credit card, account, etc.

Again, this can be done by the addition of a further identifier or token together with the identifier, provided for the transaction.

Information stored in the trust entity computing system may also include a user defined flooring transaction value, over which value the system will not enable the transaction without first contacting the user eg by email or by telephone or by any other method. This provides some added control on the value of the transaction for the user.

Preferably, the database also stores a vendor identifier associated with each vendor. The trust entity system is preferably arranged to require the vendor to provide a vendor identifier before facilitating the transaction. In this way, the system can ensure that vendors are certified vendors. The system may also store payment information associated with the vendor to enable the vendor to be paid. For example, a vendor bank account information may be stored.

As the system has knowledge of user location, in the preferred embodiment, (delivery destination), there exists the potential for the system to calculate tax or duty payable on a transaction according to the destination of the user. Preferably, the trust entity system includes means for calculating and applying tax or duty to a transaction.

The provision or amendment of the delivery requirement information to the trust entity preferably requires a value judgement on security. That is, there is 8 a security requirement that a user must meet in order to have his delivery requirement information entered on the trust entity computing system. This avoids the possibility of a fraudster attempting to change the delivery requirement information without the user's knowledge. The value judgement on security can take many forms. For example, the value judgement may require a process of the user providing a secure password before the delivery requirement information can be changed.

It may require a user to attend at a trust entity physical location and provide them with identity information (such as a driving licence, passport, etc.).

Features and advantages of the present invention will become apparent from the following description of an embodiment thereof, by way of example only, with reference to the accompanying drawings, in which: Brief Description of Drawings Figure 1 is a schematic block diagram showing a system and process in accordance with an embodiment of the present invention; Figure 2 is an example of a user profile and Figure 3 is an example of transaction information.

9 Description of Preferred Embodiment Referring to Figure 1, there is illustrated an embodiment of system in accordance with the present invention comprising a Trust Entity Computing System 1, in this example being in the form of a computer system which is Web-enabled (ie including a server computer with Internet access). The System 1 also includes a database 4 which stores user delivery requirement information which has been pre-specified by a user 5 of the system. The database 4 also stores user payment processing information associated with the user 5 of the system to enable payment for a product transaction, and an identifier associated with each of the delivery and payment processing information for user 5. In operation, a user 5 who wishes to subscribe to the system provides the payment information and the delivery requirement information to the system 1 by a secure path 6, which may mean attending at an office manned by trust entity personnel, or may mean using conventional post or any other method. In return, system 1 generates an identifier in the form of a code number or any other number, which is kept by the user and also kept in database 4. In this embodiment, the delivery requirement information includes a requirement to deliver to a location address pre-specified by a user.

Figure 2 shows an example of information included in the database for the preferred embodiment of the system 1.

This includes the identifier code number 10 which is provided to the user in exchange for the destination and payment information, the user name 11, the mailing address 12, an e-mail address 13 for user, and contact details of the Internet Service Provider of the user 14.

It also includes payment options 15, in this case, there are three different payment options, numbered 1, 2 and 3. The user can therefore select which preferred payment option they wish to use for a particular transaction, by providing a payment option identifier (in this case an integer, 1, 2 or 3).

Similarly, options are provided for a number of different delivery destinations 16. Again, the user 5 may designate which delivery address option is to be used for a transaction, using a delivery destination option identifier (in this case an integer).

In this embodiment, there is also provided a delivery address 17 for software download, which will be used should software be the product which is the subject of the transactions. Software downloads may be for publications, music, computer programs, movies and more.

In this case, for example, the software is to be delivered to a proxy server which would usually be maintained by an ISP 7 to deliver to end user equipment Finally, a user specified "floor limit" 18 is also contained in the database 4. Any transaction which has a purchase value above this floor limit will need to be authorised by the user before the transaction is authorised by the system 1.

In operation, a user 5 who wishes to purchase products from vendors offering products for sale on the Internet 2, accesses the Internet via the user computer and ISP 7. The user 5 locates the desired vendor Website on the Internet 2, maintained by a vendor server computer 31 of a vendor system 32. The user 5 selects the product to purchase and, if the vendor system 32 subscribes to the system of the present invention, provides the identifier number to the vendor. The vendor system 32 then accesses the trust entity computing system 1 via the Internet 2.

Vendor system 32 then provides the details of the transaction and the identifier number to the trust entity computing system 1. The system 1 locates the associated payment and delivery information and, if all is correct, authorises payment via credit control system 33 direct to the vendor system 32 (the credit control system 33 may be controlled by a bank as with traditional credit card processing), and provides the vendor system 32 with the delivery destination designated by the user 5. The vendor system 32 is also provided with an authorisation code (as is usually provided with credit transactions), authorising a transaction. The vendor then delivers the product to the user.

If the product is software, the software is delivered from the vendor system to the repository 6 on the ISP 7 and the user computer 30 is alerted that software is to be delivered.

Note that the user may be advised by e-mail from the trust entity computing system 1 that the product is to be delivered, whether the product is software or not.

Figure 3 shows the transaction information requested in more detail. The vendor system 32 requires the users to complete a consumer order form 40 which includes information such as the description of goods 41 (in this case a toner cartridge for a printer) the quantity of goods 42, the unit cost 43, the total cost 44, the identifier number 45, the payment option 46 and the delivery option 47 of the user. As discussed above, the system may support a number of different payment options (eg credit cards) and a number of different delivery options (eg different destinations). The user specifies which payment option and which delivery option is to be used for a particular transaction by a simple integer identifier, as shown in the consumer order form This provides all the information the vendor requires.

When the vendor accesses the system 1, details as shown on the "vendor request for authority to system" form are required. This includes the vendor identification number 51. In this embodiment, the vendor is provided with their own identification number by the system 1. This facilitates security of the system as the system can

Q

12 require security guarantees from the vendor in exchange for a vendor identification number. Further, the database 4 may also store the vendor contact details.

Further information in the form includes the user identification number 52, the payment and delivery options 53 and 54, value 55 of the transaction and the vendor payment details 56 (to enable the system 1 to be able to facilitate payment to the vendor).

In return, the system may provide the vendor authority 60 which includes transaction amount 61, transaction authority 62 and delivery detail 63, so that the vendor can deliver the product to the user. The delivery details may be a software repository address for delivery of software.

In this case the dollar value of the transaction did not exceed the floor limit 18 of the user. If the dollar value of the transaction does exceed the floor limit, then the transaction clearing system 1 would seek the authority of the user (eg by e-mail or telephone) before authorising the transaction. Note that the ISP 7 maintains a database in the software repository 6 that links the identification number to the end user computer 30, so that software can be downloaded.

Instead of providing a delivery destination to the vendor, alternative delivery requirements may be followed, still providing security to the user. For example, the user may specify that they must be contacted before any transaction can be authorised. In such a case, the user could have already provided the delivery destination to the vendor, but the transaction would not proceed until the user himself is contacted. This prevents fraud.

Yet another delivery requirement would be to require the user to deliver a password (stored in the trust entity computing system) before the product is handed over. For example, with entertainment tickets for theatres) a user would usually attend a venue to pick up the tickets.

14 In the embodiment described above, the identifier is a number. The identifier could be any means for identifying the user, including a finger print, voice print, and others. Similarly, the option identifiers need not be integers, as in the above embodiment, but could be any other means of identifying the options such as delivery requirement, delivery address, payment option, etc.

In the embodiment described above, the payment processing information is a credit card information. It could be any other information enabling the transaction to be paid for, for example a user bank account information.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiment without departing from the spiritual scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respect as illustrative and not restricted.

Claims (2)

1. A system for facilitating transactions for products taking place over a computer network between vendors and users, the system comprising a trust entity computing system connectable to the computer network and including a database storing user delivery requirement information pre-specified to the trust entity by users, and user payment processing information associated with each user, and wherein to facilitate a transaction between a vendor and a user, the trust entity computing system is arranged to receive a user identifier from a vendor and to locate the delivery requirement information associated with the user identifier, whereby to enable delivery of the product the subject of the transaction in accordance with the delivery requirement information, and to locate the user payment processing information associated with the user identifier whereby to enable processing of payment to the vendor for the transaction, wherein, in order to enable delivery of the product in accordance with the delivery requirement information, the trust entity computing system is arranged to make the delivery requirement information available to the vendor providing the user identifier information.

2. A system in accordance with claim 1, wherein the user payment processing information includes a plurality of payment processing options, wherein the trust entity computing system is arranged to select between the payment processing options for paying for a product, wherein the user identifier includes a payment option identifier, and the trust entity computing system is arranged to select the payment option identified by the payment option identifier. S3. A system in accordance with claim 1 or claim wherein the delivery requirement information includes a ,1urality of delivery requirement options, wherein the 16 trust entity computing system is arranged to select between the delivery requirement options for delivering a product, wherein the user identifier includes a delivery requirement option identifier, and the trust entity computing system is arranged to select the delivery requirement option identified by the delivery requirement option identifier. Dated this 7th day of November 2000 PETER NAGEL AND CARLYLE NAGEL By their Patent Attorneys GRIFFITH HACK