Method for electronic merchandise dispute resolution

Abstract

A system for open electronic commerce having a customer trusted agent securely communicating with a first money module, and a merchant trusted agent securely communicating with a second money module. Both trusted agents are capable of establishing a first cryptographically secure session, and both money modules are capable of establishing a second cryptographically secure session. The merchant trusted agent transfers electronic merchandise to the customer trusted agent, and the first money module transfers electronic money to the second money module. The money modules inform their trusted agents of the successful completion of payment, and the customer may use the purchased electronic merchandise.

Claims

I claim:

1. A method for resolving a dispute over electronic merchandise utilizing a customer trusted agent, a first host processor, a merchant trusted agent, and a second host processor, comprising the steps of:

(a) establishing a cryptographically secure session between said customer trusted agent and said merchant trusted agent;

(b) said customer trusted agent sending transaction log data to said first host processor for choice of a dispute corresponding to an electronic ticket stored in said customer trusted agent;

(c) said first host processor sending dispute information to said customer trusted agent;

(d) said customer trusted agent sending a copy of said electronic ticket and said dispute information to said merchant trusted agent, via said cryptographically secure session;

(e) said merchant trusted agent validating said electronic ticket;

(f) said merchant trusted agent sending said electronic ticket and said dispute information to said second host processor;

(g) deciding to deny said dispute relating to said electronic ticket and said dispute information;

(h) said second host processor sending a dispute denied message to said merchant trusted agent;

(i) said merchant trusted agent reporting said dispute denied message to said customer trusted agent;

(j) said customer trusted agent committing; and

(k) said merchant trusted agent committing.

2. The method of claim 1, wherein step (j) includes the substep of logging the dispute denied transaction.

3. The method of claim 1, further comprising the steps of:

said customer trusted agent sending an electronic object corresponding to said electronic ticket to said merchant trusted agent;

validating said electronic object;

decrypting said electronic object using said electronic ticket; and

sending said decrypted electronic object to said second host processor for defect testing.

4. The method of claim 3, wherein said electronic object is a movie.

5. The method of claim 3, wherein said electronic object is computer software.

6. A method for resolving a dispute over electronic merchandise utilizing a customer trusted agent, a first host processor, a merchant trusted agent, and a second host processor, comprising the steps of:

(a) establishing a first cryptographically secure session between said customer trusted agent and said merchant trusted agent;

(b) said customer trusted agent sending transaction log data to said first host processor for choice of a dispute corresponding to an electronic ticket stored in said customer trusted agent;

(c) said first host processor sending dispute information to said customer trusted agent;

(d) said customer trusted agent sending a copy of said electronic ticket and said dispute information to said merchant trusted agent, via said first cryptographically secure session;

(e) said merchant trusted agent validating said electronic ticket;

(f) said merchant trusted agent sending said electronic ticket and said dispute information to said second host processor;

(g) deciding not to deny said dispute relating to said electronic ticket and said dispute information; and

(h) initiating a customer refund.

7. The method of claim 6, wherein step (h) includes the steps of:

said second host processor sending a message to said first host processor requesting customer resolution;

said first host processor informing said customer trusted agent that said customer resolution is a refund; and

said customer trusted agent sending a refund request to said merchant trusted agent, via said first cryptographically secure session.

8. The method of claim 7, further including the steps of:

establishing a second cryptographically secure session between a first money module associated with said customer trusted agent and a second money module associated with said merchant trusted agent;

said customer trusted agent providing first refund payment information to said first money module and said merchant trusted agent providing second refund payment information to said second money module; and

said second money module transferring electronic money in an amount consistent with said refund payment information, to said first money module via said second cryptographically secure session.

9. The method of claim 7, further including the steps of:

said merchant trusted agent sending a refund payment amount to said customer trusted agent via said cryptographically secure session;

said customer trusted agent sending a payment credential to said merchant trusted agent via said cryptographically secure session;

said merchant trusted agent validating said payment credential;

said merchant trusted agent sending said payment credential and said refund payment amount to an authorization network for refund authorization;

said merchant trusted agent receiving a refund authorization; and

said merchant trusted agent sending a refund authorization message to said customer trusted agent via said cryptographically secure session.

10. The method of claim 6, further comprising the steps of:

said customer trusted agent sending an electronic object corresponding to said electronic ticket to said merchant trusted agent;

validating said electronic object;

decrypting said electronic object using said electronic ticket; and

sending said decrypted electronic object to said second host processor for defect testing.

11. The method of claim 6, further comprising the steps of said merchant and customer trusted agents committing.

12. The method of claim 11, wherein the merchant and customer trusted agents non-provisionally maintain transaction log data after said committing steps.

13. A method for resolving a dispute over electronic merchandise utilizing a customer trusted agent, a first host processor, a merchant trusted agent, and a second host processor, comprising the steps of:

establishing a cryptographically secure session between said customer trusted agent and said merchant trusted agent;

said customer trusted agent sending transaction log data to said first host processor for choice of a dispute corresponding to an electronic ticket stored in said customer trusted agent;

said first host processor sending dispute information to said customer trusted agent;

said customer trusted agent sending a copy of said electronic ticket and said dispute information to said merchant trusted agent, via said cryptographically secure session;

said merchant trusted agent validating said electronic ticket;

said merchant trusted agent sending said electronic ticket and said dispute information to said second host processor;

deciding not to deny said dispute relating to said electronic ticket and said dispute information;

said merchant trusted agent requesting new electronic merchandise from a merchandise server;

said merchandise server sending new merchandise to said merchant trusted agent; and

said merchant trusted agent sending said new merchandise to said customer trusted agent via said cryptographically secure session.

14. The method of claim 13, further comprising the steps of:

said customer trusted agent sending an electronic object corresponding to said electronic ticket to said merchant trusted agent;

validating said electronic object;

decrypting said electronic object using said electronic ticket; and

sending said decrypted electronic object to said second host processor for defect testing.

15. The method of claim 13, further comprising the steps of said merchant and customer trusted agents committing.

16. The method of claim 14, wherein the merchant and customer trusted agents non-provisionally maintain transaction log data after said committing steps.

17. A system for resolving a dispute over electronic merchandise, comprising:

a tamper-proof customer trusted agent;

a tamper-proof merchant trusted agent that communicates with said customer trusted agent via a cryptographically secure session;

a trusted server;

where said merchant trusted agent sends electronic merchandise to said customer trusted agent via said cryptographically secure session, and said merchant trusted agent records a purchase transaction in its transaction log;

where said customer trusted agent receives and validates said electronic merchandise and records said purchase transaction in its transaction log;

where said customer and merchant trusted agents communicate to execute a first dispute protocol, and when said dispute is denied an indication of denial is recorded in said customer trusted agent's transaction log; and

where said customer trusted agent communicates with said trusted server to execute a second dispute protocol when the customer is not satisfied with the result of the first dispute protocol with the merchant.

Description

FIELD OF THE INVENTION

BACKGROUND OF THE INVENTION

Electronic commerce today is comprised of a collection of closed communities. Examples of such communities include local and long distance telephone companies, cable companies, cellular telephone companies, E-mail services, and electronic service providers such as Prodigy and CompuServe. Customers must enroll in each community in order to use the products and services provided. Thus, prior identification of the payer is required before electronic delivery of merchandise or services. The operator of the service can then either bill the customer, credit his/her loan account, or debit his/her deposit account.

With the advent of high-speed networks delivering entertainment and information on demand, the current billing and payment systems will be flooded with transactions. Consequently, the customer will be bombarded by invoices with numerous items for each billing period. Moreover, the customer's lifestyle will be exposed to each system operator due to the non-anonymous nature of the transactions.

One method of anonymous payment is described in my PCT patent application WO 93/10503 entitled "Electronic-Monetary System" published May 27, 1993, the disclosure of which is incorporated herein by reference. That application discloses an electronic monetary system for implementing electronic money payments as an alternative medium of exchange to cash, checks, credit cards, debit cards, and electronic funds transfers. In particular, the described system uses money modules packaged in tamper-proof housings to store and transfer electronic notes.

Money module payments may be either real-time, off-line payments between money modules (e.g., between a money module contained within a customer's "electronic wallet" and a money module contained within a merchant's point-of-sale terminal), or on-line payments for network services such as information retrieval and telephone calls, or for purchasing airline tickets, theater tickets, etc.

However, a serious problem with remote, anonymous purchase is the security of payment and delivery. If one wants to purchase a movie over the telephone anonymously, then how can the buyer be assured he will receive the movie if he pays first, or the seller be assured that he will be paid if he delivers the movie first? Thus, when purchasing anything from a remote location, it is customary today for the buyer and seller to first identify themselves, leading to a consequent loss of privacy.

SUMMARY OF THE INVENTION

Accordingly, it is an object of the invention to provide a system which will allow customers to buy electronic merchandise or services on demand without enrolling in an electronic community.

It is another object of the present invention to enable remote delivery of electronic merchandise or services with real-time anonymous payment or real-time authorization-based payment where neither the customer nor the merchant can interfere with the payment and delivery process once they have agreed to the transaction.

It is another object of the present invention to use trusted agents and money modules to create a system for open electronic commerce where both customers and merchants can securely transact remotely over electronic networks without prior knowledge of each other.

It is another object of the present invention to provide a secure electronic real-time purchase transaction between buyer and seller without third-party intervention.

According to one aspect of the invention, a customer trusted agent establishes a cryptographically secure session with a merchant trusted agent. The customer trusted agent securely communicates with a first money module, and the merchant trusted agent securely communicates with a second money module. The merchant trusted agent delivers electronic merchandise that is provisionally retained by the customer trusted agent. The trusted agents participate in a secure dialogue and mutually agree on the payment terms. The first money module transmits electronic money to the second money module. Upon successful completion of the money module payment, the first money module informs the customer trusted agent, and the second money module informs the merchant trusted agent. The merchant then logs the sale and the customer may use the purchased electronic merchandise.

According to a second aspect of the invention, the customer may pay for the electronic merchandise by presenting a credential representing a credit or debit card.

According to a third aspect of the invention, electronic tickets may be presented to other trusted agents in order to obtain services.

According to a fourth aspect of the invention, the trusted agents may be used for performing a secure identity-based payment.

According to a fifth aspect of the invention, the trusted agents may be used to resolve a dispute over purchased electronic merchandise.

DESCRIPTION OF THE DRAWINGS

The invention will be described in greater detail below with reference to the attached drawings, of which:

FIG. 1 is a diagram showing the trusted agent/money module interaction.

FIG. 2 illustrates the sections and fields of various tickets.

FIG. 3 illustrates the components of a transaction device.

FIGS. 4A-4D illustrate the functional components of trusted agents.

FIG. 5 is a diagram showing the network structure of a system for open electronic commerce.

FIG. 6A is a diagram showing the security hierarchy for the trusted agents.

FIG. 6B illustrates the functional components of a (primary) trusted server.

FIG. 7A illustrates a Commit protocol.

FIG. 7B illustrates an Abort protocol.

FIGS. 8A-8C illustrate a Recertify Trusted Agent protocol.

FIGS. 9A-9E illustrate an Establish Session protocol.

FIG. 10 illustrates a Send Message protocol.

FIG. 11 illustrates an Abort Transaction protocol.

FIGS. 12A-12B illustrates a Purchase of Electronic Merchandise protocol.

FIG. 13 shows the various message encryption layers established among trusted agents and money modules.

FIG. 14 illustrates a Check Credential protocol.

FIGS. 15A-15B illustrate a Deliver Merchandise protocol.

FIGS. 16A-16E illustrate a Money Module Payment protocol.

FIG. 17 illustrates a Send Routed Message protocol.

FIG. 18 illustrates a Send MM/TA Message protocol.

FIG. 19 illustrates a Send TA/MM Message protocol.

FIG. 20 illustrates a Send E-Routed Message protocol.

FIGS. 21A-21B illustrate an Authorization-Based Payment/Refund protocol.

FIG. 22 illustrates an Open Merchandise protocol.

FIGS. 23A-23D illustrate a Present Electronic Ticket for Services protocol.

FIG. 24 illustrates a Commit Ticket protocol.

FIGS. 25A-25C illustrate a Transfer Tickets protocol.

FIG. 26 illustrates an Acquire Credential protocol.

FIGS. 27A-27B illustrate a Deliver Credential protocol.

FIGS. 28A-28B illustrate a Revalidate Credential Remotely protocol.

FIGS. 29A-29B illustrate an Identity-Based Money Module Payment protocol.

FIGS. 30A-30E illustrate a Dispute Over Electronic Merchandise protocol.

FIG. 31 illustrates a Commit Dispute protocol.

FIG. 32 illustrates a Pay Dispute protocol.

FIG. 33A is a diagram showing the EMS Security Hierarchy.

FIG. 33B is a diagram showing the security network messaging between a primary security server and an ordinary security server.

FIG. 34 is a diagram showing the security network structure for the EMS.

FIG. 35A illustrates the functional components of a security server.

FIG. 35B illustrates the functional components of a network server.

FIG. 36 shows an overview of the network sign-on procedure.

FIGS. 37A-37K illustrate a Network Sign-On protocol.

FIGS. 38A-38E illustrate an Establish Session protocol in the EMS.

FIGS. 39A-39B illustrate a Transfer Notes protocol.

FIGS. 40A-40D illustrate a Foreign Exchange protocol.

FIG. 41 illustrates a Commit protocol for modules in the EMS.

FIGS. 42A-42B illustrate an Abort Transaction protocol for modules in the EMS.

FIGS. 43A-43C illustrates a Point of Sale (POS) Payment protocol.

FIGS. 44A-44B illustrate a Link Accounts protocol.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention contemplates a system for enabling the secure delivery of electronic merchandise with real-time anonymous payment or authorization-based payment. The system allows both the customer and merchant to feel secure that their interests are being served.

Referring to FIG. 1, there is shown the basic interaction between system components during an anonymous payment transaction. To achieve the secure exchange of payment for electronic merchandise when buyer and seller are transacting electronically, the present invention introduces trusted agents 2, 4 for both the customer and merchant. A trusted agent is a combination of hardware and software components. It is tamper-proof and contains secure protocols which cooperate with a money module 6 to synchronize secure payment to delivery.

The money modules contemplated herein are tamper-proof devices capable of storing and transferring electronic money. The electronic money is preferably in the form of electronic notes that are representations of currency or credit. Money modules are also capable of establishing cryptographically secure communication sessions with other devices. The preferred embodiment of the present invention utilizes the transaction money modules described in PCT patent application WO 93/10503, together with any modifications or improvements described hereafter.

Conceptually, a trusted agent is a surrogate actor for an entity who wants to transact remotely (electronically) in a secure way. The trusted agents are under control of transaction protocols and behave in a way calculated to resolve the transaction to the satisfaction of both parties. In order to guarantee the behavior of a trusted agent, the protocols are physically protected. Thus neither party can modify the protocols to the disadvantage of the other party.

The trusted agents exchange electronic merchandise and payment. As shown in FIG. 1, the merchant's trusted agent 4 (MTA) sends electronic merchandise to the customer's trusted agent 2 (CTA). In return, the customer's money module 6 sends electronic money to the merchant's money module 6 via CTA 2 and MTA 4.

Tickets

Electronic merchandise is any goods that can be represented in electronic form, and in the preferred embodiment described herein consists of either a ticket or an encrypted electronic object (EO) and its associated decryption ticket. Referring to FIGS. 1 and 2, a ticket 8 is an electronic item created by a MTA 4 and transferred to a CTA 2 during a purchase transaction. Tickets may be thought of as the property of the trusted agents. A customer whose CTA 2 has just received a ticket 8 may only use that ticket upon successful completion of the transaction.

The present invention supports a variety of ticket types used for various purposes:

1. A decryption ticket is always associated with a particular encrypted electronic object. Examples of electronic objects are computer software, games, movies, or information products like electronic newspapers and books. In this case, the merchant's goods are the electronic objects, which are encrypted by a MTA prior to being delivered to a customer. An encrypted electronic object can be decrypted by unique information in its associated decryption ticket. Together, the encrypted electronic object and its decryption ticket comprise the electronic merchandise transferred by the merchant.

The transferred electronic object is cryptographically secure from inspection and use by the receiving customer or any other third party unless they have access to the decryption ticket. The decryption ticket, in turn, is the "property" of the CTA and may only be used upon successful completion of the purchase transaction.

2. A credential ticket identifies the "owner" and permits specific privileges. Examples of credentials include a driver's license, passport, credit card, debit card, social security card, and corporate seal.

3. A transportation ticket can serve as an airline, rail or bus ticket in electronic form.

4. An event ticket can provide access to various events such as a theater, concert, play, or sporting event.

5. A communications ticket can provide access to various communications services including satellite, cable, radio, cellular telephone and Plain Old Telephone Service (POTS). For example, a communications ticket may be used to unscramble TV or radio broadcasts.

6. A physical object ticket can serve as purchase order, invoice, payment advice, receipt, or title for physical objects.

Other types of ticket are, of course, possible and may be desirable in implementing open electronic commerce in accordance with the present invention.

A trusted agent can not only purchase tickets but can also present them to other trusted agents for a variety of purposes. For example, event tickets can be electronically presented for entry into an arena. Once the ticket holder is inside, the ticket can again be presented electronically for automated directions to his/her seat. A driver's license in ticket form can be presented as proof of identity. A ticket can be presented as proof of purchase of non-electronic goods and exchanged for a physical object, either delivered to the customer or picked up by the customer at a store or warehouse. A credit or debit card ticket can be presented for authorization-based payment. In a purchase dispute, a ticket may be presented as proof of purchase of defective merchandise.

FIG. 2 shows a preferred embodiment of a ticket 8 in which the ticket is comprised of six major sections: Identifier 10, Components 12, Issuer Signature 14, Issuer Certificate 16, Transfer History 18 and Sender Signatures 20. The sections, in turn, are comprised of various information containing fields.

The Identifier section 10 has a field 22 which holds information that identifies the merchant or authority creating the ticket. Such information, for example the merchant's or authority's name, is copied from a merchant or authority credential held by the ticket issuer. The field 22 also contains the expiration date of the merchant or authority credential. A field 24 contains the receiving trusted agent's identification number. The field 24 also contains the expiration date of the ticket receiver's trusted agent credential. A field 26 designates the ticket type (e.g., decryption ticket, event ticket, etc.).

The Components section 12 contains the basic ticket content which varies depending upon the ticket type and its specific purpose. FIG. 2 shows examples of components found in different ticket types.

The Component section 12 of a decryption ticket has an Object Identifier field 36 which uniquely identifies a particular electronic object and may also contain a short description of the electronic object (e.g., title and author). Electronic objects themselves (e.g., movies) are comprised of a header and a body. The header contains an object identifier which ties to the object identifier 36 in the decryption ticket. The header also contains descriptive information which could be presented to the buyer for preview of the object content. The body is the content which the purchaser can interact with, peruse, or watch.

A Decryption Key field 38 contains the information used to decrypt the ticket's associated electronic object. A Purchase Price field 40 has the electronic object's price information. A Date of Purchase field 42 has the date on which the electronic object was purchased. An object Signature field 44 contains a digital signature of the electronic object. Digital signatures are well known in the art and are used to detect if a signed electronic object has been altered in any way since the time it was signed. Thus, electronic object integrity may be checked. A Usage field 46 specifies restrictions on usage of the electronic object.

A credential ticket such as a driver's license may have: a Name field 48; an Address field 50; a Picture and Physical Description field 52; a Signature of Driver field 54 holding an electronic image of the driver's signature; an Expiration Date field 56; a Status field 58 indicating if the license is valid, suspended, or revoked; and an In Use field 60 indicating when a copy of the ticket has been presented to a MTA 4 for use, so that the original ticket held by the CTA 2 cannot be reused during the presentation period. A credential ticket such as a corporate seal may have: a Corporate Name field 62; an Address field 64; a Taxpayer ID field 66; an Expiration Date field 68; and an In Use field 70.

A transportation ticket may have: a Carrier Name field 72; a Trip Number field 74 specifying for example a flight, train or bus number; Departure and Arrival fields 76, 78 each specifying a time and location; a Purchase Price field 80; a Date of Purchase field 82; a Status field 84 indicating whether the ticket is unused or has already been used; and an In Use field 86.

An event ticket may have: an Event Identity field 88; a Location field 90; a Date field 92; a Seat Number field 94, a Purchase Price field 96, a Date of Purchase field 98; a Status field 100; and an In Use field 102.

A communications ticket may have: a Carrier Identity field 104; a Time Purchased field 106; a Channel/Frequency field 108; a Purchase Price field 110; a Date of Purchase field 112; a Decryption Keys field 114 for decrypting if the communication is encrypted; a Time Available field 116 indicating the remaining value of the ticket; and an In Use field 118.

A physical object ticket (not shown) may serve as a purchase order and contain the following information: reference number, date, customer identifier, list of items to purchase, instructions, and status (on order, invoiced, etc.). A physical object ticket may also serve as an invoice and contain: invoice number, date, PO reference numbers, vendor identifier, and amount. Similarly, a remittance advice would contain: invoice reference numbers, customer identifier, date, and amount paid. A receipt would contain: date, vendor, identifier, list of items or invoice reference numbers, and amount paid.

Trusted agents may be used for retail purchasing of physical objects either in person or remotely. If purchasing in person with the trusted agent, the entire transaction can be accomplished at electronic speeds with no paper for both anonymous and identity-based transactions. For the merchant, this means he can reduce the cost of the customer payment. For the customer, it means more convenience and control, since the transaction time has been reduced and the agent has an electronic list of purchases which can be easily analyzed at a later time.

When purchasing physical objects remotely over the phone or over interactive TV, a nagging restriction for the merchant and customer is that merchandise has to be shipped to the customer's address. This is to secure the merchant from fraud. Payment is usually provided using a credit card or the customer is billed, disclosing the customer's identity.

If the purchase was made using a trusted agent, then the merchandise would not have to be delivered to the customer's address, and the customer would not have to disclose his identity. Anonymity can be accomplished if the customer pays with electronic money at the time of order or receipt of the merchandise. The restriction on delivery location can be lifted in either case. The merchant can be secured from fraud because he/she will get paid before or at the time the goods are delivered. Moreover, the receiver is validated at the time the merchandise is delivered. The customer can feel secure because it will be difficult for a third party to defraud him/her, since they have a secure receipt. Also, the transaction can be disputed using the secure receipt if the merchandise is faulty. At the end of the transaction, both the customer's trusted agent 2 and the merchant's trusted agent 4 will have recorded that the ordered merchandise was paid for and delivered to the correct party.

For commercial transactions, trusted agents provide secure, authenticated, automated transactions and records from order to payment. Vendors can be efficiently paid upon delivery of goods, and customers can have authenticated receipts without the hassle of paperwork. All ancillary systems such as accounts payable, accounts receivable, purchase order, and invoicing can be integrated with trusted agents to provide a seamless, secure system for procurement.

The Issuer Signature section 14 of a ticket 8 holds a digital signature, formed by the ticket creator, over the Identifier and Components sections 10, 12. Such signature is made using a private key belonging to the issuer's trusted agent. The Issuer Certificate section 16 contains a certification by a trusted third party (hereinafter referred to as the "Trusted Agency") used in conjunction with the issuer signature to verify the authenticity of the issued ticket 8. Such certification is in the form of a certificate belonging to the issuer's trusted agent. The general use of certificates and digital signatures is known and described, for example, in D. W. Davies and W. L. Price, Security For Computer Networks (John Wiley & Sons, 1984).

The Transfer History section 18 contains information generated when tickets are transferred between trusted agents after the initial issuing of the ticket 8 by a merchant or authority. A Receiver ID's field 28 contains the receiving trusted agent's identification number. A Sender ID's field 30 contains the sending trusted agent's identification number. A Sender Certs field 32 contains the sending trusted agent's certificate. A Date/Times field 34 contains the date and time of transfer of the ticket 8. As subsequent transfers are made, additional receiver and sender ID's, sender certificates, and dates and times are appended to each field, thus creating a list of transfer history information. It may be noted that the trusted agent ID found in the Receiver field of the Identifier section, should be the same as the first ID in the Sender ID's field.

In addition, whenever a ticket 8 is transferred between trusted agents, the sender digitally signs the ticket over the five preceding ticket sections using a private key belonging to the sender's trusted agent. The Sender Signatures section 20 is then updated by appending the newly created digital signature, thus forming a list of sender signatures.

Transaction Devices

Referring to FIG. 3, a trusted agent 120 is embedded in a transaction device 122. The transaction device 122 is composed of three major components for both the merchant and the customer. There is a host processor 124, a trusted agent 120, and a money module 6. These components are connected, for example, by a bus 126. When trusted agent 120 is a MTA 2, the device 122 is referred to as a merchant transaction device (MTD). When trusted agent 120 is a CTA 4, the device 122 is referred to as a customer transaction device (CTD).

FIG. 3 shows the functional components of the host processor 124. The host processor provides the following functions: Communications 128, Transaction Applications 130, Human/Machine Interface 132, Date/Time 136, and a Message Manager 134.

The Communications function 128 supports communications between the transaction device 122 and the outside world. Such communications may be wired or wireless, broad or narrow band, so long as CTD 2 and MTD 4 communications are compatible. The Communications function 128 sets up the connection between two transaction devices 122, or connects a transaction device to a network for indirect connection to another transaction device or a trusted server.

Transaction Applications 130 may perform a variety of tasks. For example, a transaction application may perform the shopping task by interfacing to a merchant server's catalogue services for browsing activities, choosing the products, and initiating payment and delivery. Another transaction application may provide for the interim storage of electronic objects and possibly execute objects. In order to execute an electronic object, there may be additional object processors depending on the type of electronic object (e.g., movie, book, multimedia game, etc.). In short, a transaction device 122 contains all the processes to choose, buy and possibly use electronic objects, credentials, and other tickets 8, or the processes to sell the same.

The Human/Machine Interface function 132 provides the look and feel of the transaction device 122. It could include a keyboard, mouse, pen, voice, touch screen, icons, menus, etc. The Human/Machine Interface 132 communicates with other functions in the trusted agent 120 and the money module 6 through the message manager 134. In some applications a Human/Machine Interface 132 may not be necessary, for example, in a fully automated merchant transaction device.

The Date/Time function 136 is set by the owner of the transaction device 122 and includes date, time and time zone. The Date/Time information is fed to the embedded trusted agent 120 whenever the trusted agent is opened for use.

The Message Manager 134 routes inter-host messages (i.e., messages between transaction devices) and messages among the host processor 124, the trusted agent 120 and the money module 6.

Trusted Agents

FIG. 4A shows the functional components of a trusted agent 120. The contemplated system for open electronic commerce uses three types of trusted agent 120 which differ in certain unique Transactor functions 146 that they provide. FIG. 4B shows the transactor functions found in a CTA 2. FIG. 4C shows the transactor functions found in a MTA 4. FIG. 4D shows the transactor functions found in an Authority Trusted Agent (ATA) which, in turn, is embedded in an Authority Transaction Device (ATD). ATDs are associated with credential issuing authorities such as the Department of Motor Vehicles.

An External Interface function 138 provides physical communication with the host processor 124 and the money module 6 of the transaction device 122 in which the trusted agent 120 is embedded. A Message Interface function 140 processes and routes inter-agent and intra-agent messages. A Session Manager function 142 sets up and breaks down inter-agent sessions and agent to trusted server sessions. A Security Manager function 144 maintains security information (e.g., a trusted agent certificate and an untrusted agent list) and establishes secure communication with a counterparty trusted agent (via the host processor 124) and with the local money module 6 within the same transaction device 122. The Transactor function 146 provides the protocols to perform a transaction. Customer, merchant and authority transactors are used for CTAs, MTAs and ATAs, respectively.

FIG. 4B shows the customer transactor functions. A Purchase function 158 exchanges payment for tickets 8 and electronic objects. A To Host function 160 provides an interface to the transaction device's host processor 124. A Present Ticket function 164 presents tickets 8 to obtain information or services. An Acquire Credential function 166 interacts to receive a credential ticket. A Tran Log function 162 maintains a log of trusted agent transactions. Both CTAs 2 and MTAs 4 maintain a transaction log which stores the following information: transaction type (e.g., ticket type); a pre-transaction ticket image; a post-transaction ticket image; dispute information including the date of dispute (as maintained by each trusted agent in the dispute dialog), status, and merchant resolution (e.g., replace, refund, denied); and recertifying information (e.g., date of recertification). An Initiate Dispute function 168 presents electronic merchandise if a customer is dissatisfied.

FIG. 4C shows the merchant transactor functions. A Purchase function 170 exchanges tickets 8 and electronic objects for payment. A To Host function 172 provides an interface to the transaction device's host processor 124. A Receive Ticket function 176 processes a received ticket 8 to provide service or information. An Acquire Credential function 177 obtains a merchant credential. A Tran Log function 174 maintains a log of trusted agent transactions. A Resolve Dispute function 178 receives tickets 8 and electronic objects to resolve a customer complaint.

FIG. 4D shows the authority transactor functions. A Create Credential function 180 constructs and delivers credential tickets to a requestor. A To Host function 182 provides an interface to the transaction device's host processor 124. A Receive Ticket function 184 processes a received ticket 8 to provide service or information. A Revalidate Credential function 186 accepts a current credential and reissues the credential with a new expiration date. A Tran Log function 183 maintains a log of transactions. An Acquire Credential function 185 obtains an authority credential.

Referring again to FIG. 4A, a To Money Module function 150 communicates with the money module 6 in the same transaction device 122 to provide payment. A Cryptography function 152 provides public key and symmetric key cryptographic functions. Any well known public and symmetric key cryptography techniques may be used, for example, RSA and DES. A Ticket Holder function 148 creates tickets 8 in a MTA 4 or stores and retrieves tickets 8 in a CTA 2. A Random Number Generator function 156 generates random numbers to produce cryptographic keys. A Date/Time function 154 manages the date and time delivered from the host processor 124 to date tickets 8 and validate certificates and presented tickets. Current clock information is fed to the trusted agent 120 every time the trusted agent is opened (i.e., signed on for use) and maintained until the trusted agent is closed.

System Overview

FIG. 5 shows the general network architecture of the contemplated system for open electronic commerce. Customer transaction device 188 can communicate with a merchant through any gateway network 190 without revealing the owner. Thus, customers can travel the networks anonymously, paying each in real-time for access. They can search out merchants' electronic space and enter it anonymously, select the item for purchase, and deliver payment in real-time. The system also provides for secure authorization-based payment via credit or debit card. This is accomplished by the customer presenting credit or debit card information stored within the trusted agent 120 as a credential.

In the preferred embodiment, the gateways 190 provide CTDs 188 with access to local merchant networks 134 for commerce and local identification authority networks 192 for acquiring and revalidating credentials (e.g., driver's licenses, credit cards, etc.) Merchant networks 192 may consist of merchant servers 194 that provide a merchandise catalogue, merchant transactor devices 198 to deliver goods for payment, and merchandise servers 196 which constitute an electronic warehouse. Merchant networks 192 also preferably have trusted servers 200 for distributing security information.

Identification authority networks 202 may have authority servers 204 which manage a database of credentials and an authority transaction device 206 which issues and revalidates credentials. Examples of identification authorities connected to networks 202 are foreign offices, departments of motor vehicles, banks, and the Social Security Administration. Identification authority networks 202 also have trusted servers 200 for distributing security information.

System Security

With reference to FIG. 5, security for the open electronic commerce system is provided by a network of trusted servers 200 situated at a Trusted Agency Network 208, at merchant networks 192, and at identification authority networks 202. The trusted servers 200 are tamper-proof processors that perform four primary functions: certification of trusted agents 120, distribution of untrusted lists, distribution of primary trusted server public key lists, and resolution of customer/merchant disputes.

FIG. 6A shows the system security hierarchy. At the top of the hierarchy, and located at the Trusted Agency Network 208, are primary trusted servers 210 which certify and provide trusted server certificates (cert(TS)) to all the trusted servers 200 in the system.

Each primary trusted server 210 has its own public key and corresponding private key. The primary trusted server public keys are commonly shared by all trusted servers 200 and trusted agents 120 in the system. These public keys are stored in a primary trusted server public key (PTS(PK)) list. The term "public" key as used here and throughout the specification, does not imply that the key is known to the public at large. In this case, for example, the public key is known only to all trusted servers 200 and trusted agents 120 and is sealed within their tamper-proof housings. This limited sense of "public" provides added security to the system as a whole.

Beneath the primary trusted server 210 on the security hierarchy are the trusted servers 200 which may be located throughout the overall commerce system. The trusted servers 200 provide trusted agent certificates (cert(TA)) to the trusted agents 120 (i.e., CTAs 2, MTAs 4, and ATAs 212).

The Trusted Agency guarantees the protocols and physical protection of each trusted agent 120 in the system. Trusted agents 120 are manufactured in a physically secure environment under control of the Trusted Agency. The components are fabricated, assembled, and loaded with software in this environment. The trusted agents 120 are then tamper-proofed and can only be communicated with through their external interface.

At initialization, each trusted agent 120 is placed in communication with a trusted server 200. The trusted server 200 assigns each trusted agent 120 a unique identification number TA(id). Then the trusted server 200 requests the trusted agent 120 to generate a public and private key pair. The trusted agent 120 generates the key pair and passes its public key (TA(PK)) to the requesting trusted server 200. The trusted server 200 incorporates this information and the TA(id) into a trusted agent certificate cert(TA) and passes it back to the trusted agent 120 along with a PTS(PK) list, and an untrusted list. Finally, the trusted agent 120 tests its newly received certificate and makes sure the certificate is valid.

These initialization steps are performed only once, prior to distribution of the trusted agent 120 to the public. Upon purchase, a trusted agent 120 is personalized by its owner via biometrics or secrets (e.g., a personal identification number (PIN) is chosen).

In a similar fashion, a trusted server 200 is initialized by a primary trusted server 210. Upon conclusion of trusted server initialization, each trusted server 200 holds a trusted server certificate (cert(TS)) containing a unique trusted server identification number (TS(id)) and a trusted server public key (TS(PK)). The trusted server 200 also holds the private key corresponding to its public key TS(PK), a PTS(PK) list, and an untrusted list.

A cert(TS) is encrypted by a primary trusted server 210 and carries a unique identification number (PTS(id)) for that primary trusted server 210 in the clear. A cert(TA) is encrypted by a trusted server 200 and carries that trusted server's certificate (cert(TS)) for validation.

The structures of the cert(TS) and the cert(TA) are as follows:

    ______________________________________
     ##STR1##
     ##STR2##
    Where
    PTS = Primary Trusted Server
                         PK = Public Key
    TS = Trusted Server  .sigma. = digital signature
    TA = Trusted Agent   Cert = Certificate
    .parallel. = Concatenate
                         E = Algorithm with
    id = identification number
                         private key used for
                         encrypting and for
                         creating digital
                         signature
    ______________________________________

    ______________________________________
    Where PSS = Primary Security Server
                            PK = Public Key (includes
          SS = Security Server
                            length of key)
          M = Module        .sigma. = Digital Signature = E .degree. h
          .parallel. = Concatenate
                            Cert = Certificate
          id = identification number
                            E = Algorithm with
          h = Hash function private key used for
          C = Constant random number
                            encrypting and for
          shared by all modules
                            creating digital
                            signature
                            D = Algorithm with public
                            key used for decryption
                            and for checking
                            digital signature
    ______________________________________