 |
Claims  |
|
|
I claim:
1. A system for electronic commercial payment comprising:
a customer trusted agent;
a first money module associated with said customer trusted agent that securely communicates with said customer trusted agent;
a merchant trusted agent that establishes a first secure session with said customer trusted agent by using cryptographic means;
a second money module associated with said merchant trusted agent that securely communicates with said merchant trusted agent, and that establishes a second secure session with said first money module by using cryptographic means;
where said customer trusted agent provides a remittance advice information signal to said merchant trusted agent, and said merchant trusted agent provides a commercial payment ticket signal to said customer trusted agent;
where upon receiving said commercial payment ticket signal, said customer trusted agent initiates a transfer of electronic money from said first money module to said second money module.
2. The system of claim 1, wherein said merchant trusted agent creates a digital signature over said remittance advice information and includes said digital signature in said commercial payment ticket signal.
3. The system of claim 2, where upon receiving said commercial payment ticket signal, said customer trusted agent verifies said digital signature prior to initiating said transfer of electronic money.
4. The system of claim 3, wherein said remittance advice information includes a list of invoices.
5. A method for electronic commercial payments utilizing a customer trusted agent, a first money module, a merchant trusted agent, and a second money module, comprising the steps of:
(a) establishing a first secure session between said customer trusted agent and said merchant trusted agent by using cryptographic means;
(b) said customer trusted agent transferring a remittance advice information signal, via said first secure session, to said merchant trusted agent;
(c) said merchant trusted agent creating a commercial payment ticket including, at least in part, data from said remittance advice information signal;
(d) said merchant trusted agent transferring a commercial payment ticket signal, via said first secure session, to said customer trusted agent which provisionally retains said ticket;
(e) establishing a second secure session between said first money module and said second money module by using cryptographic means;
(f) said first money module transferring an electronic money signal, via said second secure session, to said second money module which provisionally retains said electronic money;
(g) said first money module committing and securely informing said customer trusted agent of successful electronic money transfer;
(h) said second money module committing, whereupon said retention of said electronic money is no longer provisional, and securely informing said merchant trusted agent of successful electronic money receipt;
(i) said customer trusted agent committing, whereupon said retention of said commercial payment ticket is no longer provisional; and
(j) said merchant trusted agent committing.
6. The method of claim 5, wherein said merchant trusted agent creates a digital signature over said remittance advice information and includes said digital signature in said commercial payment ticket signal.
7. The method of claim 6 further including the step of said customer trusted agent verifying said digital signature prior to initiating said transfer of electronic money.
8. A system for securely linking electronic commercial payment to remittance advice information over a communication network, comprising:
a tamper-proof first electronic agent having a first processor;
a tamper-proof first money module associated with and that securely communicates with said first electronic agent, and having a second processor;
a tamper-proof second electronic agent that established a first secure session with said first electronic agent over said communication network by using cryptographic means, and having a third processor;
a tamper-proof second money module associated with and that securely communicates with said second electronic agent, and that establishes a second secure session with said first money module by using cryptographic means, and having a fourth
processor;
where said first processor is adapted to transfer a remittance advice information signal, via said first secure session, to said second electronic agent;
where said third processor creates a commercial payment ticket based on said remittance advice information, and transfers a commercial payment ticket signal to said first electronic agent via said first secure session;
where upon verifying said commercial payment ticket, said first processor institutes an electronic money payment from said first money module to said second money module.
9. The commercial payment system of claim 8, wherein said third processor forms a digital signature over said remittance advice information, and includes said digital signature in said commercial payment ticket signal.
10. The commercial payment system of claim 9, wherein said remittance advice information includes a list of invoices.
11. The commercial payment system of claim 10, wherein amounts associated with invoices of said list are summed and compared to a total amount included in said remittance advice information.
12. A system for securely linking electronic commercial payment to remittance advice information, comprising:
a tamper-proof first electronic transaction device including a first processor;
a tamper-proof second electronic transaction device including a second processor and that communicates with said first electronic transaction device via a secure session established by using cryptographic means;
where said first processor is adapted to transfer a remittance advice information signal including a list of invoices to said second electronic transaction device;
where said second processor digitally signs at least part of said remittance advice information and incorporates said digital signature in a commercial payment ticket;
where said second processor transfers a commercial payment ticket signal to said first electronic transaction device; and
where said first electronic transaction device transfers an electronic money signal to said second electronic transaction device, thereby completing a final payment from payor to payee without third party intermediaries.
13. The commercial payment system of claim 12, wherein said commercial payment ticket is sent to a computer-implemented accounts payable system as proof of payment.
14. The commercial payment system of claim 12, wherein said second electronic transaction device sends said remittance advice information to a computer-implemented accounts receivable system to match with outstanding invoices.
15. The commercial payment system of claim 12, wherein said first electronic transaction device verifies said digital signature prior to initiating said transfer of electronic money.
16. The commercial payment system of claim 12, wherein said first electronic transaction device checks the validity of an electronic merchant credential associated with said second electronic transaction device. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
FIELD OF THE INVENTION
The present invention relates to a system for facilitating electronic commercial payments without third party intermediaries. In particular, the system utilizes tamper-proof electronic units, referred to as "trusted agents", in combination with
money modules to create a secure transaction environment for handling commercial payments and the accompanying remittance information.
BACKGROUND OF THE INVENTION
Numerous electronic payment systems are currently being developed to accommodate the growth in electronic commerce. One method of electronic payment is described in my co-pending U.S. patent application Ser. Nos. 07/794,112 filed Nov. 15,
1991, now U.S. Pat. No. 5,453,601, 08/234,461 filed Apr. 28, 1994, now U.S. Pat. No. 5,557,518, and 08/427,287 filed Apr. 21, 1995, pending, the disclosures of which are incorporated herein by reference. These applications disclose an electronic
monetary system for implementing electronic money payments as an alternative medium of exchange to cash, checks, credit cards, debit cards, and electronic funds transfers. In particular, the described system uses money modules packaged in tamper-proof
housings to store and transfer electronic notes. Money module payments may be either real-time, off-line payments between money modules (e.g., between a money module contained within a customer's "electronic wallet" and a money module contained within a
merchant's point-of-sale terminal), or on-line payments for network services such as information retrieval and telephone calls, or for purchasing airline tickets, theater tickets, etc.
The trusted agents discussed herein are fully described in my co-pending U.S. patent application Ser. No. 08/234,461, filed Apr. 28, 1994, the disclosure of which is incorporated herein by reference. That application describes a system for
enabling the secure delivery of electronic merchandise with real-time anonymous payment or authorization-based payment. The system allows both the customer and merchant to feel secure that their interests are being served.
Commercial payments are mostly made by check, but increasingly there is a move to electronic funds transfer (EFT). A commercial payment, whether by check or EFT, carries a remittance advice that allows the payee to apply the payment to the
customer's outstanding invoice(s). It is important to match the payment with the remittance advice so that both the payer and payee can prove their case if there is a dispute.
In the case of a check payment, the remittance advice is normally printed with the check. Check payments are costly to both the payer and payee. The payer has to print, mail, and reconcile the checks, and the payee has to open the mail, rekey
the information, and wait for the check to clear. Because of these inefficiencies, intermediaries offering disbursement and lock box services are being used more and more.
There is also a movement to EFT since this will lower the cost to both payer and payee. Currently, EFT payments are less than five percent of commercial payments. One of the impediments to expanding EFT is the need for a bank to intermediate
the transaction. Processing is limited to the availability of the bank's systems, and cannot be used if the payer's bank and payee's bank do not have an EFT arrangement. The EFT system must be capable of transmitting the remittance advice with the
payment message so that payment information can be matched to the payment. EFT needs fixed relationships among banks and payers and payees. It locks the parties into relationships which are difficult to rework.
The present invention describes a system that allows commercial payments to be done securely and electronically between payer and payee without the need for intermediaries and that matches the payment and remittance advice. The transaction can
be accomplished at the convenience of the parties and provides proof of payment to the payer and payee in case of a dispute.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a secure system using trusted agents that enables electronic commercial payments from payer to payee without any intermediaries.
It is a further object of the present invention to provide a payment system that marries the payment information with the payment so that the payment is final and there is no need to match the payment information to the actual payment after the
payment is made.
It is yet a further object of the present invention to provide a payment system where the payment information is electronically signed by the payee's trusted agent so that the payee cannot repudiate that he has been paid.
In the present invention, a payment system is provided having a customer trusted agent, a first money module associated with the customer trusted agent and with which it securely communicates, a merchant trusted agent that establishes a first
cryptographically secure session with the customer trusted agent, and a second money module associated with the merchant trusted agent with which it securely communicates. The first and second money modules establish a second cryptographically secure
session. The customer trusted agent provides remittance advice information to the merchant trusted agent, and the merchant trusted agent provides a commercial payment ticket to said customer trusted agent. Upon receiving the commercial payment ticket,
the customer trusted agent initiates a transfer of electronic money from the first money module to the second money module.
The commercial payment ticket preferably contains the merchant trusted agent's digital signature over the remittance information. The customer trusted agent then verifies the digital signature prior to initiating an electronic money payment.
DESCRIPTION OF THE DRAWINGS
The invention will be described in greater detail below with reference to the attached drawings, of which:
FIG. 1 is a diagram showing the trusted agent/money module interaction.
FIGS. 2A-2B illustrate the data included in a Remittance Advice created by a customer's accounts payable system.
FIG. 3 illustrates the sections and fields of a Commercial Payment ticket.
FIG. 4 illustrates the components of a transaction device.
FIGS. 5A-5D illustrate the functional components of trusted agents.
FIG. 6 is a diagram showing the network structure for commercial money module payment.
FIG. 7A illustrates a Commit protocol.
FIG. 7B illustrates an Abort protocol.
FIGS. 8A-8D illustrate a Commercial Money Module Payment.
FIGS. 9A-9E illustrate an Establish Session protocol.
FIG. 10 illustrates a Send Message protocol.
FIG. 11 illustrates a Check Credential protocol.
FIG. 12 illustrates an Abort Transaction protocol.
FIGS. 13A-13E illustrate a Money Module Payment protocol.
FIG. 14 shows the various message encryption layers established among trusted agents and money modules.
FIGS. 15A-15E illustrate an Establish Session protocol for money modules.
FIG. 16 illustrates a Send Routed Message protocol.
FIG. 17 illustrates a Send MM/TA Message protocol.
FIG. 18 illustrates a Send TA/MM Message protocol.
FIGS. 19A-19B illustrate an Abort Transaction protocol for money modules.
FIG. 20 illustrates a Send E-Routed Message protocol.
FIGS. 21A-21B illustrate a Transfer Notes protocol.
FIG. 22 illustrates a Commit protocol for money modules.
DESCRIPTION OF THE PREFERRED EMBODIMENT
As described in my co-pending U.S. application Ser. No. 08/234,461, a trusted agent is a combination of hardware and software components. It is tamper-proof and contains secure protocols which cooperate with a money module to synchronize
secure payment to delivery. Money modules are tamper-proof devices capable of storing and transferring electronic money. The electronic money is preferably in the form of electronic: notes that are representations of currency or credit. Money modules
are also capable of establishing cryptographically secure communication sessions with other devices. The preferred embodiment of the present invention utilizes the transaction money modules described in my co-pending U.S. patent applications Ser. Nos. 07/794,112 and 08/427,287.
The trusted agents when making purchases over a network, exchange electronic merchandise and payment. In the present invention for making commercial payments, as shown in FIG. 1, the customer's trusted agent 2 (CTA) sends remittance advice
information to the merchant's trusted agent 4 (MTA). The merchant's trusted agent 4 then sends a commercial payment ticket to the customer's trusted agent 2. In return, the customer's money module 6 sends electronic money to the merchant's money module
6 via CTA 2 and MTA 4.
Remittance Advice
The customer's accounts payable system creates a remittance advice to be paid by a customer trusted device. The remittance advice is sent to the trusted device over the customer network. As shown in FIG. 2A, the remittance advice contains
information needed to consummate the transactions, for example, customer and merchant information 46, 47 such as the name and address of the customer and merchant, a customer reference number, and the network address of the merchant, the amount to be
paid 49, the date of payment 48, and the list of invoices 50 to be paid. As shown in FIG. 2B, the invoice includes sufficient information for the merchant to match to the accounts receivable system and to use in a dispute. Such invoice information may
include an invoice number 51, a purchase order number 52, a due date 53, the amount of the invoice 54, the discount amount 55, and the net amount 56.
Tickets
Referring to FIGS. 1 and 3, a ticket 8 is an electronic item created by a MTA 4 and transferred to a CTA 2 during a transaction. Tickets may be thought of as the property of the trusted agents. A customer whose CTA 2 has just received a ticket
may only use that ticket upon successful completion of the transaction.
As described in the 08/234,461 application, trusted agents support a variety of ticket types used for various purposes. However, of primary importance for the present invention are commercial payment tickets. A commercial payment ticket
identifies the particulars of a commercial payment, has the payee's digital signature over the remittance advice, and be used by the customer in a dispute scenario.
FIG. 3 shows a preferred embodiment of a ticket 8 in which the ticket is comprised of six major sections: Identifier 10, Components 12, Issuer Signature 14, Issuer Certificate 16, Transfer History 18 and Sender Signatures 20. The sections, in
turn, are comprised of various information containing fields.
The Identifier section 10 has a field 22 which holds information that identifies the merchant or authority creating the ticket. Such information, for example the merchant's authority's name, is copied from a merchant or authority credential held
by the ticket issuer. The field 22 also contains the expiration date of the merchant or authority credential. A field 24 contains the receiving trusted agent's identification number. The field 24 also contains the expiration date of the ticket
receiver's trusted agent credential. A field 26 designates the ticket type (e.g., credit or debit card ticket, commercial payment ticket, etc.).
The Components section 12 contains the basic ticket content which varies depending upon the ticket type and its specific purpose. FIG. 3 shows an example of components found in a commercial payment ticket.
A commercial payment ticket may have: a Customer Information field 36; a Merchant Information field 38; a Date of Payment field 40; an Amount Paid field 42; and a Remittance Advice Signature field 44 that is the MTA's digital signature over the
remittance advice information.
The Issuer Signature section 14 of a ticket 8 holds a digital signature, formed by the ticket creator, over the Identifier and Components sections 10, 12. Such signature is made using a private key belonging to the issuer's trusted agent. The
Issuer Certificate section 16 contains a certification by a trusted third party (hereinafter referred to as the "Trusted Agency") used in conjunction with the issuer signature to verify the authenticity of the issued ticket 8. Such certification is in
the form of a certificate belonging to the issuer's trusted agent. The general use of certificates and digital signatures is known and described, for example, in D. W. Davies and W. L. Price, Security For Computer Networks (John Wiley & Sons, 1984).
The Transfer History section 18 contains information generated when tickets are transferred between trusted agents after the initial issuing of the ticket 8 by a merchant or authority. A Receiver ID's field 28 contains the receiving trusted
agent's identification number. A Sender ID's field 30 contains the sending trusted agent's identification number. A Sender Certs field 32 contains the sending trusted agent's certificate. A Date/Times field 34 contains the date and time of transfer of
the ticket 8. As subsequent transfers are made, additional receiver and sender ID's, sender certificates, and dates and times are appended to each field, thus creating a list of transfer history information. It may be noted that the trusted agent ID
found in the Receiver field of the Identifier section, should be the same as the first ID in the Sender ID's field.
In addition, whenever a ticket 8 is transferred between trusted agents, the sender digitally signs the ticket over the five preceding ticket sections using a private key belonging to the sender's trusted agent. The Sender Signatures section 20
is then updated by appending the newly created digital signature, thus forming a list of sender signatures.
Transaction Devices
Referring to FIG. 4, a trusted agent 120 is embedded in a transaction device 122. The transaction device 122 is composed of three major components for both the merchant and the customer. There is a host processor 124, a trusted agent 120, and a
money module 6. These components are connected, for example, by a bus 126. When trusted agent 120 is a MTA 2, the device 122 is referred to as a merchant transaction device (MTD). When trusted agent 120 is a CTA 4, the device 122 is referred to as a
customer transaction device (CTD).
FIG. 4 shows the functional components of the host processor 124. The host processor provides the following functions: Communications 128, Transaction Applications 130, Human/Machine Interface 132, Date/Time 136, and a Message Manager 134.
The Communications function 128 supports communications between the transaction device 122 and the outside world. Such communications may be wired or wireless, broad or narrow band, so long as communications are compatible between the devices.
The Communications function 128 sets up the connection between two transaction devices 122, or connects a transaction device to a network for indirect connection to another transaction device or a trusted server.
Transaction Applications 130 may perform a variety of tasks. For example, a transaction application may pay invoices received from prior transactions. In general, a transaction device 122 contains all the processes to choose, buy and possibly
use electronic objects, electronic money, credentials, and other tickets 8, or the processes to sell the same.
The Human/Machine Interface function 132 provides the look and feel of the transaction device 122. It could include a keyboard, mouse, pen, voice, touch screen, icons, menus, etc. The Human/Machine Interface 132 communicates with other functions
in the trusted agent 120 and the money module 6 through the message manager 134. In some applications a Human/Machine Interface 132 may not be necessary, for example, in a fully automated merchant or customer transaction device.
The Date/Time function 136 is set by the owner of the transaction device 122 and includes date, time and time zone. The Date/Time information is fed to the embedded trusted agent 120 whenever the trusted agent is opened for use.
The Message Manager 134 routes inter-host messages (i.e., messages between transaction devices) and messages among the host processor 124, the trusted agent 120 and the money module 6.
Trusted Agents
FIG. 5A shows the functional components of a trusted agent 120. The contemplated system for open electronic commerce uses three types of trusted agent 120 which differ in certain unique Transactor functions 146 that they provide. FIG. 5B shows
the transactor functions found in a CTA 2. FIG. 5C shows the transactor functions found in a MTA 4. FIG. 5D shows the transactor functions found in an Authority Trusted Agent (ATA) which, in turn, is embedded in an Authority Transaction Device (ATD).
ATDs are associated with credential issuing authorities such as a bank.
An External Interface function 138 provides physical communication with the host processor 124 and the money module 6 of the transaction device 122 in which the trusted agent 120 is embedded. A Message Interface function 140 processes and routes
inter-agent and intra-agent messages. A Session Manager function 142 sets up and breaks down inter-agent sessions and agent to trusted server sessions. A Security Manager function. 144 maintains security information (e.g., a trusted agent certificate
and an untrusted agent list) and establishes secure communication with a counterparty trusted agent (via the host processor 124) and with the local money module 6 within the same transaction device 122. The Transactor function 146 provides the protocols
to perform a transaction. Customer, merchant and authority transactors are used for CTAs, MTAs and ATAs, respectively.
FIG. 5B shows the customer transactor functions. A Purchase function 158 exchanges payment for tickets 8 and electronic objects. A To Host function 160 provides an interface to the transaction device's host processor 124. A Present Ticket
function 164 presents tickets 8 to obtain information or services. An Acquire Credential function 166 interacts to receive a credential ticket. A Tran Log function 162 maintains a log of trusted agent transactions. Both CTAs 2 and MTAs 4 maintain a
transaction log which stores the following information: transaction type (e.g., ticket type); a pre-transaction ticket image; a post-transaction ticket image; dispute information including the date of dispute (as maintained by each trusted agent in the
dispute dialog), status, and merchant resolution (e.g., replace, refund, denied); and recertifying information (e.g., date of recertification). An Initiate Dispute function 168 presents electronic merchandise if a customer is dissatisfied.
FIG. 5C shows the merchant transactor functions. A Purchase function 170 exchanges tickets 8 and electronic objects for payment. A To Host function 172 provides an interface to the transaction device's host processor 124. A Receive Ticket
function 176 processes a received ticket 8 to provide service or information. An Acquire Credential function 177 obtains a merchant credential. A Tran Log function 174 maintains a log of trusted agent transactions. A Resolve Dispute function 178
receives tickets 8 and electronic objects to resolve a customer complaint.
FIG. 5D shows the authority transactor functions. A Create Credential function 180 constructs and delivers credential tickets to a requestor. A To Host function 182 provides an interface to the transaction device's host processor 124. A
Receive Ticket function 184 processes a received ticket 8 to provide service or information. A Revalidate Credential function 186 accepts a current credential and reissues the credential with a new expiration date. A Tran Log function 183 maintains a
log of transactions. An Acquire Credential function 185 obtains an authority credential.
Referring again to FIG. 5A, a To Money Module function 150 communicates with the money module 6 in the same transaction device 122 to provide payment. A | | |
