Note: Descriptions are shown in the official language in which they were submitted.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
1
A METHOD AND SYSTEM FOR THE PROVISION OF ELECTRONIC
COMMERCE AND SHOPPING VIA CABLE TELEVISION SYSTEMS
AND ASSOCIATED ENTERTAINMENT TERMINALS
This application claims the benefit of U.S.
provisional patent application no. 60/150,679 filed
August 25, 1999.
BACKGROUND OF THE INVENTION
The present invention relates to an e-commerce
architecture and implementation, and more particularly
to a method and system for enabling an entertainment
terminal or the like to be used for electronic
commerce and electronic shopping transactions.
Various models for e-commerce have been
developed, including the Secure Electronic Transaction
Specification (SET). These models rely on public key
cryptography, which is well known in the art.
Unfortunately, existing e-commerce models are overly
complex and are not particularly well suited for use
by cable television system operators and their
subscribers. For example, known models require end
users (also referred to herein as "cardholders" or
"consumers" interchangeably) to swipe a magnetic card
through a card reader or to insert a smart card into
an interface on a set-top terminal. This requires the
user to get up and walk over to the set-top, which may
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
2
be objectionable and is clearly inconvenient.
Moreover, existing e-commerce models do not meet the
business needs of cable television operators and the
like, such as multiple system cable operators (MSO)
that desire to provide e-commerce services over
existing network facilities, such as cable television
networks. In many cases, the interest has been in the
area of e-shopping via an MSO electronic store
administered by the cable system operator or a
designated party. The e-commerce models were developed
without consideration of privately owned and operated
networks and were tailored to the Internet with
applications such as shopping, banking, and investing.
Smart cards are similar to credit cards, but
store information on an integrated microprocessor
(CPU) located within the card. There are two kinds of
smart cards. The more functionally capable one,
referred to as an "intelligent card", contains a CPU
that has the ability to store and process secured
information specific to the card issuer's application
needs. It offers a read/write capability where new
information is processed and added or decremented,
e.g., for monetary value associated with a given
purchase. The second type of smart card is often
referred to as a "memory card." A memory card is
primarily a storage device that contains a stored
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
3
monetary value, which the user can spend in a retail
store, vending machine, pay phone, etc.
Intelligent smart cards often are considered more
secure for electronic transactions when compared to
credit cards, because the information is stored
securely and protected against damage or theft. This
is unlike credit cards, where the information is
present on the card in a readable format. The
underlying smart card capabilities are secure sign-on,
authentication (based on electronic signatures), and
encryption key mobility (for securing electronic
commerce transactions).
Visa International and MasterCard International
have championed an industry effort to develop a set of
specifications to provide secure payment card
transactions over open networks. Other participants
included: GTE, IBM, Microsoft, Netscape, RSA, SAIC,
Terisa, and Verisign. These specifications are
referred to as the SET Secure Electronic Transactions
Specifications, Book 1, 2, 3, Version 1.0 May 31, 1997
(SET). The SET is comprised of three main parts: Book
1, Business Description; Book 2, Programmer's Guide;
and Book 3, Format Protocol Definition.
The SET protocol features: Certificate Authority
trust model, RSA Public Key Cryptography, Secure Hash
Algorithm (SHA), Message Digest Algorithm (Rev. 5)
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
4
(MD5) and Data Encryption Standard (DES). The SET
protocol is intended to facilitate the following
functions: purchase, authorization, capture and
retrieval. The main parties involved are: card holder,
acquirer, issuer and gateway. A somewhat simplified
model was developed by VISA International using
proprietary solutions that are not SET compliant.
In what follows, it is assumed that the reader is
familiar with public key cryptography (PKC) and the
contents of the SET specification. Additional
background on PKC can be found at www.rsa.com/rsalabs.
Various acronyms and terms of art used in the
relevant industry and/or referred to herein are
defined as follows:
CA - Certificate Authority. A Certificate
Authority can be any trusted central administration
willing to vouch for the identities of those to whom
it issues certificates and their association with a
given key. For example, a credit card company may
issue certificates to its cardholders.
Certificate - Certificates are generated by a CA
and are essentially digital signatures that protect
public keys from forgery, false representation, or
alteration. Certificates are issued to an individual
after the CA establishes appropriate proof of the
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
individual's identification. Alternatively, a
manufacturer that is generating the RSA keys for a
given device (e.g., an entertainment terminal), may
also seed the device with the corresponding
5 certificate. In this manner, the manufacturer takes on
the role of a certificate authority.
CRL - Certificate Revocation List. A CRL is a
list of certificates that have been revoked before
their scheduled expiration date. A CRL is maintained
by the CA and provides information about the revoked
certificate.
I~5 - Message Digest Algorithm. A compression
algorithm for use with digital signature applications
where a large message has to be compressed in a secure
manner before being signed with a private key.
SHA - Secure Hash Algorithm. A compression
algorithm which is more secure than MD5.
DES - Data Encryption Standard. An encryption
standard which is described in US patent no.
3,962,593.
PKC - Public Key Cryptography
SET - Secure Electronic Transactions
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
6
Java - Object oriented, machine independent
programming language.
Applet - A Java program that runs inside a web
browser. All applets referred to in this document are
written in Java.
Client Application - A software application that
works on behalf of a consumer (cardholder) to extract
a service from a server somewhere on the Internet. It
is the 'Client' piece of client/server architecture.
DLL - Dynamic link library. Library which is
dynamically linked to an application when it is loaded
and executed at run time.
HTML - Hyper Text Markup Language used on the
Internet that allows users to click on a highlighted
word or phrase and obtain more information related to
that phrase.
Merchant Server - The merchant software that
offers goods or services to the Client. The Merchant
may be the MSO or a designated merchant in an
electronic store scenario.
Merchant Web Site - The web server and Merchant
Server which run on a computer that can be accessed by
web browsers over the Internet.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
7
SSL - Secure Sockets Layer, a protocol developed
by Netscape to allow client software to securely
communicate with servers. Using SSL prevents someone
who is watching a conversation on the Internet from
determining the contents of what is being transmitted.
It is thus useful for transmitting information such as
credit card numbers and other sensitive information.
The following SET functional description is an
excerpt from the aforementioned references. It is
provided here to illustrate the difference in
implementation complexity. The SET model uses message
encryption to ensure confidentiality of information
and provides for digital signatures. Both of these
techniques are intended to ensure the integrity of
payment information. The SET model also uses digital
signatures and cardholder certificates to ensure the
authentication of the cardholder account and provides
for the use of digital signatures and merchant
certificates to ensure authentication of the merchant.
For interoperability purposes, SET uses published
protocols and message formats.
SET does not address the following:
Message protocols for offers, shopping,
delivery of goods, etc.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
8
~ Operational issues such as the criteria set by
individual financial institutions for the
issuance of cardholder and merchant
certificates.
~ Screen formats including the content,
presentation and layout of order entry forms
as defined by each merchant.
~ General payments beyond the domain of payment
cards.
~ Security of data on cardholder, merchant, and
payment gateway systems including protection
from viruses, Trojan horse programs, and
hackers.
SET supports only three of the likely phases in
e-shopping/commerce. These are: a) payment
authorization and transport, b) confirmation and
inquiry, and c) merchant reimbursement. In the
following generalized description of an e-commerce
transaction, only the items preceded by SET are
addressed by the SET specifications.
~ Browsing and Shopping
~ Merchant and Item Selection
WO ~l/1$~92 CA 02376337 2002-02-15 pCT/US00/21232
9
~ Negotiation and Ordering
~ Payment Selection
~ SET » Payment Authorization and Transport
~ SET ~ Confirmation and Inquiry
~ Delivery of Goods
~ SET ~1 Merchant Reimbursement
The typical electronic shopping experience can be
divided into several distinct phases:
1. The cardholder browses for items. This may be
accomplished in a variety of ways, such as: using a
browser to view an on-line catalog on a merchant's
World Wide Web page; viewing a catalog supplied by the
merchant on a CDROM; or looking at a paper catalog.
2. The cardholder selects items to be purchased
from a merchant.
3. The cardholder is presented with an order form
containing the list of items, their prices, and a
total price including shipping, handling, and taxes.
This order form may be delivered electronically from
the merchant's server or created on the cardholder's
computer by electronic shopping software.
W~ ~l/1$~92 CA 02376337 2002-02-15 pCT/US00/21232
Some on-line merchants may also support the ability
for a cardholder to negotiate for the price of items
(such as by presenting frequent shopper identification
or information about a competitor's pricing).
5 4. The cardholder selects the means of payment.
SET focuses on the case when a payment card is
selected.
5. The cardholder sends the merchant a completed
order along with a means of payment. In SET, the order
10 and the payment instructions are digitally signed by
cardholders who possess certificates.
6. The merchant requests payment authorization
from the cardholder's financial institution via the
acquirer. If authorization succeeds, the merchant may
send confirmation of the order out of band to SET.
7. The merchant ships the goods or performs the
services requested from the order.
8. The merchant requests payment from the
cardholder's financial institution via acquirer.
SET changes the way that participants in a
payment system interact. In a face-to-face retail
transaction or a mail order transaction, electronic
processing begins with the merchant or the acquirer.
However, in a SET transaction, the electronic
processing begins with the cardholder.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
11
A prior art SET system model is illustrated in
Figure 1 and consists of the following:
Cardholder Functions: In the electronic commerce
environment, consumers and corporate purchasers
("cardholders") interact with merchants from personal
computers. A cardholder 10 uses a payment card that
has been issued by an Issuer 30. SET ensures that in
the cardholder's interactions with the merchant 20,
the payment card account information remains
confidential.
The cardholder's primary interface in SET is to
merchant systems 20. This interface supports the
cardholder's portion of the payment protocol, which
enables the cardholder 10 to initiate payment, perform
inquiries, and receive order acknowledgment and
status.
The cardholder 10 also has an indirect interface
to an Acquirer 40 through the merchant system 20. This
interface supports encrypted data fields that are sent
via the Merchant 20 to the Acquirer 40, but can only
be decrypted by the Payment Gateway 50. This enables
the Acquirer 40 to mediate interactions between the
cardholder 10 and Merchant 20, and by so doing provide
security services to the cardholder 10. These security
services ensure that the cardholder 10 is dealing with
a valid, payment card-approved merchant 20.
CA 02376337 2002-02-15
WO 01/15092 PCTNS00/21232
12
Depending upon the policies established by the
payment card brand, the cardholder 10 may also
interface with a Cardholder Certificate Authority
(CCA) 60 to request and renew public key certificates
that support electronic commerce security functions.
Performing cryptographic functions in hardware
cryptographic modules is recommended, but not required
by SET. SET encourages but does not mandate the use of
tamper resistant hardware for secret key generation
and storage and associated cryptographic functions.
The cardholder system supports the following
security services: integrity, authentication,
certificate management as prescribed by SET, in
addition to supporting shopping, payment selection,
and communication functions.
Issuer Functions: An Issuer 30 is a financial
institution that establishes an account for a
cardholder and issues the payment card. The Issuer
guarantees payment for authorized transactions using
the payment card in accordance with payment card brand
regulations and local legislation.
The SET merchant computer system 20 provides an
interface to the cardholder 10 for the support of
electronic payments. In addition, the merchant 10
interfaces with the Acquirer 40 using the payment
protocol to receive authorization and capture services
WO 01/15092 CA 02376337 2002-02-15 pCT~S00/21232
13
for electronic payment transactions. The merchant 20
interfaces with a Merchant Certificate Authority (MCA)
70 to request and renew public key certificates that
support electronic commerce security functions.
The merchant 20 supports SET protocols for the
authorization of electronic commerce transactions
initiated by the cardholder 10. In addition, the
merchant system 20 supports security services
(integrity, authentication, certificate management).
Merchant system 20 supports shopping, payment
selection, and communications functions. SET strongly
recommends but does not require performing
cryptographic functions and storing secret key
generation in hardware cryptographic modules (i.e.,
smart card). Payment card brand requirements for a
specific implementation and environment in which the
merchant server 20 may operate dictate requirements
for the use of hardware cryptographic support.
Merchant Functions: A merchant 20 offers goods
for sale or provides services in exchange for payment.
With SET, the merchant 20 offers its cardholders 10
secure electronic interactions. A merchant 20 that
accepts payment cards must have a relationship with an
Acquirer 40.
Acquirer Functions: An Acquirer 40 is the
financial institution that establishes an account with
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
14
a merchant 20 and processes payment card
authorizations and payments. The Acquirer 40 is
responsible for gathering the financial data related
to the transaction in order to obtain authorization
for payment from the cardholder's Issuer 30.
Payment Gateway Functions: A payment gateway 50
is a device operated by an Acquirer 40 or a designated
third party that processes merchant payment messages,
including payment instructions from cardholders 10.
The payment gateway system 50 is operated by the
Acquirer 40. It provides electronic commerce services
to the merchants 20 in support of the Acquirer 40, and
interfaces with the payment card's financial network
to support the authorization and capture of
transactions. The payment card's financial network
interface is largely unchanged from the interface
supporting Acquirers today. The Payment Gateway 50
also interfaces with the Payment Gateway Certificate
Authority (PCA) 80 for requesting and renewing public
key certificates to support the electronic commerce
security functions. It supports the distribution of
certificate revocation lists (CRLs) on behalf of the
brand and financial institution. Cryptographic
functions are performed in hardware cryptographic
modules. In addition, secret key generation and
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
storage uses tamper resistant hardware cryptographic
modules.
Brand Functions: Financial institutions have
founded payment card brands that protect and advertise
5 the brand, establish and enforce rules for use and
acceptance of their payment cards, and provide
networks to interconnect the financial institutions.
Other brands are owned by financial services companies
that advertise the brand, and establish and enforce
10 rules for use and acceptance of their payment cards.
These brands combine the roles of Issuer 30 and
Acquirer 40 (e. g., Visa, MasterCard) in interactions
with cardholders 10 and merchants 20.
Third parties Functions: Issuers 30 and Acquirers
15 40 sometimes choose to assign the processing of
payment card transactions to third-party processors.
SET does not distinguish between the financial
institution and the processor of the transactions.
Certificate Handling: SET certificate issuance
relies heavily on hierarchy of trust. SET certificates
are verified through a hierarchy of trust. Each
certificate is linked to the signature certificate of
the entity that digitally signed it. By following the
trust tree to a known trusted party, there is added
assurance that the certificate is valid. For example,
a cardholder certificate is linked to the certificate
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
16
of the Issuer (or the Brand on behalf of the Issuer).
The Issuer's certificate is linked back to a root key
through the Brand's certificate. The public signature
key of the root is known to all SET software and may
be used to verify each of the certificates in turn.
SET defines the certificate management
architecture, protocols, concepts, certificate format,
certificate revocation, list and certificate authority
to certify authority messages.
The following characteristics are readily
identifiable from the previous discussion of the SET
e-commerce models:
1. SET assumes different operational models than
current credit-cards, requiring new systems to
be put in place.
2. SET models are overly complex. The boundaries
between the different players are maintained
and the solutions are workarounds to keep
these pre-existing and proprietary boundaries
intact. This gets in the way of ubiquitous
smart card based implementations.
3. Many transactional steps are required for a
single purchase transaction in SET. Each step
translates to several steps. Errors may occur
at each step and the entire process becomes
more vulnerable and less robust.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
17
4. Certificate administration, maintenance and
revocation procedures for each of the
participants in SET (clients, merchants, and
payment gateways) is not trivial.
5. SET systems were not designed to accommodate
the business model used in interactive cable
television systems, where the MSO has first
hand knowledge of the transactions taking
place on its network. In such systems, the MSO
is under the control of the financial
institution and the agreements that are in
place, but has no means of directly
determining the amount of revenue generated by
the subscribers residing on the MSO's network.
Nor does the MSO have any control means for
non-repudiation.
6. The scalability model for the Internet is
different from television viewing (i.e., home
shopping). Impulse purchase of advertised
items by a large number of subscribers is not
within the SET model.
It would be advantageous to provide a secure
scheme for e-shopping over existing cable television
networks that is simple, efficient, and consumer
friendly as compared to pre-existing models such as
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
18
SET. It would be further advantageous to provide such
a scheme that is a straightforward extension to
existing systems. The present invention enables the
principal functions in e-commerce, in particular
electronic-shopping, in a coherent and less complex
manner when compared to the previously described
functional model. The present invention provides
methods and systems having the aforementioned and
other advantages.
CA 02376337 2002-02-15
WO 01/15092 PCT/USOO121232
19
SUMMARY OF THE INVENTION
In accordance with the present invention, a
method and system is provided to support e-commerce
transactions via an entertainment terminal or the
like.
In a particular embodiment of the invention, e-
commerce transactions between a merchant and a
consumer are enabled via an entertainment terminal
capable of providing a consumer with access to a
selection of goods and services provided by one or
more merchants via a merchant transaction server. The
entertainment terminal has a client application with a
purchase application program interface. A merchant
transaction server is provided which is capable of
communicating with the terminal. A purchase request
for the goods or services to be purchased is sent to
the merchant transaction server from the terminal.
This request is encrypted and sent in a secure manner,
together with a consumer's public key and certificate,
to enable the merchant transaction server to
communicate securely with the consumer. An encrypted
response is sent from the merchant transaction server
to the terminal. This encrypted response includes
transaction information. The encrypted response is
decrypted at the terminal and the consumer pays the
merchant for the purchase.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
In a further embodiment of the invention, the
terminal is provided with a smart card interface
enabling the consumer to pay the merchant.
In another embodiment, the smart card may be
5 provided with a cryptographic engine enabling
encryption and decryption. In this embodiment, the
purchase request may be encrypted by the smart card
prior to being sent to the merchant transaction
server. The smart card may also decrypt the encrypted
10 response from the merchant transaction server.
In a further embodiment, the consumer pays the
merchant through a credit transaction wherein consumer
credit against an item cost of the item purchase
request is verified and the transaction is authorized
15 or denied based on verification of credit.
In a particular embodiment, the selection of
goods and services is provided via a global
communication network. Alternatively, the selection of
goods and services may be provided by a system
20 operator. The system operator may be a cable
television system operator, a satellite television
system operator, an Internet Service Provider, or the
like.
In a further embodiment, the goods and services
enabled by the system operator may be from a plurality
of merchants offered via an MSO portal.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
21
The entertainment terminal may be a cable
television set-top box, a digital television or host
with point of deployment capability, or the like.
In a further embodiment of the invention, the
encrypted response is decrypted by the client
application in the terminal which invokes the
corresponding cryptographic routines via designated
application program interface routines.
In another embodiment of the invention, the
transaction information includes at least one of a
transaction identifier, an item identifier, and item
cost.
In a further embodiment, a unique transaction
identifier is generated by a purchase application
program interface routine which corresponds to the
transaction identifier provided by the merchant
transaction server.
In another embodiment, the client application
tracks different consumers purchasing from the
terminal.
The terminal may also have a secure processor
with memory to retain the transaction information for
secure storage.
In a particular embodiment, the consumer is pre-
approved for a predetermined credit limit. The
consumer's credit is verified against the cost of the
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
22
purchase request. The item cost is then checked
against a current account balance maintained by the
secure processor. If the current balance is greater
than the item cost, a transaction confirmation is
generated at the secure processor. The transaction
confirmation is sent from the secure processor via the
purchase application program interface back to the
client application. The transaction confirmation is
then sent from the client application to the merchant
transaction server so that the transaction can be
completed. The current balance is then decremented by
the item cost to pay the merchant.
In a further embodiment, the merchant transaction
server can verify the validity of the consumer's
public key and certificate.
In another embodiment, the terminal can securely
report the purchase back to the headend transaction
server (i.e. system operator) after the purchase
transaction is completed.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/Z1232
23
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram of the prior art SET
System Model; and
Figure 2 is a block diagram of an embodiment of
the present invention.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
24
DETAILED DESCRIPTION OF THE INVENTION
The methods and systems of the present invention
securely enable the principal functions in e-commerce,
in particular electronic shopping, in a coherent and
less complex manner when compared to existing models
(e. g., the previously described SET functional model).
It is of direct application to MSO electronic stores
with one or more affiliated merchants. Advantageously,
the invention can be used to enable e-shopping
transactions via an entertainment terminal, such as
the DCT-5000 series digital cable television set-top
terminals available from General Instrument
Corporation, of Horsham, Pennsylvania, USA, the
assignee of the present invention.
Extending the capabilities of existing cable
television systems (such as the DigiCipher~ II (DCII)
system available from General Instrument Corporation,
of Horsham, Pennsylvania, USA) to support e-commerce
provides a potentially compelling alternative when
contrasted with the SET and other known
implementations. It offers the existing base of cable
system operators an alternate avenue to controlling e-
commerce, facilitating a per-transaction tracking
and/or revenue collection and monitoring. The billing,
however, can still be done by the card issuer or the
associated bank. One of the considerations for MSO's
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
turning to Card Issuers is to prevent e-commerce
purchases from being included on the subscriber's
monthly cable television bill (issued by the MSO).
This can be achieved without the added implication of
5 relinquishing MSO control of e-commerce in their
system.
The invention can best be illustrated by
describing three basic levels of integration. Before
referring to the Figures, a brief overview of the
10 three levels of integration is provided:
1. First Level of Integration: (Basic integration -
minimal changes to integrated components). This
enables smart-card portability for various e-commerce
scenarios. This solution assumes that smart cards are
15 to be supported via a corresponding peripheral
interface to the entertainment terminal. The
integration is done with existing e-commerce models
(MSO issues aside). In this case the DCT-5000 or
similar end user device would have to have the
20 appropriate e-commerce client application present. The
consumers would also have to have the appropriate
smart cards issued ahead of time. The transactions
happen transparently to the MSO's network via the
Internet connecting the client application to the
25 merchant server and the financial institution. This
level is required in the event that the same smart
CA 02376337 2002-02-15
WO 01/15092 PCTNS00/21232
26
card must be used in other environments for other
applications.
2. Second level of Integration: (Minimal integration -
utilizing existing Cryptographic Services, such as
those supported by a secure processor resident in the
entertainment terminal). This level of integration
facilitates some of the security functions needed by
the client application via the secure processor. To
what degree the need for an intelligent smart card is
eliminated depends on how the client application is
integrated with the security functions resident in the
terminal. Various advantages result by eliminating the
need for an intelligent smart card (i.e., one without
keys and without cryptographic engines). These include
reduced cost, operational simplifications, and user
friendliness (e.g., the user does not have to walk to
the terminal to swipe the card or keep it there;
instead the user just pushes the button on the screen
or remote control).
3. Third level of integration: (Optimized integration
- utilizing existing system capabilities with a
commercially available transaction server). Extends
existing system capabilities to support e-shopping in
a case where the MSO or a designee is providing the
electronic store. In this case, the merchant and the
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
27
MSO may be considered one and the same or the MSO may
utilize one or more affiliated merchant servers.
An example of a simplified method in accordance
with the invention consists of the following steps:
1. A consumer forwards a purchase requests for an item
to a Merchant via an entertainment terminal, using a
process similar to SET. The consumer provides its
public key as part of the transaction. (SSL is
utilized for underlying communication).
2. The merchant may contact the MSO's Validation
Authority server for certificate validation.
3. The merchant responds by forwarding transaction
information to the terminal, such as transaction
identifier (ID), item ID, and other relevant
parameters encrypted using the consumer's public key.
4. A client application in the terminal uses a
suitable cryptographic services Purchase API
(application program interface) and other API's to
decrypt the response, while a secure processor in the
terminal retains the transaction identifiers and the
associated cost for secure storage. The client
application can keep track of different users - from
the secure processor's perspective, it is one
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
28
household account although the user ID may have
different values as determined by the Client
application. The Purchase API generates a unique
transaction ID corresponding to that issued by the
server.
5. The secure processor checks the amount against a
current balance, and if remaining balance is greater
than zero, the secure processor decrements the
purchase amount and sends a transaction confirmation
back via the Purchase API. The processor generates the
report back in a similar manner as done for IPPV
purchase to a system controller subtending transaction
server (real time delivery). In particular, the report
back is sent via upstream communication which is
forwarded to the transaction server for further
processing.
6. The transaction server contacts the Collection
Point to forward the information for billing purposes.
The collection point forms the interface with the
financial institution for billing purposes. This
interface may utilize existing interfaces (some are
based on the applicable ISO standard).
7. If the balance is to be tracked by the secure
processor and the MSO's transaction server, then steps
5 and 6 apply. Otherwise the Merchant's transaction
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
29
server would contact the financial institution
directly.
8. The financial institution performs the same
functions done today by paying the merchant, and bills
the MSO's subscriber for payment.
In a particular embodiment of the invention as
shown in Figure 2, e-commerce transactions between a
merchant 135 and a consumer are enabled via an
entertainment terminal 100 capable of providing a
consumer with access to a selection of goods and
services 140 provided by one or more merchants) 135
via a merchant transaction server 150. The
entertainment terminal 100 having a client application
120 (which may be comprised of firmware and/or
software) which also utilizes application program
interface routines to allow it to interact with
cryptographic service routines in the terminal.
Merchant transaction server 150 is capable of
communicating with the terminal 100. A purchase
request for the goods or services 140 to be purchased
is sent to the merchant transaction server 150 from
the terminal 100. This request is encrypted and sent
in a secure manner, together with a consumer's public
key and certificate, to enable the merchant
transaction server 150 to communicate securely with
CA 02376337 2002-02-15
WO 01/15092 PCTNS00/21232
the consumer. An encrypted response is sent from the
merchant transaction server 150 to the terminal 100.
This encrypted response includes transaction
information. The encrypted response is decrypted at
5 the terminal 100 and the consumer pays the merchant
135 for the purchase.
In order to provide for payment to the merchant
135, the merchant transaction server 150 contacts a
collection point 170 and forwards the transaction
10 information for billing purposes. The collection point
170 forms an interface with a financial institution
180 for billing and payment purposes. The financial
institution 180 can then pay the merchant 135 (e. g.,
electronically via the merchant transaction server
15 150, via electronic funds transfer to a merchant's
bank, or the like). Affiliation with the billing
system of a system operator 145 is not required and
hence separation of billing for MSO services versus
purchase transactions is achieved.
20 Delivery 160 of the selected goods and/or
services is provided for.
In a further embodiment of the invention, the
terminal 100 is provided with a smart card interface
130 enabling the consumer to pay the merchant 135.
25 In another embodiment, a smart card used with the
smart card interface 130 may be provided with a
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
31
cryptographic engine enabling encryption and
decryption. In this embodiment, the purchase request
may be encrypted by the smart card via the smart card
interface 130 prior to being sent to the merchant
transaction server 150. The smart card may also
decrypt the encrypted response from the merchant
transaction server 150.
In a further embodiment, the consumer pays the
merchant 135 through a credit transaction wherein
consumer credit against an item cost of the item
purchase request is verified and the transaction is
authorized or denied based on verification of credit.
In a particular embodiment, the selection of
goods and services 140 is provided via a global
communication network. Alternatively, the selection of
goods and services 140 may be provided by a system
operator 145. In both instances, the goods and
services are coupled with the merchant transaction
server 135, whether the merchant is the MSO or an
independent party.
The system operator 145 may be a cable television
system operator, a satellite television system
operator, an Internet Service Provider, or the like.
where the goods and services are provided by an MSO
(e.g., an electronic store run by the MSO), the MSO
may take on the merchant role or contract with one or
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
32
more merchants to be part of the MSO's electronic
store.
In a further embodiment, the goods and services
140 enabled by the system operator 145 are from a
plurality of merchants offered via an MSO portal.
The entertainment terminal 100 may be a cable
television set-top box, a digital television or host
with point of deployment capability, or the like.
In a further embodiment of the invention, the
encrypted response is decrypted by the client
application 120 in the terminal 100 which invokes the
corresponding cryptographic routines via designated
application program interface routines.
In another embodiment of the invention, the
transaction information includes at least one of a
transaction identifier, an item identifier, and item
cost.
In a further embodiment, a unique transaction
identifier is generated by a purchase application
program interface routine in the terminal 100 which
unique transaction identifier corresponds to the
transaction identifier provided by the merchant
transaction server 150. Such a unique transaction
identifier facilitates non-repudiation measures for
the transaction at the client and the server sides.
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
33
In another embodiment, the client application 120
in the terminal 100 tracks different consumers
purchasing from the terminal 100.
The terminal 100 may also have a secure processor
110 with memory to retain the transaction information
for secure storage (e.g., for subsequent retrieval by
the system operator or by the merchant).
In a particular embodiment, the consumer is pre-
approved for a predetermined credit limit. The
consumer's credit is verified against the cost of the
purchase request. The item cost is then checked
against a current account balance maintained by the
secure processor 110. If the current balance is
greater than the item cost, a transaction confirmation
is generated at the secure processor 110. The
transaction confirmation is sent from the secure
processor 110 and associated firmware via the purchase
application program interface back to the client
application 120. The transaction confirmation is then
sent from the client application 120 to the merchant
transaction server 150 so that the transaction can be
completed. The current balance is then decremented by
the item cost to pay the merchant.
In a further embodiment, the merchant transaction
server 150 can verify the validity of the consumer's
public key and certificate by using a Validation
CA 02376337 2002-02-15
WO 01/15092 PCT/US00l21232
34
Authority offered by the MSO or by an alternate party
on behalf of the MSO.
In another embodiment, the terminal 100 can
securely report the purchase back to the headend
transaction server at the system operator 145 after
the purchase transaction is completed.
It should now be appreciated that the present
invention provides an advantageous method and system
for providing secure e-shopping over existing cable
television networks that is simple, efficient, and
consumer friendly. In particular, the present
invention provides such a scheme that is a
straightforward extension to existing systems. The
present invention enables the principal functions in
e-commerce, in particular electronic shopping, in a
coherent and less complex manner when compared to the
prior art models.
There are different approaches to utilizing smart
cards in support of e-commerce in existing cable
television systems, each with varying levels of added
value to the MSO and affiliated customers as well as
varying levels of integration complexity. Affording
the MSO with system solutions for e-commerce by simple
extensions to existing systems is desirable. Basic
integration is also achievable, even though for e-
shopping via the MSO electronic store scenario, much
CA 02376337 2002-02-15
WO 01/15092 PCT/US00/21232
simplification is realizable. Additionally, providing
the MSO control over non-repudiation and direct
visibility into transaction revenue are capabilities
facilitated by the illustrated approach but are not as
5 readily facilitated by alternate approaches.
Although the invention has been described in
connection with various illustrated embodiments,
numerous modifications and adaptations may be made
thereto without departing from the spirit and scope of
10 the invention as set forth in the claims.
