U.S. patent application number 11/404841 was filed with the patent office on 2006-08-31 for payment system and method for use in an electronic commerce system.
Invention is credited to Christian Allfred, Luiz Otavio Carvalhal, Lars Haraldsson, Andreas Undhagen.
Application Number | 20060195367 11/404841 |
Document ID | / |
Family ID | 20417842 |
Filed Date | 2006-08-31 |
United States Patent
Application |
20060195367 |
Kind Code |
A1 |
Allfred; Christian ; et
al. |
August 31, 2006 |
Payment system and method for use in an electronic commerce
system
Abstract
A method and system of payment of goods and services in an
electronic commerce system, reduces the transfer and processing
costs for each purchase made by a customer from a merchant; using a
customer agent, a merchant agent, an account manager associated
with the agents for administration of customer accounts and
merchant accounts, and a mediating trusted agent associated with
one of the account manager and merchant agent for checking
transactions during a trading session. The customer agent and
merchant agent, account manager, and mediating trusted agent are
interconnected by an electronic communication network.
Inventors: |
Allfred; Christian;
(Karlskrona, SE) ; Carvalhal; Luiz Otavio;
(Karlskrona, SE) ; Undhagen; Andreas; (Karlskrona,
SE) ; Haraldsson; Lars; (Ronneby, SE) |
Correspondence
Address: |
NIXON & VANDERHYE, PC
901 NORTH GLEBE ROAD, 11TH FLOOR
ARLINGTON
VA
22203
US
|
Family ID: |
20417842 |
Appl. No.: |
11/404841 |
Filed: |
April 17, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09718411 |
Nov 24, 2000 |
|
|
|
11404841 |
Apr 17, 2006 |
|
|
|
Current U.S.
Class: |
705/26.1 ;
705/76 |
Current CPC
Class: |
G06Q 20/10 20130101;
G06Q 20/3821 20130101; G06Q 30/06 20130101; G06Q 30/0613 20130101;
G06Q 30/0601 20130101; G06Q 20/027 20130101; G06Q 20/0855 20130101;
G06Q 50/188 20130101; G06Q 20/085 20130101; G06Q 20/401 20130101;
G06Q 20/108 20130101; G06Q 20/40 20130101; G06Q 20/102 20130101;
G06Q 40/025 20130101; G06Q 20/204 20130101; G06Q 20/382 20130101;
G06Q 20/105 20130101; G06Q 20/20 20130101; G06Q 20/3672 20130101;
G06Q 40/00 20130101; G06Q 20/3674 20130101; G06Q 20/367
20130101 |
Class at
Publication: |
705/026 ;
705/076 |
International
Class: |
G06Q 99/00 20060101
G06Q099/00; H04L 9/00 20060101 H04L009/00; H04K 1/00 20060101
H04K001/00 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 23, 1999 |
SE |
9904258-2 |
Claims
1-23. (canceled)
24. A method for secure delivery of electronic products over a
communications network by an automated merchant agent, comprising
the steps of: receiving and accepting a signed order from a
consumer agent; encrypting the electronic product with a first key;
signing and sending the encrypted electronic product and the
product identity to the consumer agent for verification; and
receiving an acceptance message from the consumer and sending the
first key to the customer agent for decryption of the electronic
product.
25. A method according to claim 24, wherein before the step of
sending the first key to the customer agent, the method comprises
the further step of: receiving a second key from the consumer via a
mediating trusted agents, which signs the second key before
delivery to the merchant agent.
26. A method according to claim 25, wherein the first encryption
key is encrypted with the second key before the first key is sent
to the customer agent.
27. A method according to claim 24, wherein after the verification
of the received electronic product by the customer agent, the
method further comprises the step of: receiving a refusal message
from the customer agent; and initiating a re-sending of the
electronic product.
28. An electronically-implemented merchant agent for secure
delivery of electronic products over a communications network,
comprising electronic circuitry configured to: receive and accept a
signed order from a consumer agent; encrypt the electronic product
with a first key; electronically sign and send the encrypted
electronic product and the product identity to the consumer agent
for verification; and receive an acceptance message from the
consumer and send the first key to the customer agent for
decryption of the electronic product.
29. An electronically-implemented merchant agent according to claim
28, wherein before the first key is sent to the customer agent, the
electronically-implemented merchant agent is further configured to:
receive a second key from the consumer via a mediating trusted
agent for signing the second key before delivery to the merchant
agent.
30. An electronically-implemented merchant agent according to claim
29, wherein the electronically-implemented merchant agent is
further configured to: encrypt the first encryption key with the
second key before sending the first key to the customer agent.
31. An electronically-implemented merchant agent according to claim
28, wherein after the verification of the received electronic
product by the customer agent, the electronically-implemented
merchant agent is further configured to: receive a refusal message
from the customer agent; and initiate a re-sending of the
electronic product.
32. An electronically-implemented merchant agent for secure
delivery of electronic products over a communications network,
comprising: means for receiving and accepting a signed order from a
consumer agent; means for encrypting the electronic product with a
first key; means for electronically signing and sending the
encrypted electronic product and the product identity to the
consumer agent for verification; and means for receiving an
acceptance message from the consumer and sending the first key to
the customer agent for decryption of the electronic product.
33. An electronically-implemented merchant agent according to claim
32, wherein before the first key is sent to the customer agent, the
electronically-implemented merchant agent further comprises: means
for receiving a second key from the consumer via a mediating
trusted agent for signing the second key before delivery to the
merchant agent.
34. An electronically-implemented merchant agent according to claim
33, further comprising: means for encrypting the first encryption
key with the second key before sending the first key to the
customer agent.
35. An electronically-implemented merchant agent according to claim
32, wherein after the verification of the received electronic
product by the customer agent, the electronically-implemented
merchant agent further comprises: means for receiving a refusal
message from the customer agent; and means for initiating a
re-sending of the electronic product.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to a payment system and method
for an electronic commerce system, and more particularly to a
payment system and method utilising at least a customer agent and a
merchant agent, at least an account manager associated with said
agents for administration of customer accounts and merchant
accounts, and at least a mediating trusted agent associated with
said at least one account manager and merchant agent for checking
transactions, for purchases made by a customer from a merchant.
DESCRIPTION OF THE PRIOR ART
[0002] Different kinds of electronic commerce systems and
associated payment systems are provided. Some existing systems
provide only handling of payments, i.e so called payment systems,
some systems provide full transaction services, and other systems
provide some transaction services together with payment
services.
[0003] Transactions and payments in such electronic commerce
systems are done over a communication network such as the public
switched telephone network, cellular phone systems, the Internet,
or an intranet etc. Small payment transactions are denoted micro
payments. The goods, such as documents, pictures, software, stock
market information, etc., are purchased by a customer via a
webbrowser from a merchant over the Internet.
[0004] Crucial for all existing micro payment schemes is a very low
transaction cost, i.e the transaction cost must be at least a
magnitude smaller than the price of the goods. The low prices of
the goods imply a lower expectation of the security level compared
to "full" price systems.
[0005] Further, other requirements on payment systems is low price,
fast and reliable transfer, and to provide customer integrity.
[0006] For every transaction, money has to be transferred from a
customer account to a merchant account. Micro payment may be
considered as one transaction per merchant site while as a
plurality of transactions in other cases. The current business
model for micro payments is still not well understood and different
solutions aim for different models.
[0007] There are two basic concepts and a number of different
solutions for each concept on the market. On the one hand DigiCash,
CyberCoin and Millicent are well-known digital cash solutions
representing the first concept and on the other hand IBM's MiniPay
is an account based solution, wherein real money is transferred
between different accounts, representing the second concept.
[0008] The MiniPay is a lightweight system and probably quite cheap
regarding operating costs and it is user friendly.
[0009] A general description of a prior art account based system is
described with reference to FIG. 1.
[0010] According to a generic payment system as shown in FIG. 1, a
merchant 100 displays the goods for sale, e.g on a web page, at
step 0. A customer 101 orders goods at step 1. At step 2, the
customer 101 sends a payment order to its account manager 102. The
payment is transferred to a value acquirer 103 at step 3. The
merchant 100 is notified of the payment completion by the value
acquirer 102 at step 4 and the goods are finally delivered.
[0011] A micro payment system such as the IBM MiniPay system
includes a plurality of necessary features in order to operate
properly. When a purchasable item is presented on a customer's
browser, the Minipay provides desired click and pay features for
the order and payment of the goods. Further, an easy way for
establishment of the link between the goods and the payment system,
and the use of the system from the customer's as well as the
merchant's point of view has to be provided. The usefulness of the
payment system increases if it is adaptable to several accounting
systems like Telco's billing systems and banking accounts. It must
be possible to do business in multi-operator environment. The
system must be scalable, i.e adaptable for a few users as well as
for millions of users with costs growing not more than linearly.
For the purpose of distribution the system has to run on standard
hardware, such as PCs and workstations. The value of the goods for
sale in a micro payment environment is quite low and, consequently,
the security measures should be in harmony with these values. Micro
payment systems have to provide limited information volume and
processing overheads for the transactions. Among the required
processing tasks are customer authentication, authorization, and
currency exchange rate calculations. Most of the above mentioned
features are solved by the MiniPay system.
[0012] However, a problem with the MiniPay system and other prior
art payment systems is less good solutions to the problem of
interoperator transactions, and complex clearing procedures of
transactions within an operator and between operators.
[0013] Another problem is that prior art payment systems only
support a single or a pair of currencies and it is not possible to
add new currencies. A consumer expects to buy from merchants
scattered around the globe. Thus, there is minimal chance that a
consumer buys a product from a merchant using the same currency as
in its own country. As much as a consumer expects to pay in its own
currency, a merchant expects to be paid in its own.
[0014] A main problem in digital cash systems and in some account
based systems is double spending, which occurs when customers are
involved in several transactions simultaneously. Customer integrity
is a further problem in electronic commerce systems, i.e merchants
can utilise customer consumption patterns in undesired ways.
Authentication, authorisation of the customer, and the handling of
encryption keys are important features in a payment system.
[0015] PKI (Public Key Infrastructure) is a system(s) using
certificates or electronic ID cards for obtaining secure
transactions and customer integrity. Certificates exist in various
formats and flavours, such as the X.509 standard.
[0016] One of the most difficult items in electronic commerce today
is how to secure the transportation of digital goods between
trading parties. There are several aspects where it might be an
advantage to have a mechanism that can protect the involved parties
both from a legal and a reliability perspective. Usually, today's
trading/payment schemes do not cover this at all, or badly.
[0017] Three major problems can be identified as blockers for
trading with digital goods over the Internet:
[0018] 1. Acceptance of Delivery
[0019] The consumer does not have sufficient tools to handle
acceptance of delivery in case of digital goods. Most often,
merchandise has to be accepted as it arrives through the Internet
to the consumer's computer. There are no legal possibilities to
complain if it was erroneous or completely wrong.
[0020] 2. Fraudulent Consumers/Non-repudiation
[0021] The merchants on the Internet does not have enough or easy
tools to prohibit fraudulent consumers from ordering goods that
they do not want to pay for. The merchant cannot know if the goods
reached the consumer or not.
[0022] 3. Unauthorized access of goods
[0023] In some trading situations, either the consumer or the
merchant (sometimes both) does not want to reveal the good for any
outsiders. Within the Internet environment, it will always be
possible to catch plain text information between two parties.
SUMMARY OF THE INVENTION
[0024] It is an object of the present invention to provide an
improved electronic payment system for use in an electronic
commerce system and a method thereof, which reduces the transfer
and processing costs for each purchase by a customer from a
merchant in the commerce system.
[0025] Another object of the present invention is to provide a
payment system not disclosing the customer's identity during a
trading session.
[0026] It is still another object of the present invention to
provide secure transactions between a customer and a merchant in
order to protect the customer's accounts and its account manager
from abuse.
[0027] It is a further object of the present invention to prevent
double spending of the customer.
[0028] It is yet another object of the invention to provide and
reduce the authentication procedure to a minimum.
[0029] It is still a further object of the present invention to
provide a payment system adaptable to several accounting
systems.
[0030] A further object of the present invention is to enable
interoperator transactions.
[0031] Another objective is to guarantee the payment to the
merchant.
[0032] Another object is to provide the customer with spending
control.
[0033] Still another object of the present invention is to provide
a scalable payment system.
[0034] Yet another object of the present invention is to support a
plurality of currencies.
[0035] These objects are accomplished by a payment system and
method according to the invention as claimed.
[0036] A more specific object of the invention is to provide a
method for secure delivery of electronic products over a
communications network.
BRIEF DESCRIPTION OF THE DRAWINGS
[0037] In order to explain the invention in more detail and the
advantages and features of the invention a preferred embodiment
will be described in detail below, reference being made to the
accompanying drawings, in which
[0038] FIG. 1 is a block diagram showing a network configuration of
a prior art electronic payment system for use in electronic
commerce;
[0039] FIG. 2 is a block diagram showing a network configuration of
an electronic payment system according to the invention for use in
electronic commerce, illustrating the initiation and continuation
of a trading session;
[0040] FIG. 3 is a block diagram showing a network configuration of
an electronic payment system according to the invention for use in
electronic commerce, illustrating the conclusion of the trading
session; and
[0041] FIG. 4 is a block diagram showing a network configuration of
an electronic payment system for use in electronic commerce,
illustrating a method for secure delivery of electronic products
over a communications network according to the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0042] With reference to FIGS. 2 and 3, a payment system for use in
an electronic commerce system for reducing the transfer and
processing costs for each purchase made by a customer or consumer
from a merchant, comprises at least a merchant agent 200, such as a
server or computer system operated by a merchant, a customer agent
201, such as a PC, PDA, Mobile or workstation operated by a
customer, at least an account manager 202 provided by an operator
associated with said agents for administration of customer accounts
and merchant accounts, and at least a mediating trusted agent or a
so called value acquirer 203 provided by the operator or another
operator associated with the at least one account manager 202 and
merchant agent 200 for checking transactions during a trading
session.
[0043] The customer agent(s) 201 and merchant agent(s) 200, the
account manager(s) 202, and the mediating trusted agent(s) 203 are
interconnected by for example an electronic communication network,
such as the Internet, an intranet, a public switched telephone
network, and/or a mobile telephone network, an optical network, or
a combination thereof, or another kind of communication
network.
[0044] The main function of the account manager 202 is to
administer the customer accounts and trading records, and to create
and forward billing records to external billing systems, such as
banks, telecommunication operators, credit card firms etc. A
merchant or the merchant agent is associated like customers to the
account manager 202; the difference is in the relation to the
mediating trusted agent 203.
[0045] The mediating trusted agent or value acquirer 203 is a part
of the payment system of the merchant's operator. The function of
the value acquirer 203 is to handling a deposit, described later,
check the transaction records when trading sessions are terminated,
and deliver the transaction records to the appropriate account
managers of the customer and merchant, respectively.
[0046] A relation between a customer 201 and an account manager 202
when the customer is logged-on to the account manager is denoted a
session. Each session is given an identity generated by the account
manager 202 according to the following illustrative pseudo code
expression:
Sessionidentity=AccountManagerIdentity.Sequencenumber1
[0047] The SessionIdentity is valid through the complete
session.
[0048] A relation between a customer agent 201 and a merchant agent
200 when the customer orders goods is denoted a transaction. Each
transaction is given an identity when it is generated by the
account manager 202 according to the following pseudo expression.
TransactionIdentity=SessionIdentity.Sequencenumber2
[0049] The TransactionIdentity is generated by the account manager
202 when the customer agent 201 informs about a purchase. Further,
the TransactionIdentity is valid through the complete
transaction.
[0050] A method of payment of goods in an electronic commerce
system according to the invention is divided into two phases: an
initiation phase illustrated in FIG. 2, including steps regarding
the initiation and continuation of a trading session; and a
conclusion phase illustrated in FIG. 3, including steps regarding
the conclusion of a trading session.
[0051] Hence, in the following description, the payment system is
only partly disclosed. Some well-known features such as the initial
contacts between a customer and a merchant and the registrations
and other system entities are not described in detail so as not to
make the present invention unclear.
[0052] All involved parties are given an asymmetric key pair at
registration and algorithms like RSA or DSA are likely to be used.
Further, all communication except between the customer and the
merchant is carried out on secure channels like SSL or IPSec.
[0053] In the initiation phase, a normal GET URL message is used to
download a web page and a normal response to the GET URL is
performed at step 0, i.e a web page with prices and information
associated for proceeding with the transaction. The merchant agent
200 receives an order of goods/service from the customer agent 201.
The customer account manager 202 receives an initiation message
sent from the customer agent 201, wherein the message includes data
for registration of the customer agent 201, and order information
with the size of the purchase. The initiation message further
comprises the amount of the deposit, a transaction identity, the
identity of the merchant and the identity of the merchant's
operator for locating a proper mediating trusted agent 203.
[0054] Further, the customer account manager 202 provides the
customer agent 201 with account data during a trading session being
established between the customer agent 201 and the merchant agent
200 over the network. The customer account manager 202 amends and
forwards the initiation message to the mediating trusted agent 203
for registration of the customer, and delivering of a deposit. The
amended initiation message comprises the deposit in the customer
currency, a customer identifier, the transaction identity, and the
identity of the merchant.
[0055] The mediating trusted agent 203 sends an information message
including the deposit to the merchant agent 200. The information
message comprises the deposit in the currency of the merchant, a
trading session identity, and the customer identifier. The trading
session is now ready to start.
[0056] After the mediating trusted agent 203 has sent an
information message, the merchant acknowledges the customer and the
associated deposit to the mediating trusted agent 203.
[0057] The mediating trusted agent 203 acknowledges the customer
and the associated deposit to the customer account manager 202.
[0058] The acknowledge includes the current exchange rate and that
the customer account manager 202 forwards the exchange rate to the
customer agent 201.
[0059] When the customer account manager 202 amends and forwards
the initiation message to the mediating trusted agent 203 the
customer is also vouched for.
[0060] When the value of at least one purchase amounts to the value
of the deposit, a clearing procedure is initiated by the merchant
200. If the deposit is consumed and a subsequent purchase attempt
is made it will be treated as an initial purchase attempt and a new
transaction is initiated. However, a plurality of purchase orders
can be executed within the limit of a single deposit.
[0061] Additionally, the trading session can be stopped by
instructions from the customer agent 201 or the merchant agent 202
or after a timer expiry, which may be agreed upon at the
initiation.
[0062] Thus, in order to stop or terminate the trading session the
merchant agent 200 receives a trading session terminate message
sent by the customer agent 201 or a timeout.
[0063] During the conclusion phase the customer account manager 202
receives a signed customer transaction record sent by the customer
agent 201, the customer account manager 202 sends the customer
transaction record to the mediating trusted agent 203 and the
merchant agent 200 sends a signed merchant transaction record to
the mediating trusted agent 203.
[0064] Further, the mediating trusted agent 203 compares and
evaluates the transaction records, resulting in clearing
information. The mediating trusted agent 203 sends the clearing
information to the customer account manager 202 and a merchant
account manager 204, respectively.
[0065] Finally, the customer account manager 202 and a merchant
account manager 204, respectively, send the clearing information to
the customer agent 201 and the merchant agent 200, in this
embodiment of the invention. This is, however, not necessary and
can be optional. Based on the clearing information, the transaction
records are processed to a withdrawal record and a deposit record,
respectively, which are stored. The withdrawal record is sent to a
customer billing system 205 and the deposit record is sent to a
merchant billing system 206.
[0066] The trading session may comprise a good number of single
purchases, thereby reducing the transfer and processing costs for
each purchase as most of the required transfer and processing are
performed at one instant for a large number of purchases. This is
especially important for the costly chores, such as
authentication/authorization and secure money transfer but also for
the currency exchange rate conversion.
[0067] In an alternative embodiment of the invention, the method
would allow the consumer to receive a currency exchange table
(together with a lifespan stamp) from her own bank and keep it
stored on her device or terminal (PC). The application that enables
transactions can then look for a local table in the consumer's
device (PC) first and provide price information in her consumer's
device in real time. The application can also alert the consumer if
the validity of the table has expired or if no such table exists.
If a valid table exists with the relevant currency value, it is
used throughout the whole session.
[0068] Another important point is that it keeps the trust chain
intact, i.e. a consumer is more likely to trust her own bank for
currency exchanges than another bank it has no knowledge of. It
would also avoid confusions that would come from a consumer buying
products from merchants in the same foreign country and having to
pay different prices in her own currency because the two merchants
have different banks. The flow is as follows:
[0069] 1 Offer is sent from a merchant to the consumer's
device;
[0070] 2 The device checks if a valid currency table exists (if
not, the device contacts the bank and requests a valid currency
table);
[0071] 3 The offer is changed by the device before it is displayed
so as to show the price in the consumer's currency;
[0072] 4 The consumer decides to purchase the product. It sends a
request to her financial institution including the amount of the
deposit in her own currency.
[0073] 5 The financial institution converts the deposit currency to
the merchant's currency and forwards it to the merchant's financial
institution
[0074] 6 When the shopping session ends, eventual money left unused
is returned to the consumer's financial institution on the
merchant's currency
[0075] 7 The consumer's financial institution converts the
remainder of the deposit to the consumer's currency.
[0076] 8 Session ends.
[0077] The customer identity is not disclosed by the payment
system, not even to the trusted mediating agent. The merchant will
only have access to a temporary customer identity and the customer
public key, which is not traceable via the payment system. The
merchant must of course know the IP address of the customer but one
may assume that the customer has a dynamic IP address and it is not
traceable without some effort. The contents of the purchase(s) are
hidden for the banks, i.e the mediating trusted agent or the
account manager, because the purchase list is encrypted. Only a
hash of the purchase list is visible, so that the mediating trusted
agent can compare and verify that the both lists received from the
parties are equal. A hash cannot be reversed in order to receive
the purchase list.
[0078] On the merchant side, both the merchant and the merchant's
operator have secured their payment from the customer's side. In
order to protect the customers account and the account manager from
abuse, secure channels like SSL or IPSec are used with sufficient
strength in the encryption algorithms and the associated keys. The
same applies between the merchant and the mediating trusted
agent.
[0079] Double spending is impossible since the account manager does
not hand out deposits beyond its own credit limit for the
customer.
[0080] The PKI(Private Key Infrastructure) is reduced to a minimum,
because a customer/merchant needs only to know the public keys of
its clients. The difficult part is the operator's knowledge of
other operators' public key. Other knowledge of public keys is only
temporary.
[0081] With PKI the consumer has a certificate it would show the
merchant to ensure privacy, authentication, etc. This privacy is
not privacy towards the merchant itself, who could keep track of
your shopping patterns or other info on your certificate for
future, sometimes malicious, use. Besides, from a merchant
perspective, a certificate that the consumer presents should be
vouched for by a common trusted party, which means lots of liaisons
between many different customer agents around the world.
[0082] The proposed solution assumes that the PKI infrastructure is
placed in a particular topology.
[0083] In the topology, 4 zones are identified:
[0084] Zone 1: Englobes Financial Institutions (FI) on permanent
trust relationships. A common certificate authority (CA) issues FI
certificates.
[0085] Zone 2: Englobes FIs and their customers on permanent trust
relationships. The FI issues certificates.
[0086] Zone 3: Same as Zone 2. (since a customer/consumer and a
merchant both are customers from the FI's point of view).
[0087] Zone 4: Non PKI ruled zone that exists during a shopping
session
[0088] When a shopping session starts certificates should be
exchanged between consumers and merchants. Since the certificates
issuers are outside each other PKI zone, the FI will act as
mediators in this exchange.
[0089] The consumer will ask its FI to prepare a temporary
certificate on behalf of itself. The temporary certificate contains
only the consumer's public key (and relevant cryptographic
information) and a session ID (used to track the session data to
the involved parties). The FI will sign it (using the certificate
issued by the CA common to its and the merchants FI) and deliver it
to the merchant's FI. The merchant's FI checks the signature for
validity, decrypts the information, signs it (using the certificate
issued by itself--trusted by its customer, the merchant) and
forwards it to the merchant.
[0090] The merchant now possesses a cryptographic valid certificate
that contains the necessary data to perform cryptographic enhanced
operations without revealing the other party's identity.
[0091] The reversed process is initiated by the merchant to make
its certificate available to the consumer.
[0092] This procedure also eliminates the need for the
merchant/consumer to check Certification Revocation Lists (CRLs)
for the validity of certificates. This process can be exhaustive
specially if the consumer uses devices with less processing
power/restricted bandwidth, e.g. WAP phones.
[0093] The payment system according to the invention is adaptable
to several account systems, because of an API in the account
manager.
[0094] Further, the system assumes a multioperator environment, it
is scalable, the number of supported currencies is only limited by
the operator's willingness to sign agreements with other
operators.
[0095] Even though numerous characteristics and advantages of the
present invention have been set forth in the foregoing description,
together with details of the structure, it is to be understood that
the disclosure is illustrative only, and changes may be made in
detail within the principles of the invention indicated by the
broad general meaning of the claims.
[0096] For example, in another embodiment of the invention the
customer agent is a mobile phone communicating with a merchant over
a mobile telephone network and/or a public switched network and/or
an Internet Protocol network.
[0097] In another example, each client (merchant and consumers) has
a relation with a trusted party, i.e. bank or other operator. This
party may be a common party or two different parties, in a latter
case, having a relation with each other, like international
banks.
[0098] Each client and trusted party have software components
installed, which support this feature.
[0099] A Public Key Infrastructure (PKI) is implemented, preferably
organised and maintained by the trusted party. The merchant and
consumer have access to each other's certificates.
[0100] In a usual trading situation there are always at least two
parties, i.e a consumer and a merchant. In this example a new party
is introduced, namely the trusted party. This party is however not
any new actor in the field of trading. The role for the trusted
party is to ensure that information sent between clients in the
system is correct.
[0101] A transaction may take place when a consumer has received
information about a product from a merchant. The information may
contain whatever the merchant want. To support this feature, only a
product identity and a product description are needed.
[0102] In this embodiment of the invention, a method for secure
delivery of electronic goods, i.e an electronic or digital product
such as software or a computer program product etc., is described.
The goods are delivered over a communications network such as the
Internet.
[0103] With reference to FIG. 4, the consumer chooses a product,
and initiates the purchasing process by sending a signed order to
the merchant, which will be the evidence that the consumer really
ordered the product (sign (order).sup.C). The consumer will have to
read and accept the product description before he orders a product.
By accepting the order, the merchant acknowledges that the customer
agrees to purchase the product as described in the initial product
offer.
[0104] In parallel to the action above, the consumer will send a
consumer generated ciphering key (K1) to the trusted party, which
acts as an intermediary, signing it and passing it along to the
merchant.
[0105] Upon reception of the signed order, the merchant can send
the product to the consumer (sign([prod].sup.K2, prodID).sup.M).
The complete package of the digital product and product identity is
signed and sent to the consumer. This signature ensures the
authenticity of the product, which is essential in the case of
software to be installed on the consumer's hardware (HW).
[0106] Furthermore, the digital product is sent ciphered with a key
(K2) generated by the merchant. This means that the consumer can
not open the content without the K2 key.
[0107] When the product package is received, the consumer client
will do a check on received material in order to verify the
correctness (transferring errors, wrong product etc). The
signatures of the product and product description will be checked
and that they concerns the same product. If it appears to be
correct, the consumer sends an acknowledge to the merchant in a
signed message (sign(accept, unique).sup.C) with a unique
identifier time-stamped (to avoid reproducing problems). If the
secure delivery is implemented together with an electronic payment
scheme, the money is transferred to the merchant at this stage.
[0108] When the merchant receives the acceptance message from the
consumer, it will initiate the last message in the procedure, which
is the transfer of the ciphering key K2 to the
consumer([K2].sup.K1). To avoid unauthorized access to the sent
goods, the K2 key is ciphered with the consumer's K1 key.
[0109] Of course this is only the basic principle for a successful
trading. A trading transaction can go wrong in several ways:
[0110] The goods do not reach the consumer, due to bad connections,
loss of packages etc.
[0111] At point 4, a check is done to evaluate the status of the
received product. A re-sending can be ordered automatically. If the
re-sending is not successful, the purchase is aborted. Without the
(sign(accept, unique).sup.C) message from the consumer the merchant
can not claim payment for the product.
[0112] The goods do not fulfil the consumer expectations Normally
there are no realistic legal possibilities to revoke the purchase.
However, with this system, the consumer has a big advantage, namely
the merchant-signed product description. If the consumer's view is
that the description does not give an accurate description of the
received product, the consumer can escalate the controversy to (for
example) the National Board for Consumer Policies (NBCP). The
consumer sends the product (sign([prod].sup.K2, prodID).sup.M) and
the product description (sign(prod.desc).sup.M) to the NBCP. The
NBCP requests the key (K2) for decrypting the product from the
trusted party. Since the product and the product description are
signed and tied to each other by the product id, the consumer can't
send false information to the NBCP.
[0113] This solution solves one of the most annoying problems in
the electronic commerce arena with fairly simple methods.
[0114] It is easy to implement at the merchant site, all products
may be pre-ciphered and pre-signed, and no real-time ciphering is
needed.
[0115] No need for unnecessary transportation via mediators (except
for the cipher key K1 that is a very small transfer).
[0116] The use of a verbal product description is most likely
acceptable as legal evidence in case of a dispute between the two
trading parties. This also means that the system can handle all
kinds of digital transfers, such as music, documents, movies,
software etc. without any special treatment of the goods depending
on its kind.
[0117] It is possible to implement the solution in many of today's
electronic payment schemes.
* * * * *