EP1210694A2 - A method and system for the provision of electronic commerce and shopping via cable television systems and associated entertainment terminals - Google Patents

A method and system for the provision of electronic commerce and shopping via cable television systems and associated entertainment terminals

Info

Publication number
EP1210694A2
EP1210694A2 EP00950969A EP00950969A EP1210694A2 EP 1210694 A2 EP1210694 A2 EP 1210694A2 EP 00950969 A EP00950969 A EP 00950969A EP 00950969 A EP00950969 A EP 00950969A EP 1210694 A2 EP1210694 A2 EP 1210694A2
Authority
EP
European Patent Office
Prior art keywords
accordance
merchant
purchase
transaction
consumer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00950969A
Other languages
German (de)
French (fr)
Inventor
Reem Safadi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Arris Technology Inc
Original Assignee
Arris Technology Inc
General Instrument Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Arris Technology Inc, General Instrument Corp filed Critical Arris Technology Inc
Publication of EP1210694A2 publication Critical patent/EP1210694A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user

Definitions

  • 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.
  • SET Secure Electronic Transaction Specification
  • existing e-commerce models are overly complex and are not particularly well suited for use by cable television system operators and their subscribers.
  • 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 be objectionable and is clearly inconvenient.
  • 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.
  • MSO multiple system cable operators
  • 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.
  • smart cards 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 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) .
  • 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) (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.
  • PKC public key cryptography
  • 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 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 certificate. In this manner, the manufacturer takes on the role of a certificate authority.
  • 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.
  • MD5 - 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.
  • 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 .
  • the 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.
  • SSL Secure Sockets Layer
  • Netscape a protocol developed by Netscape to allow client software to securely communicate with servers.
  • 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 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.
  • the typical electronic shopping experience can be divided into several distinct phases:
  • 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.
  • the cardholder selects items to be purchased from a merchant.
  • 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. 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) .
  • the cardholder selects the means of payment .
  • SET focuses on the case when a payment card is selected.
  • the cardholder sends the merchant a completed order along with a means of payment.
  • the order and the payment instructions are digitally signed by cardholders who possess certificates.
  • 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.
  • the merchant ships the goods or performs the services requested from the order.
  • the merchant requests payment from the cardholder's financial institution via acquirer.
  • SET changes the way that participants in a payment system interact.
  • electronic processing begins with the merchant or the acquirer.
  • the electronic processing begins with the cardholder.
  • Figure 1 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.
  • 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.
  • CCA Cardholder Certificate Authority
  • 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.
  • 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.
  • the merchant 10 interfaces with the Acquirer 40 using the payment protocol to receive authorization and capture services 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.
  • MCA Merchant Certificate Authority
  • the merchant 20 supports SET protocols for the authorization of electronic commerce transactions initiated by the cardholder 10.
  • 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) .
  • 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 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.
  • 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.
  • PCA Payment Gateway Certificate Authority
  • Cryptographic functions are performed in hardware cryptographic modules.
  • secret key generation and storage uses tamper resistant hardware cryptographic modules .
  • Brand Functions Financial institutions have founded payment card brands that protect and advertise 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 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.
  • Issuer 30 and Acquirer 40 e.g., Visa, MasterCard
  • 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 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:
  • 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 . 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.
  • 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 .
  • 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 .
  • a method and system is provided to support e-commerce transactions via an entertainment terminal or the like.
  • 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.
  • the terminal is provided with a smart card interface enabling the consumer to pay the merchant.
  • the smart card may be provided with a cryptographic engine enabling encryption and decryption.
  • 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 response from the merchant transaction server.
  • 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 or denied based on verification of credit.
  • the selection of goods and services is provided via a global communication network.
  • the selection of goods and services may be provided by a system operator.
  • the system operator may be a cable television system operator, a satellite television system operator, an Internet Service Provider, or the like.
  • the goods and services enabled by the system operator may be from a plurality of merchants offered via an MSO portal.
  • the entertainment terminal may be a cable television set-top box, a digital television or host with point of deployment capability, or the like.
  • the encrypted response is decrypted by the client application in the terminal which invokes the corresponding cryptographic routines via designated application program interface routines.
  • the transaction information includes at least one of a transaction identifier, an item identifier, and item cost .
  • 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.
  • 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 .
  • 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. 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.
  • the merchant transaction server can verify the validity of the consumer's public key and certificate.
  • the terminal can securely report the purchase back to the headend transaction server (i.e. system operator) after the purchase transaction is completed.
  • the headend transaction server i.e. system operator
  • Figure 1 is a block diagram of the prior art SET System Model
  • FIG. 2 is a block diagram of an embodiment of the present 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
  • 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.
  • 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
  • DCII DigiCipher ® II
  • the invention can best be illustrated by describing three basic levels of integration. Before referring to the Figures, a brief overview of the three levels of integration is provided:
  • 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 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 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 merchant server and the financial institution. This level is required in the event that the same smart card must be used in other environments for other applications .
  • 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) .
  • 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 MSO may be considered one and the same or the MSO may utilize one or more affiliated merchant servers.
  • 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) .
  • the merchant may contact the MSO's Validation Authority server for certificate validation.
  • 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.
  • ID transaction identifier
  • item ID item ID
  • other relevant parameters encrypted using the consumer's public key.
  • 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 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.
  • 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 .
  • 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) .
  • steps 5 and 6 apply. Otherwise the Merchant's transaction server would contact the financial institution directly.
  • the financial institution performs the same functions done today by paying the merchant, and bills the MSO's subscriber for payment.
  • 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 merchant (s) 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 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 the terminal 100 and the consumer pays the merchant 135 for the purchase.
  • the merchant transaction server 150 contacts a collection point 170 and forwards the transaction 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 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. Delivery 160 of the selected goods and/or services is provided for.
  • the terminal 100 is provided with a smart card interface 130 enabling the consumer to pay the merchant 135.
  • a smart card used with the smart card interface 130 may be provided with a cryptographic engine enabling encryption and decryption.
  • 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.
  • 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.
  • the selection of goods and services 140 is provided via a global communication network.
  • the selection of goods and services 140 may be provided by a system operator 145.
  • 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 more merchants to be part of the MSO's electronic store .
  • MSO e.g., an electronic store run by the MSO
  • 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.
  • 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.
  • the transaction information includes at least one of a transaction identifier, an item identifier, and item cost .
  • 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.
  • 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) .
  • 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.
  • the merchant transaction server 150 can verify the validity of the consumer's public key and certificate by using a Validation Authority offered by the MSO or by an alternate party on behalf of the MSO.
  • 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.
  • 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.
  • 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 .

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

The methods and systems of the present invention securely enable the principal functions in e-commerce, in a coherent and less complex manner when compared to existing models. It is of direct application to MSO electronic stores with one or more affiliated merchants. Advantageously, the invention can be used to enable e-commerce transactions between a merchant (135) and a consumer via an entertainment terminal (100). The entertainment terminal (100) is capable of providing a consumer with access to a selection of goods and services (140) provided by one or more merchant(s) (135) via a merchant transaction server (150). The invention offers the existing base of cable system operators an alternate avenue to control e-commerce, facilitate per-transaction tracking and/or revenue collection and monitoring.

Description

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 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 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) (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 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 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.
MD5 - 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 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 . 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. • 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 Negotiation and Ordering
Payment Selection
SET ^ Payment Authorization and Transport
SET ■► Confirmation and Inquiry
Delivery of Goods
SET ■► 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. 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) . 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 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. 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. 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 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 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 storage uses tamper resistant hardware cryptographic modules .
Brand Functions: Financial institutions have founded payment card brands that protect and advertise 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 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 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 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 . 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 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 .
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. 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 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 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 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 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. 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 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.
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.
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 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 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 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 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 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 merchant server and the financial institution. This level is required in the event that the same smart 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 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 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 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 merchant (s) 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 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 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 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 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. 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. In another embodiment, a smart card used with the smart card interface 130 may be provided with a 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 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. 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 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 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 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 the invention as set forth in the claims.

Claims

What is claimed is:
1. A method for enabling an entertainment terminal to be used for e-commerce transactions between a consumer and a merchant, comprising the steps of: enabling the consumer to access a selection of goods and services via the terminal; sending a purchase request for the goods or services to be purchased to a merchant transaction server, said request being encrypted and sent in a secure manner, together with a consumer's public key and certificate, to enable the merchant transaction server to securely communicate with the consumer; providing an encrypted response from the merchant transaction server to the consumer, said encrypted response including transaction information; decrypting the response from the merchant transaction server; and arranging for payment for the purchase .
2. A method in accordance with claim 1, wherein payment for the purchase is accomplished through the use of a smart card interface in the terminal .
3. A method in accordance with claim 2, wherein; the purchase request is encrypted by a smart card; and the encrypted response from the merchant transaction server is decrypted by the smart card.
4. A method in accordance with claim 1, wherein the step of arranging for payment comprises: verifying consumer credit against an item cost of the item purchase request; and authorizing or denying the transaction based on verification of credit.
5. A method in accordance with claim 1, wherein the selection of goods and services is provided via a global communication network.
6. A method in accordance with claim 1, wherein the selection of goods and services is provided by a system operator.
7. A method in accordance with claim 6, wherein the system operator is one of a cable television system operator, a satellite television system operator, or an Internet Service Provider.
8. A method in accordance with claim 6, wherein the goods and services enabled by the system operator are from a plurality of merchants.
9. A method in accordance with claim 1, wherein the entertainment terminal is one of a cable television set-top box, a digital television or host with point of deployment capability.
10. A method in accordance with claim 1, wherein the step of decrypting the response from the merchant transaction server comprises: having a client application in the terminal invoke the corresponding cryptographic routines via designated application program interface routines; and using the cryptographic routines to decrypt the response.
11. A method in accordance with claim 1, wherein the transaction information includes at least one of a transaction identifier, an item identifier, and item cost .
12. A method in accordance with claim 11, comprising the further step of generating a unique transaction identifier by a purchase application program interface routine which corresponds to the transaction identifier provided by the merchant transaction server.
13. A method in accordance with claim 1, wherein a client application tracks different consumers purchasing from the terminal.
14. A method in accordance with claim 1, comprising the further step of retaining the transaction information at a secure processor' s memory for secure storage.
15. A method in accordance with claim 14, wherein the step of arranging for payment comprises: verifying consumer credit against the cost of the purchase request; checking the item cost against a current account balance maintained by the secure processor; generating a transaction confirmation at the secure processor if the current balance is greater than the item cost; sending the transaction confirmation from the secure processor via the purchase application program interface back to the client application; sending the transaction confirmation from the client application to the merchant transaction server; and decrementing the current balance by the item cost .
16. A method in accordance with claim 1, further comprising the step of: verifying the validity of the consumer's public key and certificate.
17. A method in accordance with claim 1, further comprising the step of securely reporting the purchase from the terminal back to a system operator after the purchase transaction is completed.
18. A method in accordance with claim 1, wherein the purchase request for goods and services includes one of a purchase of merchandise, a purchase of specific applications, or a purchase of media streaming events.
19. A system for enabling e-commerce transactions between a consumer and a merchant, comprising: an entertainment terminal capable of providing a consumer with access to a selection of goods and services and having a client application with a purchase application program interface; a merchant transaction server capable of communicating with the terminal; wherein: a purchase request for the goods or services to be purchased is sent to the merchant transaction server from the terminal, said request being 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, which encrypted response includes transaction information; the encrypted response is decrypted; and the consumer pays the merchant for the purchase .
20. A system in accordance with claim 19, further comprising a smart card interface in the terminal enabling the consumer to pay the merchant.
21. A system in accordance with claim 20, wherein: the purchase request is encrypted by a smart card; and the encrypted response from the merchant transaction server is decrypted by the smart card.
22. A system in accordance with claim 19, wherein the consumer pays the merchant through a credit transaction comprising: verifying consumer credit against an item cost of the item purchase request ; and authorizing or denying the transaction based on verification of credit.
23. A system in accordance with claim 19, wherein the selection of goods and services is provided via a global communication network.
24. A system in accordance with claim 19, wherein the selection of goods and services is provided by a system operator.
25. A system in accordance with claim 24, wherein the system operator is one of a cable television system operator, a satellite television system operator, or an Internet Service Provider.
26. A system in accordance with claim 24, wherein the goods and services enabled by the system operator are from a plurality of merchants.
27. A system in accordance with claim 19, wherein the entertainment terminal is one of a cable television set-top box, a digital television or host with point of deployment capability.
28. A system in accordance with claim 19, wherein the encrypted response is decrypted by the client application in the terminal which invokes the corresponding cryptographic routines via designated application program interface routines.
29. A system in accordance with claim 19, wherein the transaction information includes at least one of a transaction identifier, an item identifier, and item cost .
30. A system in accordance with claim 29, wherein 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.
31. A system in accordance with claim 19, wherein the client application tracks different consumers purchasing from the terminal.
32. A system in accordance with claim 19, wherein the terminal further comprises a secure processor with memory to retain the transaction information for secure storage .
33. A system in accordance with claim 32, wherein: the consumer is pre-approved for a predetermined credit limit; consumer credit against the cost of the purchase request is verified; the item cost is checked against a current account balance maintained by the secure processor; a transaction confirmation is generated at the secure processor if the current balance is greater than the item cost; the transaction confirmation is sent from the secure processor via the purchase application program interface back to the client application; the transaction confirmation is sent from the client application to the merchant transaction server; and the current balance is decremented by the item cost to pay the merchant .
34. A system in accordance with claim 19, wherein the merchant transaction server verifies the validity of the consumer's public key and certificate.
35. A system in accordance with claim 19, wherein the terminal securely reports the purchase back to a system operator after the purchase transaction is completed.
36. A system in accordance with claim 19, wherein the purchase request for goods and services includes one of a purchase of merchandise, a purchase of specific applications, or a purchase of media streaming events.
EP00950969A 1999-08-25 2000-08-03 A method and system for the provision of electronic commerce and shopping via cable television systems and associated entertainment terminals Withdrawn EP1210694A2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15067999P 1999-08-25 1999-08-25
US150679P 1999-08-25
PCT/US2000/021232 WO2001015092A2 (en) 1999-08-25 2000-08-03 A method and system for the provision of electronic commerce and shopping via cable television systems and associated entertainment terminals

Publications (1)

Publication Number Publication Date
EP1210694A2 true EP1210694A2 (en) 2002-06-05

Family

ID=22535559

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00950969A Withdrawn EP1210694A2 (en) 1999-08-25 2000-08-03 A method and system for the provision of electronic commerce and shopping via cable television systems and associated entertainment terminals

Country Status (8)

Country Link
EP (1) EP1210694A2 (en)
JP (1) JP2003526840A (en)
KR (1) KR20020021413A (en)
CN (1) CN1421024A (en)
AU (1) AU6398800A (en)
BR (1) BR0013513A (en)
CA (1) CA2376337A1 (en)
WO (1) WO2001015092A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2647513A1 (en) 2012-04-03 2013-10-09 Hutchinson Air conditioning circuit duct provided with a noise reducing device, and circuit including it

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7324976B2 (en) * 2004-07-19 2008-01-29 Amazon Technologies, Inc. Automatic authorization of programmatic transactions
WO2013158081A1 (en) * 2012-04-17 2013-10-24 Intel Corporation Dynamic payment service
CN103686367A (en) * 2013-12-16 2014-03-26 康佳集团股份有限公司 Intelligent set top box application software download management method and system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0690399A3 (en) * 1994-06-30 1997-05-02 Tandem Computers Inc Remote financial transaction system
US5878141A (en) * 1995-08-25 1999-03-02 Microsoft Corporation Computerized purchasing system and method for mediating purchase transactions over an interactive network
US5778173A (en) * 1996-06-12 1998-07-07 At&T Corp. Mechanism for enabling secure electronic transactions on the open internet
US6490567B1 (en) * 1997-01-15 2002-12-03 At&T Corp. System and method for distributed content electronic commerce
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0115092A2 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2647513A1 (en) 2012-04-03 2013-10-09 Hutchinson Air conditioning circuit duct provided with a noise reducing device, and circuit including it

Also Published As

Publication number Publication date
JP2003526840A (en) 2003-09-09
WO2001015092A2 (en) 2001-03-01
BR0013513A (en) 2003-08-19
AU6398800A (en) 2001-03-19
CN1421024A (en) 2003-05-28
WO2001015092A3 (en) 2001-05-25
KR20020021413A (en) 2002-03-20
CA2376337A1 (en) 2001-03-01

Similar Documents

Publication Publication Date Title
US9349127B2 (en) Serial number and payment data based payment card processing
US6205437B1 (en) Open network payment system for providing for real-time authorization of payment and purchase transactions
US6947908B1 (en) System and use for correspondent banking
CA2753375C (en) Methods and apparatus for conducting electronic transactions
US20140180930A1 (en) Media device payments remote control personalization and protection
WO2000022559A1 (en) System and use for correspondent banking
JP2003531447A (en) Methods and systems for virtual safety
WO2001015092A2 (en) A method and system for the provision of electronic commerce and shopping via cable television systems and associated entertainment terminals
AU2015246170B2 (en) Module ID based encryption for financial transactions
Hwang et al. Greater protection for credit card holders: a revised SET protocol
AU2016202318B2 (en) Serial number and payment data based payment card processing
AU2016201533B2 (en) Serial number and payment data based payment card processing
Stallings The SET Standard & E-Commerce
Lähteenmäki Requirements for electronic payments and SET

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020313

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RBV Designated contracting states (corrected)

Designated state(s): AT BE CH CY DE FR GB LI NL

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050901

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525