System and apparatus for monitoring secure information in a computer network

A secure transaction system apparatus and method provide for the auditing of secure messages in a computer network. The secure transaction system includes an electronic commerce service which is in communication with multiple consumer computers and multiple merchant computers. The consumer computers initiate consumer transactions between the consumer computers and the merchant computers. Each consumer transaction can include different items, different merchants, different shipping methods and different payment instructions. An order object within the consumer computer stores summaries about the different items, the different merchants, the different shipping methods and different payment instructions during creation of each commercial transaction. While generating transaction data, the consumer computer also generates related audit data. The consumer computers encrypt the transaction data and the audit data into different encryption formats and send the encrypted transaction data and the encrypted audit data to the electronic commerce service. The electronic commerce service decrypts the audit data and stores copies of the encrypted transaction data. The electronic commerce service also routes the encrypted transaction data to the merchant computers. The merchant computers decrypt the encrypted transaction data and complete the desired commercial transaction. Thus, the electronic commerce service can audit secure transactions while maintaining confidentiality.

BACKGROUND OF THE INVENTION 
1. Field of the Invention 
This invention relates to computer network communication systems and, more 
particularly, to a system for monitoring secure commercial transactions in 
a computer network. 
2. Background 
Electronic commerce is currently expanding at a rapid rate. With the 
proliferation of low-cost electronic communication techniques, consumers, 
purchasing agents, merchants, suppliers, manufacturers, credit companies, 
banks and other institutions continue to expand their use of electronic 
commercial transaction technology. Wide scale use of commercial 
transactions, however, require wide scale accessibility. 
In order to cost-effectively provide wide scale accessibility, commercial 
transaction systems must not only operate with private communication 
networks, but also operate with general purpose publicly accessible 
networks such as the internet or publicly accessible network service 
providers. Because publicly accessible networks have much larger numbers 
of users, they often provide lower transmission costs than private 
communication networks. Unfortunately, eavesdroppers and other 
intermediaries have regular and easy access to electronic messages 
transported on publicly accessible networks. 
As a result, publicly accessible networks are not secure. Accordingly, 
methods have been developed to create electronic documents which are 
private and secure from unauthorized use. In conventional systems, an 
electronic document is usually converted into a secret form before 
transmission over the publicly accessible network. The process of 
converting information into a secret form is called "encryption" and a 
converted document is called an "encrypted" document. 
When the encrypted document arrives at its destination, the encrypted 
document is converted back to its original form. The process of converting 
an encrypted document into readable form is called "decryption" and the 
readable document is called a "decrypted" document. A basic introduction 
to encryption and decryption is described in the text written by Bruce 
Schneier entitled "Applied Cryptography: Protocols, Algorithms And Source 
Code In C," published by John Wiley & Sons, 1994, which is hereby 
incorporated herein by reference. 
Typically, secure documents rely on what are called "keys" to encrypt and 
decrypt secure documents in a particular manner. In encryption, the key is 
a word, number or encryption format which "locks" the document from 
unauthorized viewing. In decryption, a matching key is then used to 
"unlock" or translate the encrypted document back into readable form. 
Thus, an encryption key is analogous to a mechanical key which locks a 
door while the decryption key is analogous to a mechanical key which 
unlocks a door. 
One technique called "public key/private key" encryption uses two different 
keys. The first key is called a public key and it is used to encrypt a 
document. The second key is called a private key and it is used to decrypt 
the encrypted document. This is analogous to a door lock with two keys, 
anyone who owns the public key can lock the door, but only the person who 
owns the private key can unlock the door. In conventional systems, the 
public key is publicly disseminated while the private key is kept private. 
For example, assume that a computer user named Aaron wishes to receive 
encrypted information. Aaron first directs his computer to create a public 
key and a private key pair. Aaron then keeps his private key private while 
freely distributing his public key to other computer users. If another 
computer user named Barry wishes to send a document to Aaron, Barry 
directs his computer to encrypt the document with Aaron's public key and 
also directs his computer to send the encrypted document to Aaron. When 
Aaron's computer receives the encrypted document, it decrypts the 
encrypted document with Aaron's private key. Thus, while Barry and other 
computer users can send encrypted documents to Aaron, only Aaron can 
decrypt and read the document. 
Besides providing security, current systems also use encryption techniques 
to authenticate or "digitally sign" a document. While digital signatures 
authenticate documents, digital signatures differ significantly from hand 
written signatures in that a digital signature "signs" a document by 
encrypting a portion of the document in a unique manner. 
For example, if a computer user named Carl wishes to digitally sign an 
electronic document, Carl first directs his computer to create a public 
key private key pair. Carl's computer then digitally signs the electronic 
document by encrypting a portion of the document with Carl's private key. 
Carl can then direct his computer to send the document and Carl's public 
key to another computer user. In this example, the other computer user is 
named Doug. When Doug receives the electronic document and Carl's public 
key, Doug can direct his computer to verify Carl's digital signature by 
comparing the digitally signed portion of the document with Carl's public 
key to see if a predefined mathematical relationship exists. If so, the 
digital signature is authenticated. Because only Carl can properly encrypt 
the digital signature with his private key, other computer users cannot 
fraudulently sign the document. 
Finally, the security techniques and digital signature techniques can be 
combined to create secure documents which contain digital signatures. For 
example, assume that two computer users named Eric and Frank wish to 
transmit digitally-signed secure documents. In this example, both Eric and 
Frank create public key/private key pairs. If Frank wishes to receive 
secure documents he sends his public key to Eric. Eric then directs his 
computer to generate an electronic document and digitally signs a portion 
of the electronic document with Eric's private key. Next, Eric directs his 
computer to encrypt the digitally-signed electronic document with Frank's 
public key. Eric then sends the encrypted, digitally-signed document and 
Eric's public key to Frank. 
When Frank's computer receives the encrypted, digitally-signed document, it 
decrypts digitally-signed document with Frank's private key. Because only 
Frank's computer can decrypt the digitally-signed document, the document 
is secure. Frank can then verify Eric's digital signature by directing his 
computer to compare the encrypted digital signature to Eric's public key 
to see if a predefined mathematical relationship exists. If so, the 
digital signature is said to be authentic. 
Such techniques are widely seen as an essential means for securing the 
privacy of consumers, and for authenticating the identity of consumers who 
exchange information on publicly accessible networks. These techniques, 
however, create a variety of maintenance problems for network service 
providers. For example, a network service provider needs information to 
route a secure document to its proper destination. In addition, a network 
service provider often desires to obtain audit information from the secure 
transmissions in order to properly bill transaction fees. Still further, 
in the event of a system crash or power outage, a network service provider 
needs an efficient means for locating secure documents which have been 
stored in a backup system. 
Thus, while computer users wish to retain the privacy and the integrity of 
secure documents, providers of publicly accessible networks need the 
capability of monitoring the transmittal of secure documents to ensure 
proper routing, proper billing and the proper retrieval of secure 
documents from backup facilities. Consequently, current encryption and 
decryption techniques are not optimally adapted for publicly accessible 
networks. Accordingly, network providers need a cost-effective, flexible 
and secure system which can both provide secure audit information while 
maintaining the confidentiality of a secure document. 
SUMMARY OF THE INVENTION 
The present invention provides a secured transaction system which is 
configured to audit, store and properly route secure transactions while 
maintaining the confidentiality of the transaction. Confidentiality is 
maintained by encrypting different portions of a commercial transaction 
into different encryption formats. 
In the preferred embodiment, the secured transaction system independently 
encrypts (1) goods and service information, (2) payment instructions, and 
(3) audit information into different encryption formats. For example, in 
one embodiment of the present invention, only particular merchants can 
access the goods and service information, while only a network service 
provider can access the audit information. Advantageously, the secure 
system of the present invention preserves transaction confidentiality 
while allowing low-cost, easily accessible networks to provide routing, 
backup and auditing services. 
In a preferred embodiment of the secure transaction system, multiple 
consumer computers, an electronic commerce service and multiple merchant 
computers communicate with each other by sending secure messages over a 
publicly accessible network. A consumer computer displays goods and 
services offered by electronic catalogs, advertisements, sales brochures, 
electronic malls, etc. When an end-user selects an item for purchase, the 
consumer computer sends a secure electronic message to a network service 
provider. Preferably, the secure electronic message contains one or more 
transaction packets and an audit packet. The transaction packets and audit 
packets are encrypted into different encryption formats. 
The consumer computer in the secured transaction system comprises several 
component modules. In the preferred embodiment, the consumer computer 
contains a consumer application module, an order manager module, a secured 
technology module and an electronic mail module. Typically, the component 
modules are loaded onto the consumer computer by and end-user. In other 
embodiments, the component modules can be downloaded directly from the 
publicly accessible network. 
For example, an end-user may receive the component modules on a computer 
readable storage medium such as a compact disk or floppy disk. The 
end-user then directs the consumer computer to access the computer 
readable storage medium and execute the component modules. In other 
embodiments, the consumer component modules may be included in the 
computer computer's operating system. In still other embodiments, the 
component modules may be stored on a computer accessible storage media 
connected to the publicly accessible network. In such cases, the end-user 
directs the consumer computer to access the offerings in the publicly 
accessible network and download the component modules directly to the 
consumer computer. 
The consumer application module is the user interface which appears on an 
end-user's computer and displays items and services offered for sale. In 
the preferred embodiment, it is an electronic catalog which is installed 
in the consumer computer. In other embodiments, the consumer application 
may be a client/server application or an on-line offering such as an 
electronic mall. As discussed in more detail below, the consumer 
application communicates with the order manager module in the consumer 
computer. 
The order manager module of the preferred embodiment, creates the secure 
purchase order message. In particular, the order manager instantiates an 
order object which stores item information, shipping information and 
payment information. For example, if an end-user selects a watch while 
viewing the consumer application module, the order manager module obtains 
information about the watch, information about the merchant selling the 
watch, where to ship the watch, and how the end-user plans on paying for 
the watch. 
Upon obtaining information about a selected item, the order manager module 
creates a transaction packet for each item. Preferably, the transaction 
packet contains 1) a goods and services order and 2) payment instructions. 
The goods and services order contains information about the selected item 
and information about the merchant selling the item. The payment 
instructions contains credit account information. 
The order manager then directs the secured technology module to encrypt the 
goods and services order into a format which is only accessible by an 
authorized merchant. Furthermore, the order manager directs the secured 
technology module to encrypt the payment instructions into a format which 
is only accessible by an authorized payment entity such as a bank. As 
described in more detail below such authorized payment entities are 
typically called "acquirers." The order manager also combines the 
encrypted goods and services order and the encrypted payment instructions 
to create a transaction packet. 
The order manager also encrypts audit information which is related to the 
transaction. The audit information typically contains merchant 
identification data which identifies each merchant associated with a 
particular transaction packet. In addition, the audit information 
comprises the value of the transaction, the number of items purchased, 
etc. The order manager then directs the secured technology module to 
encrypt the audit packet into a format which is only accessible by an 
authorized network service provider. 
The order manager combines the encrypted transaction packet and the 
encrypted auditing packet to create a secure purchase order message. In 
the preferred embodiment, the secure purchase order message is then sent 
as a secure electronic mail message to the network service provider by the 
electronic mail module. 
Another feature of the present invention includes an electronic commerce 
service which executes in a publicly accessible network. In the preferred 
embodiment, the electronic commerce service contains several component 
modules. The component modules include a decryption module, a secured 
technology module, and a bindery module. In addition, the electronic 
commerce service contains an electronic commerce database. 
The bindery module registers transaction participants. In the preferred 
embodiment, the merchants register with the bindery module before they can 
receive secure transactions. Preferably, the merchants register their 
publicly accessible encryption keys with the electronic commerce service. 
The electronic commerce service authenticates the encryption keys and 
stores copies of the encryption keys in the electronic commerce database. 
In other embodiments, the consumers can, in a similar manner, also 
register their publicly accessible encryption keys with the electronic 
commerce service. 
Once the merchants have registered with the network service provider, the 
decryption module receives the secure purchase order messages and directs 
the secured technology module to decrypt the audit attachments. Thus the 
decryption module is similar to an auditor which audits each of the secure 
purchase order messages. The decryption module also stores the decrypted 
audit information and a copy of the encrypted transaction packet in the 
electronic commerce database. The storage of the encrypted transaction 
packets in the electronic commerce service allows the electronic commerce 
service to provide backup copies in the event of a system crash or power 
outage. 
In addition, the decryption module routes the encrypted transaction packet 
to the appropriate merchant computer based on the merchant identification 
data in the decrypted audit information. Advantageously, the decrypted 
audit information allows the electronic commerce service to route the 
encrypted transaction packet while maintaining confidentiality about the 
specific items and payment instructions. 
An additional feature of the present invention improves the efficiency of 
commercial transactions involving multiple merchants. In conventional 
systems, when an end-user selects items sold by multiple merchants, the 
consumer computer typically establishes a connection with each of the 
merchant computers. This increases connect times, delays response time and 
increases costs. Advantageously, in a preferred embodiment of the present 
invention, the secure purchase order message contains an encrypted 
transaction packet for each merchant. 
The electronic commerce service routes the encrypted transaction packets to 
the appropriate merchants. Thus, in the preferred embodiment, the consumer 
computer sends a single secured purchase order message to the electronic 
commerce service. As a result, connection times are reduced and network 
traffic decreases. 
In a further feature, the present invention includes a merchant computer 
that decrypts the encrypted transaction packets. In the preferred 
embodiment, the merchant computer contains several component modules which 
not only decrypt the goods and service order portion but also the payment 
instruction portion of the encrypted transaction packet. The component 
modules include an electronic mail module, a merchant module, an acquirer 
module and a secured technology module. 
In general, an acquirer is a credit company which services a credit 
account, credit card number, etc. An acquirer, however, can be any 
organization or institution which confirms that a purchaser has a credit 
account, which confirms that a purchases has sufficient funds to pay for a 
desired item, or which authorizes a credit purchase. For example, in one 
embodiment of the present invention, the acquirer may be a credit 
organization such as Visa, Mastercard, or American Express. 
In the preferred embodiment, the merchant and the acquirer are combined 
into the same entity and thus the merchant not only provides the purchased 
items, but also conducts the credit confirmation. Thus, in the preferred 
embodiment, a merchant computer contains both the merchant module and the 
acquirer module. 
Furthermore, in the preferred embodiment, the merchant component modules 
are stored on a computer readable storage medium such as a compact disk, 
hard disk or floppy disk. The merchant loads the merchant component 
modules into the processor of the merchant computer for execution. In 
other embodiments, the merchant component modules may be included in the 
computer computer's operating system. In still other embodiments, the 
merchant component modules may be stored on a computer accessible storage 
media connected to the publicly accessible network. In such cases, a 
merchant directs the merchant computer to access the offerings in the 
publicly accessible network and download the component modules directly to 
the merchant computer. 
Once loaded into the merchant computer, the electronic mail module receives 
the encrypted transaction packets, the merchant module directs the secured 
technology module to decrypt the goods and services order. The merchant 
module then sends the encrypted payment instructions to the acquirer 
module. The acquirer module then directs the secured technology module to 
decrypt the encrypted payment instructions and processes the payment 
instructions to ensure that the purchaser has sufficient funds to pay for 
the desired item. The acquirer module then sends a payment authorization 
response back to the merchant module. The payment authorization response 
either authorizes or denies the credit request. 
Once the merchant module receives the payment authorization response, the 
merchant module provides the goods or services requested by the end-user. 
For example, if the end-user has purchased a watch, the merchant module 
directs the merchant to ship the desired watch to the consumer computer. 
Upon completion of the purchase order, the merchant computer sends a 
receipt message back to the consumer computer.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
The detailed description which follows is organized into the following 
sections: Overview Of The Secure Electronic Commerce System, Architectural 
Overview Of An On-line System Appropriate For Use With The Secure 
Electronic Commerce System, Implementation Of The Secure Electronic 
Commerce System, Secure Data Formats, Registration, and Secured 
Transaction Processing. 
I. Overview Of The Secure Electronic Commerce System 
This section provides an overview of the secure electronic commerce system 
in a preferred embodiment of the present invention. A block diagram of a 
typical electronic transaction is shown in FIG. 1. Initially, a consumer 
operates a consumer computer 100 to select a desired good or service. The 
goods or services can be presented in an electronic catalog, 
advertisement, electronic mall or the like. After selecting the desired 
good or service, the consumer computer 100 generates a secure purchase 
order message 102 and sends the secure purchase order message 102 to an 
electronic commerce service 104 on a publicly accessible on-line network 
106. 
As discussed in more detail below, the secure purchase order message 102 
contains 1) a goods and service order, 2) payment instructions and 3) 
audit information. Preferably, the goods and services order specifies 
details about the purchased goods, the identity of the merchant selling 
the goods, shipping instructions, etc. The payment instructions preferably 
contain the cost of the goods, the purchaser's credit account, credit card 
number, etc. In addition, the audit information preferably specifies the 
identity of the merchant and contains other general information about the 
price and quantity of items purchased. 
The preferred embodiment encrypts the goods and service order, the payment 
instructions and the audit information into different encryption formats 
to ensure that only a desired merchant can access the goods and services 
order, only a desired credit provider can access the payment instructions 
and only a desired on-line network provider can access the audit 
information. The preferred embodiment combines the encrypted goods and 
services order and the encrypted payment instructions into one or more 
encrypted transaction packets (not shown) and stores the encrypted audit 
information in at least one encrypted audit packet (not shown). The 
encrypted transaction packets and the encrypted audit packet are then 
combined to create a secure purchase order message 102 which is sent to an 
electronic commerce service 104 executing in a publicly accessible on-line 
network 106. 
The on-line network 106 which receives the secure purchase order message 
102 provides the communication links between the parties participating in 
an electronic commercial transaction. As described in more detail below, 
the electronic commerce service 104 of the preferred embodiment executes 
within the on-line network 106. The electronic commerce service 104 
provides security registration, transfers secure transactions to their 
intended destinations and provides audit and backup services. 
Upon receiving the secure purchase order message 102, the electronic 
commerce service 104 decrypts the audit information in the secure purchase 
order message 102 and saves the audit information in an electronic 
commerce database. In addition, the electronic commerce service 104 makes 
a backup copy of the secure purchase order message 102. The electronic 
commerce service 104 then routes the secure purchase order message 102 to 
the specified merchant computer 108. 
Upon receiving the secure purchase order message 102 from the electronic 
commerce service 104, the merchant computer 108 decrypts the encrypted 
goods and services order. The merchant computer 108 also generates a 
payment authorization request 110 and sends it to the specified credit 
company's computer 112 (also called the acquirer computer 112) via the 
on-line network 106 or a variety of other communication networks. The 
payment authorization request 110 typically contains the encrypted payment 
instructions. 
The credit company associated with a credit account, credit card number, 
etc. is called an acquirer. An acquirer can be any organization or 
institution which confirms that a purchaser has a credit account, which 
confirms that a purchaser has sufficient funds to pay for a desired item, 
or which authorizes a credit purchase. In some embodiments, the acquirer 
can be a credit company, credit organization, card service or the like. 
For example, the acquirer may be a credit service such as Visa, 
Mastercard, or American Express. As discussed in more detail below, it is 
preferred that the merchant and the acquirer are combined into the same 
entity in the preferred embodiment. Thus, the same entity not only 
provides the purchased items, but also conducts the credit confirmation. 
The computer facility associated with the credit company is called the 
acquirer computer 112. Upon receiving the payment authorization request 
110, the acquirer computer 112 decrypts the encrypted payment instructions 
and uses known techniques to perform a credit confirmation. The acquirer 
computer 112 then sends a payment authorization response 114 back to the 
merchant computer 108. The payment authorization response 114 indicates 
whether sufficient funds exist to pay for the desired transaction. 
Once the merchant computer 108 receives the credit confirmation 122, the 
merchant computer 108 sends the receipt message 116 back to the consumer 
computer 100 via the on-line network 106. The receipt message 116 either 
denies or accepts the transaction specified in the secure purchase order 
message 102. 
In other embodiments, the acquirer computer 112 sends a credit request 120 
to an issuing bank computer 118. Generally, the issuing bank is the 
organization which issued the credit account. For example, the issuing 
bank may include Citibank, Wells Fargo, NationsBank and the like. 
Preferably, the issuing bank computer 118 is the issuing bank's computing 
facilities. The issuing bank computer 118 processes the credit request 120 
and determines whether sufficient funds are available to pay for the 
desired transaction. The issuing bank computer 118 then sends a credit 
confirmation 122 back to the acquirer computer 112. The issuing bank 
computer 118 then sends a bill 124 to the consumer computer 100 or 
physically prints the bill 124 and mails it to the consumer. 
II. Architectural Overview Of An On-line System Appropriate For Use With 
The Secure Electronic Commerce System 
This section provides an overview of the publicly accessible on-line 
network 106 in which the present invention is employed. The architecture 
of this network is further described in commonly-assigned copending U.S. 
application Ser. No. 08/472,807, having the title ARCHITECTURE FOR 
SCALABLE ON-LINE SERVICES NETWORK, filed Jun. 7, 1995 which is hereby 
incorporated herein by reference. 
FIG. 2 is a high level drawing illustrating the architecture of an on-line 
network 106 appropriate for use with the present invention. The on-line 
network 106 includes multiple consumer computers 100, multiple merchant 
computers 108, multiple acquirer computers 112 and multiple issuing bank 
computers 118 connected to a host data center 200 by one or more wide area 
networks (WANs) 202. The wide area network 202 of the preferred embodiment 
includes wide area network (WAN) lines 204 which are provided by one or 
more telecommunications providers. The wide area network 202 allows users 
of the consumer computers 100, the merchant computers 108, the acquirer 
computers 112 and the issuing bank computers 118 to access the host data 
center 200 via a modem. 
The host data center 200 comprises multiple gateway computers 206 connected 
to a high speed local area network (LAN) 208. Also connected to the local 
area network 208 are multiple application servers 210 which provide 
different services. The gateway computers 206 link incoming calls from the 
consumer computers 100, the merchant computers 108, the acquirer computers 
112 and the issuing bank computers 118 to the application servers 210. In 
the preferred embodiment, the application servers 210 and the gateway 
computers 206 are general purpose Pentium-class (or better) microcomputers 
which run the Windows NT operating system available from Microsoft 
Corporation. 
The application servers 210 typically have at least 128 megabytes of 
random-access memory (RAM) and at least 4 gigabytes of disk space. 
Processing power may vary from application server 210 to application 
server 210. For example, one application server 210 may have four 100 Mhz 
processors, while another application server 210 may have one 90 Mhz 
processor. Each gateway computer 206 typically has at least 64 megabytes 
of RAM and at least 2 gigabytes of disk space, and is capable of 
supporting approximately 1000 simultaneous end-users at T1 (1.544 Mbps) or 
greater data rates. The local area network 208 preferably operates at 100 
megabits per second based on the CDDI (Copper Distributed Data Interface) 
standard. The CDDI specification is a variant of the well-known ANSI Fiber 
Distributed Data Interface specification, but uses a single copper ring 
instead of a dual fiber ring. 
The host data center 200 provides a variety of communications-based and 
information-based services to end-users. A service is any service provided 
in an online environment. Typical services include, for example, an 
electronic commerce service 104, an electronic mail service 214 and other 
services not shown such as a chat service, a bulletin board service, a 
media view service, an interactive game service and various other 
information services. Preferably, the services in the on-line network 106 
are implemented as client-server applications, with server portions (or 
"server applications") running on the application servers 210, and with 
client portions (or "client applications") running on the consumer 
computers 100, the merchant computers 108, the acquirer computers 112 and 
the issuing bank computers 118. In the presently preferred embodiment, the 
client applications are implemented as Windows 95 executables and the 
server applications are implemented as dynamic link libraries which 
execute under the Microsoft Windows NT operating system. 
The application servers 210 associated with a particular service group is 
preferably a "replicated" version of other application servers 210 within 
the service, meaning that each runs the same service application as the 
others to implement a common service. For example, application servers 210 
within an electronic mail service group all run an electronic mail server 
application. A service group may have as few as one application server 
210. Further, a given application server 210 can handle multiple services, 
and can thus be simultaneously allocated to multiple services. This 
architecture advantageously features a high degree of scalability, 
allowing the capacity of the network to be scaled (without degrading the 
services) as the number of end users increases over time. 
During a typical logon session, the consumer computers 100, the merchant 
computers 108, the acquirer computers 112 and the issuing bank computers 
118 maintain a communications link with the gateway computers 206, but may 
access multiple services and thus communicate with multiple application 
servers 210. The gateway computers 206 translate messages between the 
protocol of the wide area network 202 and the protocol of the local area 
network 208 in order to establish connections among the application 
servers 210, the consumer computers 100, the merchant computers 108, the 
acquirer computers 112 and the issuing bank computers 118. 
As discussed in more detail below, the electronic commerce service 104 
establishes secure communication protocols and monitors secured 
transactions. The electronic mail service 214 receives secured 
transactions in the form of secure electronic mail messages. The 
electronic mail service 214 routes the secure electronic mail messages 
among the electronic commerce service 104, the consumer computers 100, the 
merchant computers 108, the acquirer computers 112 and the issuing bank 
computers 118. 
The host data center 200 also includes one or more custom gateway computers 
216 which link the host data center 200 to one or more external networks 
218, such as the Internet, other on-line service providers, or different 
private networks. The external networks 218 can also link additional 
consumer computers 100, merchant computers 108, acquirer computers 112 and 
issuing bank computers 118 to the host data center 200. Each custom 
gateway computer 216 uses the communications protocol required by the 
external network 218 to which the custom gateway computer 216 is linked. 
III. Implementation Of The Secure Electronic Commerce System 
The preferred embodiment of the present invention provides an enhanced 
system and method for processing secured commercial transactions on 
publicly accessible on-line networks 106. In general, an end-user directs 
one of the consumer computers 100 to initiate a commercial transaction 
such as the purchase of a good or service. The consumer computer 100 
generates the secure purchase order message 102 and converts the 
commercial transaction into a secured format. 
A. The Consumer Computers 
FIG. 3 illustrates a block diagram of the modular components existing in 
the consumer computers 100 in the preferred embodiment of the present 
invention. The modular components include a consumer application module 
300, an order manager module 302, a secured technology module 304 and an 
electronic mail module 306. In the preferred embodiment, a module is the 
set of software instructions, methods, interfaces, procedures, routines or 
the like which direct a computer processor to accomplish a desired 
function. In the preferred embodiment, the modules are stored in a 
computer accessible media or memory and are executed by the processor in 
the consumer computer 100. 
The consumer application module 300 (hereinafter referred to as the 
consumer application 300) executes on the consumer computer 100 and 
generates the user interface which appears on the consumer computer 100. 
In the preferred embodiment, the consumer application 300 is a Windows 95 
compatible program such as an electronic catalog, electronic 
advertisement, a page in an excel worksheet, a display page in a network 
browser or other programs which allow the user of the consumer computer 
100 to select desired goods and services. Once the user selects one or 
more desired items, the consumer application 300 sends item information, 
merchant identification information, acquirer identification information, 
and end-user identification information to the order manager module 302 
In the preferred embodiment, the order manager module 302 is a set of 
application programming interfaces implemented in a Win 95 32-bit dynamic 
link library and is hereinafter referred to as the order manager 302. As 
discussed in more detail below, the consumer application 300 "calls" the 
application programming interfaces in the order manager 302 to instantiate 
an order object (not shown) which contains purchase, payment, shipping and 
other information regarding a commercial transaction. An application 
programming interface "call" takes the form of a program instruction which 
identifies the name of the application programming interface and specifies 
one or more variables which pass data to the identified application 
programming interface. 
Using the application programming interfaces in the order manager 302, the 
consumer application 300 calls the order manager application programming 
interfaces to create and send the secure purchase order message 102 to the 
electronic commerce service 104 in the on-line network 106. Invoking the 
routines in an application programming interface typically take the form 
of a function call. Pertinent application programming interfaces in the 
order manager 302 include: the BeginOrder function 320, the CreateItem 
function 322, the CreateShipTo function 324, the CreatePayment function 
326, the CreateLineltem function 328 and the SubmitOrder function 330. 
In addition, the preferred embodiment provides an Object Linking and 
Embedding (OLE) server (not shown) which allows a wide variety of consumer 
applications 300 to access the order application programming interfaces in 
the order manager 302. For example, the OLE server allows 16-bit consumer 
applications 300 to invoke the 32-bit order manager 302 dynamic link 
libraries with OLE 16/32-bit interoperability. The OLE server and 
automation techniques are well known in the art and are further described 
in Microsoft Visual Basic Version 4.0 Professional Features, Microsoft 
Press, 1995, OLE 2 Programmer's Reference Vols. I and II, Microsoft Press, 
1993 and Brockschmidt, Inside OLE 2, Microsoft Press, 1994 which are 
herein incorporated by reference. 
An additional advantage of the OLE server is that the consumer applications 
300 can be implemented in a wide range of programming languages. For 
example, a consumer application 300 programmed in visual basic can 
instantiate the OLE server with the Visual Basic CreateObject routine. The 
visual basic techniques for communicating with the OLE server are also 
well known in the art and are further described in Microsoft Visual Basic 
Version 4.0, Programmer's Guide, Microsoft Press, 1995 which is wherein 
incorporated by reference. 
As explained in more detail below, the order manager 302 application 
programming interfaces communicate with the secured technology module 304 
to generate the secure purchase order message 102. The secured technology 
module 304 of the present invention can incorporate a wide variety of 
encryption techniques. In the preferred embodiment, the secured technology 
module 304 is the Secured Transaction Technology standard developed by 
Visa International and Microsoft Corporation. The Secured Transaction 
Technology standard, as described above, is known in the art and is 
described in "Secured Transaction Technology Open Specification/Wire 
Formats and Protocols, version 0.902," published by the Microsoft 
Corporation which is attached in the Appendix set forth below. Those of 
ordinary skill in the art, however, will recognize that a wide variety of 
encryption techniques can be employed in different embodiments of the 
present invention. 
The secured technology module 304 of the preferred embodiment uses one or 
more merchant public keys 308, one or more acquirer public keys 310 and an 
on-line network public key 312 to generate secure purchase order messages 
102. As explained in further detail below, during the registration 
process, each merchant computer 108 generates its own merchant public key 
308 and merchant private key (not shown), each acquirer computer 112 
generates its own acquirer public key 310 and acquirer private key (not 
shown). The on-line network public key 312 is predefined by the on-line 
network 106. 
As described in more detail below, the secured technology module 304 uses 
the merchant public keys 308, the acquirer public keys 310, the on-line 
network public key 312 to create the secure purchase order message 102. 
After generating a secure purchase order message 102, the order manager 
302 sends the secure purchase order message 102 to the electronic mail 
module 306. In other embodiments, the secured technology module 304 may 
also use a consumer public key and a consumer private key to generate 
secure purchase order messages 102. Accordingly, in other embodiments, the 
consumer computer 100 can generate its own consumer public key and 
consumer private key. 
The electronic mail module 306 uses techniques known to one of ordinary 
skill in the art to communicate with the electronic commerce service 104 
in the on-line network 106. Preferably, the electronic mail module 306 
communicates with the electronic commerce service 104 via a modem over the 
wide area network 202. A person of ordinary skill in the art, however, 
will appreciate that the electronic mail module 306 can be implemented 
using any number of different protocols and computer configurations 
without departing from the scope of the present invention. For example, 
the electronic mail module 306 could communicate with the electronic 
commerce service 104 or the external networks 218 via a cable modem, 
wireless modems, interactive television systems and the like. 
In the preferred embodiment, the electronic mail module 306 utilizes 
Microsoft's Messaging Application Program Interface (MAPI). The Messaging 
Application Program Interface (MAPI) provides functions such as the 
MapiDeleteMail function, the MapiReadMail function, and the MapiSendMail 
function for using Microsoft Mail within a Microsoft Windows application. 
By calling these functions in the appropriate manner and combination, an 
application can address, send, and receive electronic mail messages. MAPI 
is well known to those of ordinary skill in the art and is further 
discussed in the MAPI Software Development Kit which is available from 
Microsoft Corporation. 
B. The Host Data Center 
Referring now to FIG. 4, a block diagram of the electronic commerce service 
104 and the electronic mail service 214 in the host data center 200 is 
shown. In a preferred embodiment, the electronic commerce service 104 
contains multiple application servers 210 which are interconnected by the 
local area network 208, and are arranged into an electronic commerce 
service group. Each application server 210 of the electronic commerce 
service group is preferably a "replicated" version of the other 
application servers 210 within the electronic commerce service 104, 
meaning that each application server 210 runs the same electronic commerce 
software as the others to implement a common electronic commerce service 
104. 
Preferably, the electronic commerce service 104 comprises a decryption 
module 400, a bindery module 402, a secured technology module 304 and an 
electronic commerce database 404. In the preferred embodiment, the 
decryption module 400 audits the secure purchase order messages 102. 
Typically, the decryption module 400 receives the secure purchase order 
messages 102 and other electronic messages from the electronic mail 
service 214. As discussed in more detail below, the decryption module 400 
communicates with the secured technology module 304 to decrypt audit 
information 406 contained in the secure purchase order messages 102. In 
addition, the decryption module 400 routes the secure purchase order 
message 102 to the merchant computers 108 and the acquirer computers 112 
via the electronic mail service 214. 
The decryption module 400 stores the decrypted audit information 406 in the 
electronic commerce database 404. Preferably, the electronic commerce 
database 404 is implemented with Structured Query Language (SQL) code. The 
structured query language is a language standardized by the International 
Standards Organization (ISO) for defining, updating and querying 
relational databases. 
The bindery module 402 registers the merchant public keys 308 and the 
acquirer public keys 310 during the registration process. As discussed in 
more detail below, the bindery module 402 also uses the on-line network 
public key 312 to digitally sign the merchant public keys 308 and the 
acquirer public key 310. In the preferred embodiment, the digitally signed 
merchant public key 308 is called a merchant affidavit 410, the digitally 
signed acquirer public key 310 is called an acquirer affidavit 412. In 
other embodiments, a digitally signed consumer key is called a consumer 
affidavit. 
The bindery module 402 also stores a copy of the on-line network public key 
312, the on-line network private key 408, the merchant public keys 308, 
the merchant affidavits 410, the acquirer public keys 310, and the 
acquirer affidavits 412 in the electronic commerce database 404. In 
addition, the electronic commerce database 404 stores audit information 
406 about each commercial transaction and backup copies of each secure 
purchase order message 102. 
The electronic mail service 214 communicates with the electronic commerce 
service 104 via the high speed local area network 208 and routes 
electronic mail to the electronic commerce service 104, the consumer 
computers 100, the acquirer computers 112 and the issuing bank computers 
118 via the wide area network 202 or the external networks 218. The 
electronic mail service 214 of the preferred embodiment uses the Microsoft 
Messaging Application Program Interface (MAPI) which as discussed above, 
is known to one of ordinary skill in the art. 
C. The Merchant/Acquirer Computers 
Referring now to FIG. 5, the modular components existing in the preferred 
merchant computer 108 are shown. In the preferred embodiment, the merchant 
computer 108 and the acquirer computer 112 are combined into a single 
computer which is hereinafter referred to as the merchant computer 108. 
The modular components include: an electronic mail module 306, a merchant 
module 500, an acquirer module 502, a secured technology module 304. In 
addition, the modules access a merchant private key 504 and an acquirer 
private key 506. 
In the preferred embodiment, a module in the merchant computer 108 is the 
set of software instructions, methods, interfaces, procedures, routines or 
the like which direct a computer processor to accomplish a desired 
function. In the preferred embodiment, the modules are stored in a 
computer accessible media or memory and are executed by the processor in 
the merchant computer 108. In other embodiments, the merchant computer 108 
and the acquirer computer 112 may exist as separate entities. Accordingly, 
one of ordinary skill in the art will recognize that the merchant modules 
500 and the acquirer modules 502 can execute on separate merchant 
computers 108 and separate acquirer computers 112. 
In the preferred embodiment, the merchant module 500 and the acquirer 
module 502 are sets of application programming interfaces implemented in a 
Win 95 32-bit dynamic link library. The application programming interfaces 
in the merchant module 500 are configured to obtain the secure purchase 
order message 102 from the electronic mail module 306, to generate the 
payment authorization request 110 sent to the acquirer module 502, to 
process the payment authorization response 114 received from the acquirer 
module 502, and to generate the receipt message 116. 
As discussed in more detail below, the pertinent application programming 
interfaces in the merchant module 500 include: a GetOrder function 520, a 
CreateAuthRequest function 522, a ProcessAuthResponse function 524 and a 
CreateReceipt function 526. The preferred merchant computer 108 also 
contains an Object Linking and Embedding (OLE) server (not shown) which 
allows a wide variety of merchant applications (not shown) to access the 
application programming interfaces in the merchant module 500. 
The acquirer module 500 also contains application programming interfaces 
for obtaining and processing the payment authorization request 110 
generated by the merchant module 500. The application programming 
interfaces in the acquirer module 502 are configured to decrypt the 
payment instruction portion of the secure purchase order message 102, to 
perform a credit confirmation and to create the payment authorization 
response 114. As discussed in more detail below, the pertinent application 
programming interfaces in the merchant module 500 include: a 
ProcessAuthRequest function 530 and a CreateAuthResponse function 532. 
In other embodiments, the acquirer module 502 may generate the credit 
request 120 (not shown) which sends credit account information to the 
issuing bank computer 118. The issuing bank computer 118 then uses data 
processing techniques known to one of ordinary skill in the art to process 
the credit request 120 and to generate a credit confirmation 122. In 
addition, in other embodiments, the issuing bank computer 118 prepares a 
bill 124 or credit statement which is then sent electronically to the 
consumer computer 100 or which is sent manually printed and sent to the 
end-user of the consumer computer 100. 
IV. Secure Data Formats 
The data structure utilized by the preferred embodiment during the creation 
of the secure purchase order message 102 is shown in FIGS. 6A and 6B. As 
explained in more detail below, when an end-user initiates a commercial 
transaction, the order manager 302 instantiates an order object 600. The 
instantiation of the order object 600 includes the creation of the order 
object 600 and the allocation of memory to hold the order object 600. 
Object instantiation is well known in the art and is further described in 
OLE 2 Programmer's Reference Vols. I and II, Microsoft Press, 1993, and 
Brockschmidt, Inside OLE 2 Microsoft Press, 1994. 
The unique structure of the order object 600 in the preferred embodiment, 
allows a secured purchase order message 102 to contain multiple items, 
multiple payment instructions, multiple shipping methods and multiple 
merchants. Thus the order object 600 behaves much like a relational 
database. The order object 600, however, is specifically is designed to 
optimize the storage of complex commercial transactions. 
In the preferred embodiment, the order object 600 stores item records 602, 
payment records 604, shipto records 606 and lineitem records 608. The item 
records 602 contain summaries about purchased items. The payment records 
604 contain payment summaries such as credit payment instructions, while 
the shipto records 606 contain shipping instructions which summarize how 
to ship particular items. 
Each lineitem record 608 is analogous to a sales order for a specific item. 
Thus, multiple lineitem records 608 are analogous to multiple sales 
records which contain shipping and purchase data about different items. In 
the preferred embodiment, each lineitem record 608 references one of the 
item records 602, one of the payment records 604 and one of the shipto 
records 606. For example, in the preferred embodiment, an end-user may 
view a consumer application 300 such as an electronic catalog which 
displays products offered by different manufacturers. While viewing the 
consumer application 300, the end-user may desire to purchase a particular 
jacket. As discussed in more detail below, when the end-user selects the 
jacket, the preferred embodiment creates an item record 602 containing 
information about the jacket and information about the merchant selling 
the jacket. 
In this example, the consumer application 300 prompts the end-user for his 
credit card information. Upon entering the credit card information, the 
preferred embodiment creates a first payment record 604 containing 
information about the end-user's credit card. In addition, the consumer 
application 300 prompts the end-user for a shipping address. If the 
end-user enters his home address, the preferred embodiment creates a first 
shipto record 606 containing information about the end-user's home 
address. Because the end-user wishes to purchase the jacket with his 
credit card, and have the jacket delivered to his home address, the 
preferred embodiment creates a first lineitem record 606 which references 
the first item record 602, the first payment record 604 and the first 
shipto record. 
While the end-user continues to view the electronic catalog, the end-user 
may also purchase another item. In this example, the end-user selects a 
necklace offered by a second manufacturer. In addition, the end-user 
desires to use a second credit card to purchase the necklace and desires 
to have the necklace delivered as a gift to a friend. Once the end-user 
selects the necklace, the preferred embodiment creates a second item 
record 602 containing information about the necklace and the second 
manufacturer. Once the end-user enters information about his second credit 
card, the preferred embodiment creates a second payment record 604. 
Furthermore, once the end-user enters the address of the end-user's 
friend, the preferred embodiment creates a second shipto record 606 
containing the friend's address. 
After the end-user enters all the necessary information, the preferred 
embodiment creates a second lineitem record 608 which references the 
second item record 602, the second payment record 604 and the second 
shipto record 606. Thus, with the unique order object 600 of the present 
invention, a single order object 600 can contain multiple lineitem records 
608, each of which specify different items, different merchants, different 
credit cards and different shipping instructions. 
Furthermore, multiple lineitem records 608 can reference the same item 
records 602, payment records 604 or shipto records 606. For example, if 
the end-user of the above example purchases earrings for his friend from a 
third manufacturer, the preferred embodiment creates a third item record 
602 for storing information about the earrings. In this example, the 
end-user desires to charge the earrings on his first credit card and ship 
the earrings to address of the end-user's friend. Thus, the third lineitem 
record 608 is configured to reference the third item record 602 containing 
information about the earrings, the first payment record 604 containing 
information about the end-user's first credit card and the second shipto 
record 606 containing the friend's address. 
The ability of multiple lineitem records 608 to reference the same item 
records 602, payment records 604 and shipto records 606 reduces the amount 
of data stored in the order object 600. This reduces memory requirements 
and provides flexibility. Furthermore, the structure of the order object 
600 allows the end-user to select items from a wide variety of merchants, 
specify a wide variety of credit options and enter a wide variety of 
shipping instructions. 
The item record 602 of the preferred embodiment contains an item identifier 
610, an item description or summary 612, a stock keeping unit (sku) 614, a 
price 616, a quantity value 618, a merchant identifier 620, a shipment 
method 622 and additional item properties 624 which may be added in by 
different embodiments. In the preferred embodiment, the item identifier is 
a 16-bit value which uniquely identifies each item record 602. The summary 
612 contains a description of the item and is a variable length string. 
The stock keeping unit (sku) 614 contains item identification information 
and is a variable length string. The price 616 contains the cost of an 
item and specifies different currencies. The quantity value 618 is a 
32-bit value which contains the number of items. As described in more 
detail below, the merchant identifier 620 is a 128-bit globally unique 
identifier which identifies each merchant registered to transact 
electronic commerce. In the preferred embodiment, the merchant identifier 
620 is used to route secure messages to their proper destination. The 
shipment method 622 is a 32-bit value wherein different ship method values 
describe the mode of shipment such as American Express, first class United 
States mail, UPS, etc. 
The payment record 604 of the preferred embodiment contains a payment 
identifier 630, a credit card number 632, an expiration date 634, an 
issuing bank name 636, a billing address 638, a card type 640 and 
additional payment properties 642 which may be added in different 
embodiments. The payment identifier 630 is a 16-bit value which uniquely 
identifies each payment record 604. The credit card number is a twenty 
character fixed-length string. The expiration date 634 is an eight 
character fixed-length string. The issuing bank name 636 is a 64 character 
fixed-length string which contains the name of the bank which issued the 
credit card. The billing address 638 is four 64 character fixed-length 
strings which contain the billing address. The card type 640 is a 16 
character fixed-length string containing the card provider such as Visa, 
MasterCard, American Express, etc. 
The shipto record 606 of the preferred embodiment contains a shipto 
identifier 650, a shipping name 652, shipping address 654, phone numbers 
656, and additional shipping properties 658 which may be added by other 
embodiments. The shipto identifier 650 is a 16-bit value which uniquely 
identifies each shipto record 606. The shipping name 652 is a 64 character 
string which specifies the name of the recipient. The shipping address 654 
is four 64 character fixed-length strings which specify the address of the 
recipient. The phone number 656 contains two 64 character fixed-length 
strings which specify the voice and modem numbers of the customer. 
Each lineitem record 608 contains the lineitem identifier 670, the item 
identifier 610, the payment identifier 630, the shipto identifier 650 and 
the source identifier 672. The lineitem identifier 670 is a 16-bit value 
which uniquely identifies each lineitem record 608. The source identifier 
672 is optional and is a 16-bit value which identifies the source of the 
commercial transaction. 
The format of the secure purchase order message 102 generated by the order 
manager 302 is illustrated in FIG. 7. In the preferred embodiment the 
secure purchase order message 102 is an electronic mail message which 
contains a destination 700, a subject field 702, an audit attachment 704 
and one or more merchant attachments 706. The destination 700 specifies 
the electronic commerce service 104 in the on-line network 106 which in 
the preferred embodiment is MSN.sub.-- ECONN@MSN.COM. The MSN.sub.-- ECONN 
acronym identifies the electronic commerce service 104 and the MSN.COM 
acronym identifies the electronic address of the Microsoft Network. 
The subject field 702 contains the version of the order manager 302 which 
in the preferred embodiment is ECORDV05. The ECORDV05 acronym stands for 
the electronic commerce order manager version 0.5. In addition, the 
subject field 702 contains the transaction identifier 720, the date and 
time of the transaction 722, the dynamic link library version 724 and a 
catalog version 726. As discussed in more detail below, whenever the order 
manager 302 generates the secure purchase order message 102, the order 
manager 302 also generates the transaction identifier 720 which identifies 
each secure purchase order message 102. The transaction identifier 720 is 
a 128-bit globally unique identifier which is created with the OLE 
DEFINE.sub.-- GUID routine. The OLE DEFINE.sub.-- GUID routine is well 
known and is further described in OLE 2 Programmer's Reference Vols. I and 
II, Microsoft Press, 1993 and Brockschmidt, Inside OLE 2 Microsoft Press, 
1994. 
The date and time value defines the date and time the order manager 302 
created the secure purchase order message 102. The dynamic link library 
version 724 defines the version number of the order manager dynamic link 
library, while the catalog version identifies the version number of the 
consumer application 300. 
A. The Secure Technology Keys 
The present invention uses a wide variety of different encryption schemes, 
different encryption and decryption keys and different public key/private 
key pairs. In the preferred embodiment, the public key/private key pairs 
are based on well known and patented RSA encryption standards where were 
developed by the Massachusetts Institute of Technology and RSA Data 
Security, Inc. 
Preferably, the secured technology modules 304 in the consumer computers 
100, the merchant computers 108, the acquirer computers 112, the issuing 
bank computers 118 and the on-line network 106 rely on the following 
public key/private key pairs: the on-line network public key 312, the 
on-line network private key 408, the merchant public key 308, the merchant 
private key 504, the acquirer public key 310, and the acquirer private key 
506. The on-line network public key 312 is a 768-bit value. The on-line 
network private key 408 is a 768-bit value. The merchant public key 308 is 
a 768-bit value. The merchant private key 504 is a 768-bit value. The 
acquirer public key 310 is a 1024-bit value. The acquirer private key 506 
is a 1024-bit value. 
Besides the public key/private key pairs, as is discussed in more detail 
below, the secured technology modules 304 also utilize RC4 encryption keys 
(not shown) and DES encryption keys (not shown). In the preferred 
embodiment, the secured technology module 304 utilize RC4 encryption keys 
to encrypt the goods and service orders and the audit information 406. The 
secured technology module 304 utilizes the DES encryption keys to encrypt 
the payment instructions. 
The RC4 acronym stands for Ron Rivest's Cypher 4 and is well known by those 
of ordinary skill in the art. The RC4 encryption key of the preferred 
embodiment utilizes a 40-bit encryption value and a 16-bit supplemental 
encryption value to create a 56-bit RC4 encryption key. The DES acronym 
stands for the United States Data Encryption Standard. The implementation 
of the DES standard is well known to those of ordinary skill in the art. 
Preferably, the DES encryption keys are 56-bit values. 
B. The Merchant Attachment 
The merchant attachment 706 contains the merchant public keys 308, the 
acquirer public keys 310 and a transaction GSO/PI packet 708. The GSO/PI 
acronym stands for the combination of a goods and services order (GSO) and 
a payment instruction (PI). Referring now to FIGS. 8A and 8B, a block 
diagram of the preferred transaction GSO/PI packet 708 is shown. In the 
preferred embodiment, the transaction GSO/PI packet 708 contains a goods 
and services order 710 and a payment instruction 712. 
The goods and service order 710 contains a RC4 encryption key 800, a signed 
merchant data packet 802, a optional consumer digital signature field 804 
and a miscellaneous information field 806. The preferred embodiment 
creates a different RC4 encryption key 800 for each goods and services 
order 710. As discussed in more detail below, the preferred embodiment 
then encrypts the RC4 encryption key 800 with the 768-bit merchant public 
key 308. Thus, only the merchant computer 108 can obtain the RC4 
encryption key 800 with the merchant private key 504. 
The signed merchant data packet 802 contains a consumer information segment 
810, merchant information segment 812 and an other information segment 
814. The consumer information segment 810 includes the customer name field 
820, the customer address field 822 and the customer phone number field 
824. The customer name field 820 is a 64 character fixed-length string. 
The customer address field 822 comprises two sets of four 64 character 
fixed-length strings. One set of strings provides a shipping address and 
the other set of strings provides a billing address. The customer phone 
number field contains two 64 character fixed-length strings which contain 
the voice and modem phone numbers of the end-user. 
The merchant information segment 812 contains a merchant name field 830, a 
merchant identifier field 832, and a transaction identifier field 834. The 
merchant name field 830 is a 64 character fixed-length string. The 
merchant identifier field 832 is a 128-bit fixed-length string. As 
explained in more detail below, the merchant identifier 620 is assigned by 
the on-line network 106 during the registration process. The transaction 
identifier field 834 is a 128-bit fixed-length string which contains the 
transaction identifier 720 and a concatenated non-decreasing serial 
number. The preferred embodiment increases the serial number every time it 
creates a purchase order message 102. 
The other information segment 814 contains a term field 840, a summary 
field 842, a charge slip field 844, a price field 846, and an optional 
consumer key exchange affidavit field 848 (hereinafter referred to as the 
consumer affidavit field 848). The term field 840 is a 16-bit number that 
identifies the number of items. The summary field 842 is a variable-length 
string that represents the summary of the order which appears on a credit 
card bill. The charge slip field 844 is a variable-length string which 
contains the order displayed to the end-user. The price field 846 is a 64 
character fixed-length field which contains the amount of the transaction. 
The consumer affidavit field 848 is not used in the preferred embodiment, 
but can comprise a fixed-length field which contains the consumer 
affidavit (the digitally signed consumer public key.) The consumer digital 
signature field 804 is not used in the preferred embodiment, but can be a 
fixed-length field containing data encrypted with the consumer private 
key. 
The miscellaneous information field 806 contains variable-length strings 
which further describe details about the transaction. The preferred 
embodiment encrypts the signed merchant data packet 802, the optional 
consumer digital signature field 804 and the miscellaneous information 
field 806 with the RC4 encryption key 800. 
Focusing now on the payment instruction 712, the payment instruction 712 
contains a credit card number field 860, a DES encryption key 862, a 
signed acquirer data packet 864, and a copy of the consumer digital 
signature field 804. The credit card number field is a 20 character 
fixed-length string which contains a credit card number. The DES 
encryption key 862 is a 56-bit value which is randomly generated and which 
complies with the Data Encryption Standard (DES) encryption scheme 
described above. The preferred embodiment uses the 56-bit DES encryption 
key 862 to encrypt the signed acquirer data packet 864 and the consumer 
digital signature field 804. The preferred embodiment then encrypts the 
credit card number field 860 and the DES encryption key 862 with the 
1024-bit acquirer public key 310. Thus, only the acquirer private key 506 
can decrypt the credit card number field 860 and the DES encryption key 
862. 
The signed acquirer data packet 864 contains the consumer information 
segment 810, the merchant information segment 812, a credit card 
information segment 870 and the other information segment 814. The 
consumer information segment 810 contains a copy of the consumer name 
field 820, the customer address field 822 and the customer phone number 
field 824. The merchant information segment 812 contains a copy of the 
merchant name field 830, the merchant identifier field 832 and the 
transaction identifier field 834. 
The credit card information segment 870 contains an issuing bank field 872, 
an expiration date field 874 and a card type field 876. The issuing bank 
field 872 is a 64 character fixed-length field which contains the name of 
the bank appearing on the consumer's credit card. The expiration date 
field 874 is an eight character fixed-length field which contains the 
expiration date of the consumer's credit card. The card type field 876 is 
a 16 character field which contains the card type such as, for example, 
Visa, Mastercard, American Express, etc. 
The other information segment 814 contains a copy of the term field 840, 
the summary field 842, the charge slip field 844 and the price field 846. 
In addition, the other information segment 814 contains an optional card 
key exchange affidavit field 880 and an optional credential flag 882. 
C. The Audit Attachment 
Referring now to FIG. 9, a block diagram of the preferred audit attachment 
704 is shown. In the preferred embodiment, the audit attachment 704 
comprises a uniquely formatted audit GSO/PI packet 714. The audit GSO/PI 
packet 714 contains an audit goods and services order 902 and an empty 
payment instruction 904. 
The audit goods and services order 902 includes an RC4 encryption key 800, 
an auditing data packet 906, and the miscellaneous information field 806. 
The RC4 encryption key 800 is a 56-bit value based on the RC4 encryption 
scheme described above. The preferred embodiment encrypts the signed 
auditing data packet 906 and the miscellaneous information field 806 with 
the RC4 encryption key 800. The preferred embodiment then uses encrypts 
the RC4 encryption key 800 with the 768-bit on-line network public key 
312. Thus, only the on-line network private key 408 can decrypt the 
auditing goods and services order. 
The signed auditing data packet 906 contains a copy of the consumer 
information segment 810. The copy includes an auditing name field 916, an 
auditing address field 918 and an auditing phone number field 920. The 
miscellaneous information field 806 contains a merchant table 908. In the 
preferred embodiment, the merchant table 908 contains one or more rows 
910. The number of rows 910 in the merchant table 910 correspond to the 
number of merchant attachments in the secure purchase order message 102. 
Preferably, each row in the merchant table 910 contains an index value 912, 
the merchant identifier field 832, the price field 846 and a quantity 
value 914. The index value 912 is a 16-bit value which identifies the 
row's corresponding merchant attachment. The quantity value 914 is a 
32-bit value which contains the quantity of items purchased in the secure 
purchase order message 102. The price field 846 is a 64 character value 
which contains the total purchase price of the items in the secure 
purchase order message 102. The merchant identifier field 832 is a 128-bit 
value which contains the merchant identifier 620. 
V. Registration 
FIG. 10 illustrates a high level flow chart of the sequence of states which 
occur during the registration process. Beginning in a start state 1000, a 
preferred embodiment of the present invention proceeds to state 1002. In 
state 1002, the electronic commerce service 104 generates the on-line 
network public key 312 and the on-line network private key 408. As 
discussed above, the generation of public key/private key pairs is well 
known in the art. 
After generation of the on-line network public key 312 and the on-line 
network private key 408, the electronic commerce service 104 makes the 
on-line network public key 312 publicly available, and keeps the on-line 
network private key 408 private. In the preferred embodiment, software 
developers typically incorporate the on-line network public key 312 into 
the consumer applications 300, the order managers 302, the merchant 
modules 500 and the acquirer modules 502. In other embodiments, the 
software developers design the consumer applications 300, the order 
managers 302, the merchant modules 500 and the acquirer modules 502 to 
access the on-line network 106 so as to obtain the on-line network public 
key 312. 
A. Merchant/Acquirer Registration 
Proceeding to state 1004, the merchant module 500 of the preferred 
embodiment generates the merchant public key 308 and the merchant private 
key 504. In state 1006, the acquirer module 502 generates a acquirer 
public key 310 and an acquirer private key 506. As explained above, the 
merchant public key 308, the merchant private key 504, the acquirer public 
key 310 and the acquirer private key 506 are created with secure 
techniques known to one of ordinary skill in the art. 
Proceeding to state 1008, the merchant computer 108 registers the merchant 
public key 308 and the acquirer public key 310 with the electronic 
commerce service 104. Referring now to FIG. 11, a detailed flow chart 
further illustrates the registration process of state 1008. Beginning in a 
start state 1008, the merchant computer 108 proceeds to state 1100 where 
the secured technology module 304 encrypts the merchant public key 308 and 
the acquirer public key 310 with the on-line network public key 312. 
The electronic mail module 306 then sends the encrypted merchant public key 
308 and the encrypted acquirer public key 310 to the bindery module 402 in 
the electronic commerce service 104. The preferred embodiment uses the 
on-line network public key 408 to encrypt the merchant public key 308 and 
the acquirer public key 310. Thus, only the bindery module 402 can decrypt 
the encrypted merchant public key 308 and the encrypted acquirer public 
key 310 with the on-line network private key 408. This prevents others 
from fraudulently acting as the bindery module 402. 
Proceeding to state 1102, the bindery module 402 directs the secured 
technology module 304 in the electronic commerce service 104 to decrypt 
the merchant public key 308 with the on-line network private key 408. In 
addition, the bindery module 402 directs the secured technology module 304 
to decrypt the acquirer public key 310 with the on-line network private 
key 408. The bindery module 402 then stores the decrypted merchant public 
key 308 and the decrypted acquirer public key 310 in the electronic 
commerce database 404. 
Proceeding to state 1104, the secured technology module 304 digitally signs 
the merchant public key 308. In the preferred embodiment, the secured 
technology module 304 creates the digital signature by encrypting a data 
segment with the on-line network private key 408. The digital signature is 
then appended to the merchant public key 308. In the preferred embodiment, 
the digitally signed merchant public key 308 is called the merchant 
affidavit 410. In like manner, the secured technology module 304 also 
digitally signs the acquirer public key 310 to create the acquirer 
affidavit 412. 
Proceeding to state 1106, the secured technology module 304 encrypts the 
merchant affidavit 410 with the merchant public key 308. Encrypting the 
merchant affidavit 410 with the merchant public key 308 ensures that only 
the merchant module 500 can view the merchant affidavit 410. In state 
1108, the secured technology module 304 encrypts the acquirer affidavit 
412 with the acquirer public key 310. Encrypting the acquirer affidavit 
412 with the acquirer public key 310 ensures that only the acquirer module 
502 can view the acquirer affidavit 412. During state 1108, the secured 
technology module 304 routes the encrypted merchant affidavit 410 and the 
encrypted acquirer affidavit 412 back to the merchant computer 108 via the 
electronic mail service 214. 
Proceeding to state 1110, the merchant module 500 directs the secured 
technology module 304 to decrypt the encrypted merchant affidavit 410 with 
the merchant private key 504. Proceeding to state 1112, the acquirer 
module 502 directs the secured technology module 304 to decrypt the 
encrypted acquirer affidavit 412 with the acquirer private key 506. Once 
the secured technology module 304 decrypts the merchant affidavit 410 and 
the acquirer affidavit 412 in end state 1114, the merchant can publicly 
distribute the merchant affidavit 410 and the acquirer affidavit 412. 
For example, the merchant could distribute a list of goods for sale, the 
merchant affidavit 410 and the acquirer affidavit 412 to a developer of a 
consumer application 300. The developer can then create a consumer 
application 300 such as a sales catalog which contains the items for sale, 
the merchant affidavit 410 and the acquirer affidavit 412. As explained in 
more detail below, when a user of the consumer application 300 purchases 
one of the items, the consumer computer 100 uses the information in the 
merchant affidavit 410 and the acquirer affidavit 412 to create a secured 
purchase order message 102. 
B. Consumer Registration 
In the preferred embodiment, the consumers do not register with the 
bindery. However, in other embodiments, the consumers may separately 
generate their own consumer public key and consumer private key. Referring 
now to FIG. 10, in these other embodiments, the order manager 302 in the 
consumer computer 100 continues the registration process in state 1010. In 
state 1010, other embodiments generate a consumer public key and a 
consumer private key. Proceeding to state 1012, the consumer computer 100 
registers the consumer public key with the electronic commerce service 104 
and keeps the consumer private key private. 
Referring now to FIG. 12, a detailed flow chart illustrates the consumer 
registration process of state 1012. Beginning in start state 1012, the 
secured technology module 304 proceeds to state 1200 and encrypts the 
consumer public key with the on-line network public key 312. Encrypting 
the consumer public key with the on-line network public key ensures that 
only the electronic commerce service 104 can view the consumer public key. 
During state 1012, the electronic mail module 306 sends an electronic 
message containing the encrypted consumer public key to the bindery module 
402 in the electronic commerce service 104. 
Proceeding to state 1202, the bindery module 402 directs the secured 
technology module 304 in the electronic commerce service 104 to decrypt 
the consumer public key with the on-line network private key 408. The 
bindery module 402 then stores the consumer public key in the electronic 
commerce database 404. Proceeding to state 1204, the secured technology 
module 304 digitally signs the consumer public key with the on-line 
network private key 408. In this embodiment, the digitally signed consumer 
public key is called the consumer affidavit. 
Proceeding to state 1206, the secured technology module 304 encrypts the 
consumer affidavit with the consumer public key. Encrypting the consumer 
affidavit with the consumer public key ensures that only the order manager 
302 can view the consumer affidavit. The bindery module 402 then creates 
an electronic mail message which contains the encrypted consumer 
affidavit. The electronic mail message is then routed back to the consumer 
computer 100 via the electronic mail service 214. 
Proceeding to state 1208, the electronic mail module 306 in the consumer 
computer 100 receives the encrypted consumer affidavit and forwards it to 
the order manager 302. The order manager 302 then directs the secured 
technology module 304 to decrypt the consumer affidavit with the consumer 
private key and proceeds to end state 1210. Returning now to FIG. 10, the 
order manager 302 then proceeds to end state 1012. When a user of the 
consumer computer 100 purchases an item, this embodiment of the present 
invention includes the consumer affidavit in the secure purchase order 
message 102. 
VI. Secured Transaction Processing 
FIGS. 13A and 13B illustrate a data flow diagram of the sequence of states 
which occur during the commercial transaction process. The states 
illustrate the process of generating a purchase order message 102 which is 
electronically mailed to the electronic commerce service 104 in the 
on-line network 106. The electronic commerce service 104 extracts the 
audit attachment 704, makes backup copies, and routes the merchant 
attachments 706 to the proper merchant computers 108. The merchant 
computers 108 then process the merchant attachments 706. 
A. Generating the Purchase Order Message 
Beginning in a start state 1300, the end-user of the consumer computer 100 
initiates a consumer application 300. For example, in state 1300, an 
end-user can initiate the consumer application 300 by selecting a menu 
option, selecting an icon, entering keyboard commands, mouse commands, 
voice commands and the like. Proceeding to state 1302, the end-user views 
the goods and services offered in the consumer application 300 and selects 
an item for purchase. For example, the consumer application 300 could 
display the image of a jacket which the end-user desires to purchase. The 
end-user then selects the jacket by manipulating an input device such as a 
keyboard, mouse, joystick, remote control, or voice processing unit. 
Proceeding to state 1304, the consumer application 300 communicates with 
the order manager 302 to generate a secure purchase order message 102. In 
processing state 1304, the consumer application 300 communicates with the 
order manager 302 by calling the order manager application programming 
interfaces or functions. Typically, a software developer adds software 
instructions to the consumer application 300 which call the application 
programming interfaces in the order manager 302. Alternatively, as 
described above, a software developer can create software instructions 
which instantiate the OLE server which in turn calls the application 
programming interfaces in the order manager 302. 
1. Creation Of The Order Object 
In state 1304, the consumer application 300 of the preferred embodiment 
initiates the purchase order process by calling the BeginOrder function 
320 (hereinafter referred to as the BeginOrder function 320). The 
BeginOrder function 320 uses well known object-oriented techniques to 
instantiate the order object 600. For example, if the end-user desires to 
purchase a shirt displayed by the consumer application 300, the end-user 
selects the shirt and the consumer application 300 calls the BeginOrder 
function 320 which instantiates the order object 600. 
Referring now to FIG. 14, a detailed block diagram of the purchase order 
process is shown. After calling the BeginOrder function 320 in state 1304, 
the consumer application 300 proceeds to state 1400 where it determines 
whether it needs to create an item record 602 in the order object 600. For 
each item the end-user selects, the consumer application 300 determines 
whether a new item record 602 needs to be added to the order object 600. 
For example, if the item record 602 about the selected shirt has already 
exists in the order object 600, the consumer application 300 proceeds to 
state 1402. If, however, such an item record 692 does not exist in the 
order object 600, the consumer application 300 proceeds to state 1404. 
In state 1404, the consumer application 300 calls the CreateItem function 
322. When calling the CreateItem function 322, the consumer application 
300 passes the summary 612, the price 616, the quantity value 618, the 
merchant identifier 620 and the shipment method 622 to the CreateItem 
function 322. The CreateItem function 322 uses well known object-oriented 
techniques to create the item record 602 and the item identifier 610. In 
addition, the CreateItem function 322 stores the summary 612, the price 
616, the quantity value 618, the merchant identifier 620 and the shipment 
method 622 in the newly created item record 602. 
For example, the first time an end-user selects a shirt, the consumer 
application 300 calls the CreateItem function 322 and passes a summary 612 
of the shirt, the price 616 of the shirt, the quantity 618 of the shirts, 
the merchant identifier 620 of the merchant selling the shirt and the 
shipment method 622 to the CreateItem function 322. The CreateItem 
function 322 then uses known object-oriented techniques to create an item 
record 602 and an item identifier 610. In this example, the CreateItem 
function 322 then stores the summary 612 of the shirt, the price 616, the 
quantity value 618, the merchant identifier 620 and the shipment method 
622 in the newly created item record 602. 
If the end-user selects another item such as a watch, the consumer 
application 300 calls the CreateItem function 322 to creates another item 
record 602. However, if the end-user selects the same shirt a second time, 
such as when the user wants two of the same shirts, the consumer 
application 300 does not create a new item record 602. A new item record 
602 is unnecessary because an item record 602 which contains information 
about the shirt already exists in the order object 600. 
Proceeding to step 1402, the consumer application 300 determines whether to 
add any shipping information to the order object 600. For example, the 
end-user may desire to specify different shipping instructions for 
different items. If the end-user does not enter additional shipping 
information, the consumer application 300 proceeds to state 1406. If, 
however, the end-user enters additional shipping instructions, the 
consumer application 300 proceeds to state 1408 and calls the CreateShipTo 
function 324. 
When calling the CreateShipTo function 324, the consumer application 300 
passes the shipping name 652, the shipping address 654 and the phone 
numbers 656. The CreateShipTo function 324 then uses well known 
object-oriented techniques to create the shipto record 606 and the shipto 
identifier 650. The CreateShipTo function 324 accordingly stores the 
shipping name 652, the shipping address 654 and the phone numbers 656 in 
the newly created shipto record 606. 
For example, if the end-user desires to have a purchased shirt delivered to 
the end-user's home, the end-user enters the end-user's name and home 
address into the consumer application 300. The consumer application 300 
then calls the CreateShipTo function 324 and passes the end-user's name 
and shipping directions. The CreateShipTo function 324 creates the shipto 
record 606 and the shipto identifier 650 and stores the shipping name 652, 
the shipping address 654 and the phone numbers 656 in the newly created 
shipto record 606. 
Proceeding to state 1406, the consumer application 300 determines whether 
any payment information needs to be added to the order object 600. For 
example, the end-user may desire to specify different payment methods for 
different items. For example, an end-user might use his MasterCard for one 
item and his Visa card for another item. If the consumer application 300 
does not need to add new payment information, the consumer application 300 
proceeds to state 1410. If new payment information needs to be added, the 
consumer application 300 proceeds to state 1412 and calls the 
CreatePayment function 326. 
When calling the CreatePayment function 326, the consumer application 300 
passes the end-user's credit card number 632, the expiration date 634, the 
issuing bank name 636, the billing address 638 and the card type 640. 
While in state 1412, the CreatePayment function 326 then uses well known 
object-oriented techniques to create the payment record 604 and the 
payment identifier 630. In addition, the CreatePayment function 326 stores 
the credit card number 632, the expiration date 634, the issuing bank name 
636, the billing address 638 and the card type 640 in the newly created 
payment record 604. 
For example, if the end-user desires to pay for an item with his Visa 
credit card, the end-user enters the Visa credit card information into the 
consumer application 300. When calling the CreatePayment function 326, the 
consumer application 300 then passes the end-user's Visa credit card 
number 632, the credit card expiration date 634, the issuing bank name 
636, the end-user's billing address 638 and the card type 640. The 
CreatePayment function 326 then creates the payment record 604 and the 
payment identifier 630 and stores the Visa credit card information in the 
newly created payment record 604. 
Proceeding to state 1410, the consumer application 300 creates the lineitem 
records 608. The use of different lineitem records 608 allows the creation 
of multi-item, multi-merchant purchase order messages 102 with independent 
item information, payment instructions and shipping information. In the 
preferred embodiment, the consumer application 300 calls the 
CreateLineltem function 328. 
When calling the CreateLineltem function 328, the consumer application 300 
passes the desired item identifier 610, the payment identifier 630 and the 
shipto identifier 650 to the CreateLineltem function 328. Using techniques 
known to one of ordinary skill in the art, the CreateLineltem function 328 
creates a lineitem record 608, a lineitem identifier 670 and a source 
identifier 672. In addition, the CreateLineItem function 328 stores the 
passed item identifier 610, the payment identifier 630 and the shipto 
identifier 650 in the lineitem record 608. For example, if the end-user 
desires to purchase a shirt with his Visa credit card and have the shirt 
delivered to his home, the consumer application 300 passes the item 
identifier 610 which identifies the item record 602 containing information 
about the selected shirt, the payment identifier 630 which identifies the 
payment record 604 containing the Visa credit card information, and the 
shipto identifier 650 which identifies the shipto record 606 containing 
the end-user's home shipping address. 
Proceeding to state 1414, the consumer application 300 determines whether 
to create any other lineitem records 608. For example, if the end-user 
desires to purchase another item, the consumer application 300 proceeds to 
step 1400 and begins the process of creating another lineitem record 608. 
If, however, in state 1414, the end-user no longer desires to purchase 
additional items, the consumer application 300 proceeds to state 1416 and 
calls the SubmitOrder function 330. 
2. Creation of the Transaction GSO/PI packet 
Referring now to FIG. 15, a data flow diagram of the SubmitOrder function 
330 is shown. Beginning in state 1416, the SubmitOrder function 330 
generates a transaction identifier 720 and a concatenated non-decreasing 
serial number. The SubmitOrder function 330 increases the serial number 
every time it creates a purchase order message 102. In state 1416, the 
SubmitOrder function 330 also obtains the transaction information from the 
order object 600. Furthermore, the SubmitOrder function 330 accesses the 
lineitem records 608 in the order object 600. 
For each lineitem record 608 in the order object 600, the SubmitOrder 
function 330 creates an unencrypted transaction GSO/PI packet 708. Within 
the transaction GSO/PI packet 708, the SubmitOrder function 330 stores the 
transaction identifier 720 in the transaction identifier field 834. From 
the item record 602, the SubmitOrder function 330 stores the item summary 
612 in the miscellaneous information field 806, stores the price 616 in 
the price field 846, stores the merchant identifier 620 in the merchant 
identifier field 832, and stores the shipping method 622 it in the 
miscellaneous information field 806. 
During state 1416, the SubmitOrder function 330 also accesses the lineitem 
record 608 to obtain the payment identifier 630. Using the payment 
identifier 630, the SubmitOrder function accesses the payment information 
in the identified payment record 604 and stores the payment information in 
the transaction GSO/PI packet 708. In particular, the SubmitOrder function 
330 stores the credit card number 632 in the credit card number field 860, 
stores the expiration date 634 it in the expiration date field 874, stores 
the issuing bank name 636 in the issuing bank field 872, stores the 
billing address 638 in the customer address field 822 and stores the card 
type 640 in the card type field 876. 
During state 1416, the SubmitOrder function 330 also accesses the lineitem 
record 608 to obtain the shipto identifier 650. Using the shipto 
identifier 650, the order manager 302 accesses the shipping information in 
the identified shipto record 606 and stores the shipping information in 
the transaction GSO/PI packet 708. In particular, the SubmitOrder function 
330 stores the customer's shipping name 652 in the customer name field 
820, stores the customer's shipping address 654 in the customer address 
field 822, and stores the customer's phone number 656 in the customer 
phone number field 824. 
During state 1416, the SubmitOrder function 330 accesses each lineitem 
record 608 in a similar manner. For example, if a commercial transaction 
contains more than one item, more than one merchant, more than one credit 
card account, or different shipping instructions, multiple lineitem 
records 608 will exist in the order object 600. Thus, the SubmitOrder 
function 330 will create separate transaction GSO/PI packets 708 for each 
lineitem record 608. 
3. Creation Of The Auditing GSO/PI Packet 
In state 1416, the order manager 302 also creates an unencrypted auditing 
GSO/PI packet 714 and accesses the lineitem records 608 to obtain the 
audit information. In the preferred embodiment, the SubmitOrder function 
stores the customer's shipping name 652 in the auditing name field 916, 
stores the customer's shipping address 654 in the auditing address field 
918, and stores the customer's phone number 656 in the auditing phone 
number field 920. 
For each lineitem record 608, the SubmitOrder function 330 also creates a 
new row 910 in the merchant table 908 and a new index value 912 which 
identifies the new row 910. Within each row, the SubmitOrder function 330 
stores the price 616 in the price field 846, stores the quantity value 618 
in the quantity field 914, and stores the merchant identifier 620 in the 
merchant identifier field 832. 
For example, after an end-user has selected a shirt and a tie, two lineitem 
records 608 exist in the order object 600. The consumer application 300 
then calls the SubmitOrder function 330 which creates the unencrypted 
auditing GSO/PI packet 704 and the merchant table 908. For each of the 
lineitem records 608, the SubmitOrder function 330 adds a row 910 of audit 
information 406 to the merchant table 908. 
4. Encryption Of The Transaction GSO/PI Packet And The Auditing GSO/PI 
Packet 
Proceeding to state 1500, the order manager 302 directs the secured 
technology module 304 to generate the secure transaction GSO/PI packet 
708. As explained above, the secured technology uses Microsoft's Secured 
Transaction Technology, however, one of ordinary skill in the art will 
appreciate that a wide range of secure techniques could be used. 
Proceeding to state 1504, the secure technology module 304 generates the 
RC4 encryption key 800. With the RC4 encryption key, the secured 
technology module 304 encrypts the signed merchant data packet 802, the 
consumer signature field 804 and the miscellaneous information field 806. 
The secured technology module 304 then encrypts the RC4 encryption key 800 
with the merchant public key 308. This ensures that only the merchant 
computer 108 can decrypt the goods and service order 710. 
In the preferred embodiment, the merchant public key 308 is obtained from 
the merchant affidavit 410. As explained above, the electronic commerce 
service 104 creates the merchant affidavit 410 when the merchant computer 
108 registers the merchant public key 308. In the preferred embodiment, 
the merchant affidavit 410 contains the merchant public key 308, the 
acquirer public key 310 and the electronic commerce digital signature. 
Focusing now on state 1506, the secured technology module 304 obtains the 
merchant affidavit 410 from the consumer application 300. During state 
1506, the secured technology module 304 uses well known techniques to 
verify the merchant affidavit 410. In the preferred embodiment, the 
secured technology module 304 compares the electronic commerce digital 
signature with the on-line network public key 312 in order to determine if 
the appropriate relationship exists. If so, the secured technology module 
304 uses the merchant public key 308 and the acquirer public key 310. 
Returning to state 1504, the secured technology module 304 also generates 
the DES encryption key 862 and uses the DES encryption key 862 to encrypt 
the signed acquirer data packet 864 and the consumer digital signature 
field 804. The secured technology module 304 then encrypts the credit card 
number field 860 and the DES encryption key 862 with the acquirer public 
key 310. This ensures that only the acquirer can decrypt the payment 
instructions 712. 
Proceeding to state 1508, the secured technology module 304 stores the 
encrypted transaction GSO/PI packets 708 in the merchant attachments 706. 
In addition, the secured technology module 304 stores the merchant public 
key 308 and the acquirer public key 310 in the merchant attachment 706. In 
the preferred embodiment, the secured technology module 304 creates a 
merchant attachment 706 for each lineitem record 608. 
Focusing now on the encryption of the auditing GSO/PI packet 714, the 
secured technology module 304 proceeds to state 1510. In state 1510, the 
secured technology module 304 generates an auditing RC4 encryption key 800 
and encrypts the auditing GSO/PI packet 714 with the auditing RC4 
encryption key 800. The secured technology module 304 then encrypts the 
auditing RC4 encryption key 800 with the on-line network public key 312. 
This ensures that only the electronic commerce service 104 can decrypt the 
auditing goods and services order 902. In the preferred embodiment, the 
auditing payment instruction 904 is left empty. Proceeding to state 1508, 
the secured technology stores the encrypted auditing GSO/PI packet 704 in 
the audit attachment 704. 
5. Creation Of The Secure Purchase Order Message 
After creating the merchant attachments 706 and the audit attachment 704 in 
state 1508, the order manager 302 communicates with the electronic mail 
module 306 to create the secure purchase order message 102. In the 
preferred embodiment, the order manager 302 sends the merchant attachments 
706, the audit attachment 704, the electronic commerce service destination 
700, the transaction identifier 720, the date and time information 722, 
the order manager's dynamic link version 724 and the consumer application 
version 726 to the electronic mail module 306. 
The electronic mail module 306 uses well known techniques to create the 
secure purchase order message 102. The electronic mail module 306 stores 
the address of the electronic commerce service 104 in the destination 700. 
In the subject field 702, the electronic mail module 306 stores the 
transaction identifier 720, the date and time information 722, the order 
manager dynamic link version 724 and the consumer application version 726. 
The electronic mail module 306 attaches the encrypted audit attachment 704 
and the encrypted merchant attachment 706. The electronic mail module 306 
then sends the secure purchase message 102 to the electronic commerce 
service 104. 
B. Processing The Audit Attachment 
Referring now to FIGS. 13A and 13B, the execution states associated with 
the electronic commerce service 104 are shown. In state 1306, the 
electronic mail service 214 receives the secure purchase order message 102 
from the consumer computer 100. While in state 1306, the electronic mail 
service 214 forwards the secure purchase order message 102 to the 
electronic commerce service 104. 
Proceeding to state 1308, the decryption module 400 obtains the audit 
attachment 704 from the secure purchase order message 102. The decryption 
module 400 then directs the secured technology module 304 in the 
electronic commerce service 104 to decrypt the audit attachment 704. In 
the preferred embodiment, the secured technology module 304 uses the 
on-line network private key 408 to decrypt the RC4 encryption key 800 in 
the auditing goods and services order 902. With the RC4 encryption key 
800, the secured technology module 304 then decrypts the signed auditing 
data packet 906 and the merchant table 908. 
Proceeding to state 1310, the decryption module 400 extracts the audit 
information 406 from the decrypted audit attachment 704 and stores it in 
the electronic commerce database 404. In particular, the decryption module 
400 stores the data in the consumer information segment 906, the data in 
the merchant table 908 and copies of the encrypted merchant attachments 
706 in the electronic commerce database 404. 
Proceeding to state 1312, the decryption module 400 uses the merchant table 
to route each encrypted merchant attachment 706 to the proper merchant 
computer 108. In the preferred embodiment, each row in the merchant table 
corresponds to one of the merchant attachments 706. Beginning with the 
first row, the decryption module 400 obtains the merchant identifier 620 
from the merchant identifier field 832. The decryption module 400 then 
uses the merchant identifier 620 to locate the merchant's electronic mail 
address in the electronic commerce database 404. Thus, the electronic 
commerce service 104 uses the merchant identifiers 620 identify the 
destination address of the encrypted merchant attachments 706. 
Proceeding to state 1312, the decryption module 400 generates a merchant 
electronic mail message which contains the merchant's electronic mail 
address and the encrypted merchant attachment 706. The decryption module 
400 then forwards the merchant electronic mail message to the electronic 
mail service 214 which sends the merchant electronic mail message to the 
merchant computer 108. 
If another row exists in the merchant table, the decryption module 400 
prepares an electronic mail message for the next merchant. Thus, during 
state 1312, the decryption module 400 continues to generate the merchant 
electronic mail messages until every merchant attachment 706 has been sent 
to a merchant computer 108. 
C. Processing The Merchant Attachments 
Referring now to the data flow states in the merchant computers 108, in 
state 1314 the electronic mail module 306 in the merchant computer 108 
receives the electronic mail messages generated by the electronic commerce 
service 104. In the preferred embodiment, the merchant module 500 executes 
the GetOrder function 520. The GetOrder function 520 uses known techniques 
to retrieve the merchant electronic mail message from the electronic mail 
module 306. 
Proceeding to state 1316, the merchant module 500 directs the secured 
technology module 304 in the merchant computer 108 to decrypt the merchant 
GSO/PI packet 708. Preferably, the secured technology module 304 uses the 
merchant private key 504 to decrypt the RC4 encryption key 800 in the 
merchant goods and services order 710. With the RC4 encryption key 800, 
the secured technology module 304 encrypts the signed merchant data packet 
802, the consumer digital signature field 804 and the miscellaneous 
information field 806. 
In other embodiments, the secured technology module 304 also obtains the 
consumer public key from the consumer's affidavit field 848. The secured 
technology module 304 then compares the consumer digital signature field 
804 with the consumer public key in order to determine if the appropriate 
relationship exists. If so, the secured technology module 304 indicates 
that the data in the merchant signed data packet 802 is authentic. 
Proceeding to state 1318, the merchant module 500 sends a credit 
confirmation 122 to the acquirer module 502. In the preferred embodiment, 
the merchant module 500 executes the CreateAuthRequest function 522 to 
generate the credit confirmation 122. In the preferred embodiment, the 
credit confirmation 122 contains the encrypted payment instructions 712. 
In state 1318, the acquirer module 502 receives the payment authorization 
request 110 and decrypts the payment instruction 712. In the preferred 
embodiment, the acquirer module 502 directs the secured technology module 
304 to decrypt the payment instruction 712. The secured technology module 
304 encrypts the DES encryption key 862 and credit card number field 860 
with the acquirer private key 506. With the DES encryption key 862, the 
secured technology module 304 decrypts the signed acquirer data packet 864 
and the consumer's digital signature field 804. 
After decryption of the payment instructions, the acquirer module 502 uses 
the data in the credit card number field 860, customer information segment 
810, the credit card information segment 870 and the other information 
segment 814 to determine whether the customer has sufficient funds. In the 
preferred embodiment, the acquirer module 502 executes the 
ProcessAuthRequest function 530 to determine whether the customer has 
sufficient funds. The ProcessAuthRequest function 530 uses techniques 
which are well known in the art to compare the funds available in a user's 
credit account with the amount of the purchase. 
After processing the credit request 120, the acquirer module 502 sends a 
payment authorization response 114 back to the merchant module 500. In the 
preferred embodiment, the acquirer module 502 executes the 
CreateAuthResponse function 532. The CreateAuthResponse function 532 uses 
known techniques to generate the payment authorization response 114 and 
send it back to the merchant module 500. 
Upon receiving the payment authorization response 114, the merchant module 
500 process the payment authorization response 114 with the 
ProcessAuthResponse function 524. If the acquirer module 502 denies the 
credit request, the ProcessAuthResponse function 524 denies the commercial 
transaction and sends a denial message back to the consumer computer 100. 
If, however, the acquirer module 502 authorizes the credit request, the 
ProcessAuthResponse function 524, proceeds to state 1322 and completes the 
requested commercial transaction. 
Proceeding to state 1322, the merchant module 500 delivers the requested 
goods and services and generates a receipt. In the preferred embodiment, 
the merchant module 500 creates the receipt with the CreateReceipt 
function 526. The CreateReceipt function 526 creates a receipt detailing 
the goods and services the merchant has provided to the end-user. In other 
embodiments, the CreateReceipt function 526 directs the secured technology 
to encrypt the receipt with the consumer public key. The encrypted receipt 
is then electronically mailed to the consumer computer 100 where the 
receipt is decrypted with the consumer private key. 
While the above detailed description has shown, described and pointed out 
the fundamental novel features of the invention as applied to a preferred 
embodiment, it will be understood that various omissions and substitutions 
and changes in the form and details of the illustrated device may be made 
by those skilled in the art without departing from the spirit of the 
invention. Consequently, the scope of the invention should not be limited 
to the foregoing discussion but should be defined by the appended claims. 
VII. Appendix 
The following Appendix forms part of the specification hereof and contains 
the "Secured Transaction Technology Open Specification/Wire Formats and 
Protocols, version 0.902." published by the Microsoft Corporation. While 
the preferred embodiment uses Microsoft's Secured Transaction Technology, 
one of ordinary skill in the art will appreciate that a wide range of 
secure techniques can be used to implement the present invention. 
##SPC1##