Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION 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/00—Commerce
  • G06Q30/06—Buying, selling or leasing transactions
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems

Definitions

• the present invention relates to a method and a system for secure on-line transactions.
• the invention relates to such transactions performed over a public communications network such as the Internet.
• the customer may not know if the vendor can be trusted not to use the credit card information unfairl ⁇ . and whether the vendor stores the credit card information gathered from his customers in a secure manner. In many cases it may turn out to be easier to steal an entire database of credit card information through a break in into a vendor's system than to intercept individual card data transmitted over the Internet.
• the present invention relates to a payment system that provides customer as well as vendor with higher security without introducing unnecessary burden- some tasks for either.
• a customer is able to pay for goods or services using his credit card with a greatly reduced risk of having his credit card information compromised.
• the method provides the vendor with an opportunity to accept credit card payment without actually being registered with each and every operator of credit cards, debit cards, smart cards and the like.
• credit cards it must be understood that this is intended to cover any kind of credit card, debit card, credit or debit account, smart card or the like.
• a customer has access to a computer network, such as the Internet, through his computer.
• a computer network such as the Internet
• computers Also connected to this computer network is a number of computers containing information regarding goods and/or services offered by any number of providers. E.g. this information can be available through so called web pages set up by the providers, hereinafter referred to as vendors, on computers that act as web servers.
• vendors the providers
• web pages set up by the providers, hereinafter referred to as vendors
• vendors computers that act as web servers.
• Currently the most common way of presenting such information is through hypertext markup language (html) files (often combined with the use of scripts (Perl/CGI) and Java applets), the hypertext transfer protocol (http) and TCP/IP (Transmission Control Protocol/Internet Protocol).
• HTML hypertext markup language
• http Hypertext transfer protocol
• TCP/IP Transmission Control Protocol/Internet Protocol
• a customer retrieves information regarding the goods or services offered by a vendor from the computer network, this information will be presented to him on his computer.
• the customer selects any product or service he wants to purchase, and information regarding this is sent from the customer ' s computer to the vendor ' s computer along with any information necessary for shipment, such as the customer ' s name and address and/or shipment address.
• This information can be provided by the customer at the time, or it can be stored in his computer ahead of time, always ready to be added to any transmission of ordering information.
• the customer is already registered with the vendor, the customer ' s name and address may already be stored in the vendor ' s computer, and the customer information transmitted will in this case only include a reference to this information. This may be implemented through a so called cookie stored on the user ' s computer.
• information required for the processing of the payment is sent back to the customer.
• This information may include the total amount the customer is supposed to pay. a reference identifying the filed order, a reference identifying the vendor and any other relevant information, such as specification of goods ordered etc.
• the vendor does not have to be registered with any credit card company, but he must have an account with a payment system that consists of one or more payment centers.
• the vendor identification identifies the vendor uniquely to this payment system.
• the customer terminates the connection to the vendor. If the customer is connected to the computer network by a modem, the modem simply hangs up. The customer then enters the necessary payment information, which can for example include credit card number, expiration date. or.
• a connection is then established between the customer ' s computer and a computer at a designated payment center which constitutes or is part of the above mentioned payment system.
• This connection is not established over the public computer network used for communication between the customer and the vendor, but through a relatively secure data channel, for example the customer ' s modem dials up a direct connection to the payment center using the public telephone network, and preferably encrypted.
• the information is sent over a public computer network, but strongly encrypted, and possibly in the form of an e- mail message. The ordering information along with the credit card information is now transferred to the payment center.
• This information may then include vendor identification, order identification, total amount, customer name, address and credit card information and the customer ' s e- mail address, and constitutes a payment approval request.
• the payment center directly or through the payment system of which it is part, requests payment authorization from the credit card operator indicated by the customer ' s credit card information, or from some authorization authority approved by the credit card operator.
• This authorization authority will hereinafter be referred to as the payment authorization system, and this may include a credit card operator, a debit card operator or anyone else with whom the customer has set up some kind of an account, as well as any authority authorized one or more such entities.
• the payment system is able to choose the relevant authority out of any number of such authorities based on customer information such as for example credit card information.
• the request is preferably transmitted over a secure connection, such as a dedicated line.
• the payment system does not receive the requested authorization, the transaction is canceled. Information regarding this could be transmitted to the customer and/or the vendor, or the payment system may simply neglect to respond and the ongoing transaction may be canceled at the customer and vendor locations after a set time limit.
• the payment system may simply neglect to respond and the ongoing transaction may be canceled at the customer and vendor locations after a set time limit.
• the payment center does receive the requested authorization, the following actions are performed by the payment system.
• the payment system transmits a shipment approval to the vendor. It is important that the vendor is able to verity that the shipment approval actually originated with the payment system, so the shipment approval will preferabh be signed digitally. This can be done in a number of s. e.g. through use of a public key/private key system, through some mutual h trusted verification agency or in any other manner of digital signature know n in the art. Since the information transmitted from the payment system to the vendor does not contain confidential information, the connection can be made through a public network such as the Internet. If necessary, the payment system then terminates the connection with the vendor and waits for funds to be transferred from the credit card operator.
• the vendor delivers the purchased goods or services in exchange for the voucher. If the goods or services purchased are deliverable over the Internet, such as software or information, the exchange can be implemented automatical! ⁇ '. If this is not possible, the customer will hand over the voucher upon delivery of the goods or services.
• the vendor will of course not have precise knowledge of the voucher in advance. He will however preferably be able to verify that the voucher is indeed issued as part of the relevant transaction. This can be done by including the transaction identification in the voucher, since this will not be known to any third party trying to obtain the goods or services by presenting a false voucher. It is also possible for the payment system to transfer some information relating to the voucher along with the shipment approval, such as the checksum of the voucher number or some other means of verifying that the voucher is a voucher actually relating to the relevant transaction.
• the vendor transfers the voucher to the payment system, the amount authorized by the credit card company will be transferred to the vendor, possibly less a commission kept by the payment system and any possible fees or royalties to third parties as the result of any licenses or copyrights relating to the product.
• the ordering information is not sent from the customer computer to the vendor computer directly, but to the payment system along with the payment information.
• the payment system then forwards this order information to the vendor along with the delivery approval upon receipt of the requested payment authorization, the delivery is then made by the vendor solely based on information received form the payment system.
• FIG. 1 shows a possible configuration of an on-line shopping system using the method according to the present invention.
• Fig. 2 shows an alternative configuration of an on-line shopping system where the payment system consists of several local payment centers.
• Fig. 3 shows a flowchart of the method according to the present invention.
• Fig. 4 shows a flowchart of an alternative method according to the present invention.
• a system for on-line shopping includes a customer ' s computer 1 connected to a public network 2 such as the Internet. Also connected to this network is a number of vendors ' computers 3. Only one such computer is shown. These computers contain information presenting goods and/or services available from the vendors, e.g. in the form of web pages. Based on the information available to him in this way. a customer can file an order with the vendor by transmitting this order to the vendor's computer system. This may not necessarily be the same computer used to present the product information; it may also be a different computer set up to handle orders. Included in the on-line shopping system is also a payment system 4.
• This system is set up to handle payment, and all vendors must be registered with this payment system.
• a vendor registered with the payment system will receive a unique vendor ID.
• the system may be a centralized system run by only one operator, or it may be a network of payment centers run by several operators. Of course it may also be run by one operator, but consist of several distributed local payment centers.
• payment system will be used to refer to the whole payment system whether this is distributed or centralized, and payment center will be used to refer to the local payment center where vendor ' s are registered and to which customers connect, whether such a center constitutes the whole of the payment system or only a part of it.
• the payment system 4 is able to communicate with one or more payment authorization systems 5.
• the dotted lines surrounding the payment authorization system 5 shown in Fig. 1 indicates that there may be only one such authorization center, or there may be several, e.g. one for each credit card the payment system is able to accept.
• the communication channel between the customer computer 1 and the payment system 4 is preferably a relatively secure line, such as a dial up connection using the customers modem l b.
• the communication channel between the payment system 4 and the payment authorization center is preferably a secure channel such as a dedicated line.
• the communication channel between the payment system 4 and the vendor computer 3. need normally not be a secure line, and can be a public network such as the Internet.
• Fig. 2. where a possible alternative configuration of an on-line shopping system is shown. Reference numbers identical to those found in Fig. 1 refer to the same or similar parts of the system.
• the payment system 4 consists of several local payment centers 1 1. 12 as well as a database 13 and a computer network 14 connecting these.
• a customer connects to the payment system 4.
• he connects to his local payment center 1 1 .
• a vendor w ishing to register with the payment system 4. registers with his local payment center 12. and receives a vendor ID that identifies him uniquely to the payment system 4. It is of course possible for all the local payment centers 1 1.
• the database may contain all vendor IDs or only a table relating a given vendor ID to the right payment center. Information from the payment system 4 to a given vendor will then be sent to the vendor ' s payment center to be distributed.
• the network 14 connecting the local payment centers 1 1 , 12 and database(s) 13 that constitutes the payment system 4. will normally not need to be a secure network, since all confidential information is transmitted between the customer computer 1 and the local payment center 1 1 and between the local payment center 1 1 and the payment authorization system 5. It is however possible to modify the payment system by distributing tasks in a different manner, and the need for secure communication may then arise within the payment system. It is for instance possible to let the local payment center connect to the payment authorization center through other computers in the payment system.
• a potential customer is connected to a public computer network 2 such as the Internet, through his computer 1.
• a public computer network 2 such as the Internet
• the customer retrieves information that is available on the network from a vendor computer 3.
• this information may be presented in the form of HTML documents, or in any other convenient format, and transferred over the computer network by way of any well known protocol, such as TCP/IP.
• a next step 102 the customer selects any goods and/or services he might be interested in. and transfers order information to the vendor. Again there are several options for transferring this information. If the customer is already registered with the vendor, he may be identified to the vendor e.g. by so called cookies already stored on his computer and the customer may simply click on the items he wants to purchase. Other options include for example filling in an order form with necessary order data such as customer name, address and delivery address, and pressing a send button. The information may be transferred by way of the http protocol, or by any other suitable protocol.
• the vendor computer 3 receives the order information from the customer computer 1.
• an order ID is generated and transferred to the customer computer 1 along with a vendor ID. a total amount and any other relevant information.
• the customer may disconnect from the public computer network 2 that interconnects his computer 1 and the vendor computer 3. This may be done automatically by software running on his computer 1.
• the customer is ready to pay. he will be presented with a dialog box where he is requested to fill in personal information such as name, address and credit card information (referred to collectively as customer ID in Fig. 3 ).
• customer ID in Fig. 3 Some of this information may already be present in the information transmitted from the vendor computer to the customer computer, and in that case the customer will only have to supply the information not already available in this way.
• This payment information may already be stored on the customer computer in a preferably encrypted file. In that case all the customer has to do is to confirm his intention to pay. Alternatively the customer may be registered with the payment system 4 or a payment authorization system 5 with a debit account, a credit account or something similar, but for convenience it will be assumed in the following description that he is paying with a credit card. Actually any combination of information being entered by the customer, information being extracted from the information received from the vendor computer 3. information being pre stored on the customer computer 1 and information being pre stored in the payment system 4 or payment authorization system 5 is possible. The main thing is to make sure that the credit card information is not made available to the vendor and that the order information from the vendor is accurate when processed by the payment system. The payment information entered by the customer, along with the vendor ID, the order ID and the total amount, is then transferred 104 to the payment system 4. preferably in encrypted form.
• the payment system 4 Upon receiving this information, the payment system 4 requests authorization from the payment authorization system 5 by transferring 105 credit card information and total amount to the payment authorization system 5.
• the payment authorization system 5 may be one out of many, depending on what system has authority to authorize payment on the credit card specified by the customer.
• a next step 106 the payment system will either receive the requested authorization, or authorization is denied. If authorization is denied, the transaction is terminated 107. This may be communicated to the user and possibly also the vendor, or the transaction may simply be terminated in the different computers if the transaction does not proceed within a given time. If the transaction is authorized by the payment authorization system 5, the payment system in a next step 108 generates a voucher and transfers this to the customer computer. The connection between the payment system and the customer computer may then be terminated. The payment system also generates a delivery approval and transfers this to the vendor. If the payment system is distributed, the payment center 1 1 that is handling the transaction may have to look up the address of the vendor in a database 13.
• This address may include a network address for the vendor computer, an actual mail address, an e-mail address, a telefax number or any other vendor address to which the payment system 4 is able to send a message.
• the payment center 1 1 may be able to retrieve this address directly, or the vendor ID will only refer to the address of another payment center 12. If the latter is the case, the payment center 1 1 handling the transaction will transfer the delivery approval to the payment center 12 referred to by the vendor ID. and this payment center 12 w ill forward the delivery approval to the vendor 3.
• the delivery approval does not contain confidential information, and may therefore be transferred over a public network such as the Internet.
• the delivery approval is therefore preferably signed by a digital signature.
• a digital signature can be generated in a number of well known ways. e.g. by way of a public key/private key encryption algorithm.
• the vendor delivers goods and/or services to the customer, preferably in exchange for the voucher. If the goods and/or services constitutes information, software or something else that may be transferred over a computer network, this exchange may be done automatically. If not. the goods or services may be exchanged for the voucher manually. In some implementations of the invention it may however be necessary to forego the exchange and simply deliver the goods and/or services simply based on the delivery information and the delivery approval. This might for instance be the case when the delivery address is not the same as the address of the customer.
• the vendor After receiving the voucher, the vendor transfers 1 10 this to the payment system.
• the payment system 4 receives the voucher, the funds will be transferred to the vendor, and the transaction is completed. If the vendor has not received the voucher, he will simply make a claim that the delivery has been made. In this case the payment center will credit the vendor for example after a given period of time unless the customer does not make a counterclaim stating that the ordered goods and/or services has not been delivered.
• Figure 4 shows a flowchart that represents an alternative to the embodiment as described with reference to Fig. 3.
• the customer receives information from the vendor regarding available goods and/or services as well as prices in a first step 201. This information includes vendor information such as a vendor ID. Based on this information the customer selects 202 goods and/or services he wants to purchase.
• the customer When the customer is ready to order, he provides the necessary customer information as mentioned above, and this information along w ith the ordering information is transferred 203 to the payment system.
• the ordering information regarding the ordered product is not filed directly with the vendor, but with the payment system.
• a next step 204 the payment system requests payment authorization in the same manner as described above. If the payment system receives positive payment authorization information in step 205. a voucher is generated 207 and transferred to the customer computer as described above. Likewise a delivery approval is generated and transferred to the vendor computer, along with the ordering information, such as delivery address and information identifying the ordered goods and/or services.
• the vendor delivers 208 - the ordered goods and/or services, preferably in exchange for the voucher.
• the vendor transfers 209 a claim, preferably including the voucher, to the payment center.
• the payment system then credits 210 the vendor, possibly after a certain period that gives the customer a chance to claim that the goods and/or services have not been delivered.
• This particular embodiment is particularly convenient when the vendor is selling products that are deliverable over a public computer network such as the Internet.
• the customer may then download such a product in a trial version, possibly as part of retrieving information from the vendor in step 201. or in advance of the whole process described. This trial version.
• a product may include computer software, music, data, multimedia presentations etc.
• the goods actually purchased through the method according to the present invention, and delivered from the vendor after receipt of a delivery approval from the payment system, may then be a key that unlocks the trial version after the expiry of the trial period and converts it to a regular version of the product. It should be pointed out that this scheme may be used also regarding trial versions that are distributed by other means, such as on CD ROM or diskettes.
• the second embodiment may also be used for any other goods or services as an alternative to the first embodiment. It is important to note some of the security features as well as the flexibility provided by the method according to the present invention. Vendors that wish to offer their products over a computer network such as the Internet only have to set up an account with the payment system, without any approval from credit card companies. The payment system, however, will be registered with credit card companies, and the credit card companies makes the payments to the operator or one of the operators of the payment system. In this way. any company, small or large, or even a private individual, that wishes to sell almost anything over the Internet, may do so fairly simply.
• the customer may not withhold payment by not handing over the voucher after receiving the ordered goods and/or services.
• the payment will be held by the payment system until the voucher is received from the vendor. If the vendor does not receive the voucher in exchange for delivered goods, he may make a claim to the payment system, which may then hold the money until any conflict between customer and vendor has been resolved, or the payment system may release the payment to the vendor if the customer does not respond within a given time after having been notified that the vendor demands payment without being able to present the voucher.
• the customer may make such a claim to the payment system which will then return the funds to the customer, unless the payment system receives the voucher or a claim that delivery has been made from the vendor within a given time. In case of a conflict, the payment system may withhold the funds until the conflict has been resolved.
• the voucher In order for the vendor to make sure that the voucher he is given in exchange for the goods or services is genuine, the voucher should identify the order ID, since this will not be known to any impostor trying to obtain the goods or services in the name of the actual customer. Additional security can be provided by including with the approval information transferred from the payment system to the vendor, information that allows for the authentication of the voucher.
• the order information transferred from the vendor computer to the customer computer and forwarded to the payment system by the customer may be tamper proof such that any modification to this information will be detected by the payment system.
• the delivery approval information transferred from the pay ment system to the vendor may include information on paid amount so that the vendor is able to confirm that the funds held by the payment system corresponds with the total amount for the given order. Any combination of such security functions may also be implemented, so that any transaction containing inaccurate information may be terminated as soon as possible.
• any number of communication protocols may be used for transferring information between the different computers and systems that perform the method.
• what above is described as being one computer, for instance the vendor computer, may in fact be several computers that are interconnected by some well known means and that perform different steps of the method.
• the payment authorization system and the payment system may be operated by the same organization or legal entity, and may even be running on the same system or the same computer. If encryption and/or digital signatures are used, any of the well known algorithms or methods known in the art may be employed as well as future improvements and modifications to such algorithms and methods.
• Another possible modification that lies within the scope of the invention is to include certain contract information along with the order information transmitted from the vendor computer to the customer computer and forwarded to the payment system.
• This contract information may specify how a certain amount of the payment should not be credited the vendor, but some third party that collects royalty or some other fee from sales of a given product.
• the third party e.g. a publishing company, an artist, an inventor or anyone else who owns rights related to the product delivered by the ⁇ endor. will not be dependent on the honesty of the vendor, since all sales w ill involve the payment center.
• the individual or organization claiming the fee will be able to check that the vendor actually sends the correct contract information as part of the order information simply by placing an order and checking the order information received from the vendor.
• Funds may be transferred immediately upon receipt of the voucher, or a certain period of time after a claim has been made by the vendor and no counter claim has been made by the customer. It is also possible to wait until funds have actually been transferred from the credit card company to the payment system. A number of modifications to this scheme is possible and will be realized by anyone with the relevant skills for implementing the method according to the invention.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Marketing (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=19903094

Family Applications (1)

Country Status (4)

Families Citing this family (14)

Family Cites Families (4)

• 1999
  • 1999-03-16 NO NO19991278A patent/NO311468B1/no not_active IP Right Cessation
• 2000
  • 2000-03-16 EP EP00915594A patent/EP1177516A1/de not_active Withdrawn
  • 2000-03-16 WO PCT/NO2000/000092 patent/WO2000055777A1/en not_active Application Discontinuation
  • 2000-03-16 AU AU36833/00A patent/AU3683300A/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events