WO2002014983A2

WO2002014983A2 - System and method for conducting a transaction

Info

Publication number: WO2002014983A2
Application number: PCT/US2001/025656
Authority: WO
Inventors: Brian Puckett; Sandeep Dhingra
Original assignee: Information Projects Group, Inc.
Priority date: 2000-08-15
Filing date: 2001-08-15
Publication date: 2002-02-21
Also published as: AU2001283405A1; WO2002014983A3

Abstract

The invention is a system and method for processing a transaction, the system having a database (10), a first user module (30), and a second user module (40). Messages are exchanged between the first (30) and second (40) user modules and are stored in the database (10) in a sequential message thread. The message thread may be accessed and appended by either the first (30) or second (40) user modules. Each user module allows a respective user to check the status of messages, receive notice of a new message, reply to messages, or negotiate the transaction within the message thread. The message thread may be utilized to define the transaction.

Description

System And Method for Conducting a Transaction

Field of the Invention

This invention relates to a method and system for initiating a transaction as well as negotiating, modifying, and memorializing the details of such a transaction.

Background

With the advent of e-commerce there is a continuing need to streamline electronic interactions in arriving at a transaction between two parties. For example, the Internet is utilized in conducting business to consumer or business to business transactions in which negotiations are necessary in order to arrive at a final transaction. One example of such a transaction is the sale of goods. Merchants may wish to utilize any variety of sale formats including direct sale, auction, or a negotiated individualized transaction. The use of the Internet in such transactions presents special problems in that there is no personal contact between the parties and therefore a system of communication and tracking between the parties during the transaction becomes necessary. These transactions which require such a system are not limited to the sale of goods but can include dispute resolution, product and project management, customer support and management, and many other applications. U.S. Patent No. 5, 668,953 discloses a method and apparatus for handling a complaint utilizing a network connected to the system and a plurality of terminals also connected to the system. The system allows for a user at a terminal to post a complaint about a given subject. The subject may be a product, services, a vendor, an individual, or an organization. Before posting a complaint, the user, also known as the complainant, may search a database for the subject and view other complaints posted for the same subject. Each post is stored in a public area accessible and searchable by any user with a terminal. In response to the complaint, the vendor may choose to either negotiate in a private area having an e-mail address, which is known only to the complainant and a vendor or may post a response in the public area accessible by all users. Once the complaint is resolved, the complainant may remove the complaint posted in the public area.

U.S. Patent No. 6,055,519 discloses a computer implemented system for negotiation and tracking of the sale of goods. A negotiation engine operates to store data representing the current state of the negotiation between a seller and the buyer. The negotiation engine stores the data within a framework for representing aspects of the negotiation between the seller and the buyer. The framework includes a request object, a promise object and an acceptance object containing a current description of a contract. The negotiation engine allows the user to monitor the current state of the negotiation over a range of prices, a range of dates, ranges of quantities of a set of goods, and a range of configurations of the goods in a set.

A problem exists in that currently available systems along with the patent references discussed here do not allow sufficient flexibility between the parties in recording the negotiations that ultimately define the transaction. For example, in U.S. Patent No. 5,668,953, only the complainant has the ability to remove a posted complaint. Although a message is removed, it is desirable for either party in the negotiation to have access to a message thread including all messages exchanged between the parties during the transaction. Each party desires access to the entire message thread including messages that have been deleted by the other party in order to better memorialize the transaction. In addition, a problem exists in that such systems have not been applied to a marketplace where a merchant can opt to present their goods for sale in a variety of sale formats and then negotiate with potential buyers while memorializing all aspects of the negotiation.

Summary

The present invention addresses the above mentioned problems by providing a system for processing a transaction, the system having a database, a first user module, and a second user module. The database, first user module, and second user module are all linked to a network. Messages are exchanged between the first and second user modules and are stored in the database in a sequential message thread. The message thread may be accessed and appended by either the first or second user modules. Each user module allows a respective user to check the status of messages, receive notice of a new message, reply to messages, or negotiate the transaction within the message thread. The message thread may be utilized to define the transaction.

Brief Description of the Drawings

The invention will now be described by way of example with reference to the accompanying figures of which:

Figure 1 is a block diagram of the transaction system.

Figure 2 is a flow diagram of the merchant module of Figure 1. Figure 3 is a flow diagram of the customer module of Figure 1.

Figure 4 is a flow diagram of the messaging system of the transaction system.

Figure 5 is a flow diagram of a product delivery and acceptance portion of the transaction system.

Figure 6 is a sample sign up form accessible by the merchant module of Figure 1.

Figure 7 is a sample sign up form accessible by the customer module of Figure 1. Figure 8 is a flow diagram of an e-mail/agent module.

Detailed Description of the Preferred Embodiment

The invention will first be described generally with reference to Figure 1. In describing the invention, like numerals will be used to describe like elements throughout. The system 5 is designed for facilitating a transaction and contains a database 10 which tracks information concerning the transaction. The database 10 may be housed within a variety of hardware, which will be apparent to those skilled in the art. For example, the database may reside on a server, a personal computer, or any other suitable computer. The computer hardware containing the database 10 is connected to a network 20. This network may comprise any suitable network such as a local area network, a wide area network, a wireless network or the Internet. Those skilled in the art will appreciate that the network utilized may vary and may include any network for communicating data between hardware located either at a common location or at remote locations.

A customer module 30 is connected to the network for communicating with the database 10. The customer module 30, similar to the database may be housed within a variety of hardware such as a personal computer, a terminal, a cell phone, a personal digital assistant, or other suitable computing device. An alternative would allow for a voice recognition system to receive commands executable by the customer module or in the alternative simply stored in digital format and transmitted to the merchant module and played back by the merchant. The merchant module will be described in greater detail below. The customer module 30 contains a user interface for allowing the user to access data in the database 10 and to read from or write to the database 10. The customer module 30 also provides notification to the customer that information is available concerning a given transaction.

The customer module 30 provides a user interface in which the customer may maintain several credit cards on file within the database 10, order goods and select which credit card to charge for each of the goods, or enter transactions with merchants. Among the actions a customer may take within the module are that they may initiate an online conversation with the merchant, receive notification of the merchant's responses, read responses from the merchant in a secure manner, respond to the merchant's responses, review the status of merchant messages, review the status of messages sent to the merchant, review the message thread or history, delete messages from view, agree to consummate a transaction or purchase goods, modify orders prior to processing, review status of order (pending, charged, refused, returned, shipped and disputed) or negotiate price, receive confirmation of a purchase, review notification of shipment, confirm delivery, accept or dispute a delivery, review past purchases, or enter into multiple negotiations with multiple merchants simultaneously. The user interface of the customer module 30 may be stand alone software or may work in conjunction with other software such as e-mail, instant messaging, SMS text based messaging applications to perform some of the functions. Each of these function will be described in greater detail below. Likewise, the merchant module 40 may be housed within a variety of hardware such as a personal computer, a terminal, a cell phone, a personal digital assistant, or other suitable computing device. An alternative would allow for a voice recognition system to receive commands executable by the merchant module or in the alternative simply stored in digital format and transmitted to the customer module and played back by the customer. The merchant module 40 has a user interface for allowing the user to access data in the database 10 and to read from or write to the database 10. Similarly, the merchant module 40 has the capability to provide notification to the merchant that information is available concerning a given transaction. These functions may be performed by the merchant module 40 using stand alone software or alternatively may be performed in conjunction with other software such as e-mail, instant messages and SMS text based messaging applications. Each of the modules are preferably written in a combination of CGI, Perl, JAVA and standard generalized markup language (SGML) or hypertext markup language (HTML). Those skilled in the art will appreciate that this software can be written in other languages as a matter of design choice.

The merchant module 40 provides a user interface wherein the merchant may elect to list products in various sale formats. The merchant module 40 allows the merchant to respond to messages sent from their product page, accept orders from customers, process customer orders, or review message history regarding transaction. Contained within the merchant module 40 are administrative features which allow the merchant to list and update products in the database, integrate messaging features with products listed in an external or internal database, obtain message status for any message within a thread, review status of messages sent to customers, reply to messages, receive pending orders from customers which have not yet been processed and accept orders from customers and process those orders. Notification of shipment is also a function of the merchant module 40 along with selection of shipping method and notification of customer order acceptance. In addition to these notifications, the system 5 may provide notice and the message thread through a different user interface such as e-mail, instant messaging or SMS text based messaging applications.

The database 10 tracks all transactions between merchants and customers. It's capabilities include enrolling merchants and customers, assigning unique identifications to messages regarding a specific product, allowing identification of multiple designated mailbox accounts for processing incoming and outgoing messages, inserting date and time stamp on messages, allowing for unlimited replies or exchanges between customers and merchants, tracking replies by order and date in a thread, allowing for purging of messages by the merchant and customer, purging the display of deleted messages while retaining the messages for transactional analysis, tracking the status of messages as either read, deleted, or replied to and allowing users to view message status as well as automatically alerting merchants to ship products at a specified time (ie. after 24 hours of processing an order) and automatically alerting customers at a specified time(i.e. after five (5) days) from the order date to dispute an order if delivery and acceptance does not occur in another 48 hours.

Referring now to the Figures 2-7 , operation of the system 5 will be describing greater detail. It should be appreciated by those skilled in the art that while the invention will be described with reference to. a preferred embodiment wherein the system 5 is utilized between a merchant and a customer for the sale of goods, the system 5 is generic and has other applications which will also be described below.

Referring first Figure 2, in the preferred embodiment, a merchant administration menu 102 is a software user interface which is a part of the merchant module 40. The merchant administration menu is only available to a merchant who first registers at 104 or installs the software on their own computer system and executes the set-up procedures which integrates the invention with the merchant's database, network and email application.. In order to register, a merchant completes the sign up form shown in Figure 6. Although this sign up form requests general information from the merchant including place of business, shipping addresses, delivery options and a description of the business, it should be understood that other information may be gathered using a similar form. Returning now to Figure 2, utilizing the merchant administration menu 102 the merchant has the option to list products at 106 or use templates to insert product details or other data from external or internal database. In the preferred embodiment, the merchant may list products for sale in a variety of sale formats. For example, the merchant may elect a direct sale wherein the product and price are dictated by the merchant. The merchant may also select to use an or best offer (OBO) format in which the product is listed by the merchant and price or other terms are negotiated as will be described below. The merchant administration menu 102 also allows the merchant to review message status at 108, review order status at 110 process credit card orders at 112 and entering messaging system at 114. The merchant may s specify one or more email addresses where messages received and processed by the designated mailbox are sent. In this case data or messages received from a customer are sent by the system 5 from the database 10 to the merchant's e-mail address. The data is assigned a unique ED which identifies it with a transaction.

Once the merchant has listed products at 106 or installed the software on their own computer system, flow of the system shifts to Figure 3 wherein a customer utilizing the database 10 menu 204 may search for products offered by the merchant. The customer administration menu 202 is a software user interface which is part of the customer module 30. A customer may optionally use the customer administration menu 202 to search product offerings by multiple merchants at 204. Product offerings are also searchable and/or accessible directly through the database 10 or by accessing web pages on the merchants computer system. Any registered or unregistered user, including the customer, may access the products without using the customer administration menu 202. If the merchant has selected a direct sale format, the customer may elect to make a purchase. The customer module 30 then checks to see if a credit card is on file to make the purchase at 206. If there is no customer credit card on file, flow proceeds to 208 where the customer is requested to register at least one and possibly several credit cards for this and future purchases. Utilizing the customer administration menu 202, the customer is directed to complete a sign up form as shown in Figure 7 to gather the necessary credit card information for the transaction. It should be understood that while the form of Figure 7 indicates entry for a single credit card, the customer may enter several credit card numbers and then select between these credit cards when making future purchases. Or the customer may choose to enter their credit card details and submit them to the merchant for the purchase and then choose to save the credit card details by registered at 208. Once a customer credit card is on file, flow proceeds to 210 where the customer is requested to select one of their credit cards on file for the purchase. The customer may also elect to receive messages from the merchant through an e-mail interface instead of through the customer module 30. In this case the customer could receive and send messages from/to the merchant using standard e-mail software while the database 10 continually tracks and records the message thread as described herein. Upon selection, flow proceeds to 212 where the order request is transmitted to the database 10 for merchant review.

Utilizing the customer administration menu 202, the customer may also view pending orders at 214. If the order is not yet filled by the merchant, the customer is given the opportunity to modify the order at 216. Such modification is stored in the database 10 for merchant review at 212. The customer administration menu 202 also allows the customer to review past purchases at 218.

Returning now to the top of Figure 3, if upon finding a product at 204, the merchant has elected the OBO sale format, the customer may utilize the customer administration menu 202 to send a message to the merchant at 220. Such a message may include an offer, questions regarding the product offered, or an invitation to negotiate terms. This messaging system will now be describing greater detail with reference to Figure 4. Beginning at 302, the customer sends a message which is stored in the database 10. At 304, the merchant receives notice that a message has been sent and utilizes the merchant administration menu 102 to access and read the message sent by the customer, or has the customer message processed by the designated mailbox sent to an email address The notice may be provided by any acceptable means. For example, utilizing the merchant administration menu 102, a status of all messages may be checked. Alternatively, an e-mail message may be generated by the system 5 and sent to the merchant indicating receipt of the message sent by the customer. The e-mail message will contain a link directly to the received message in the database 10. Alternatively, notification may be provided via facsimile, through a wireless device such as a personal data assistant or cellular telephone, or through any other acceptable means. At 306, the merchant decides whether to accept or reject the customer's offer. The customer's message may be alternatively viewed by the merchant using the merchant's e-mail software. In this scenario the system 5 assigns a unique ID to the customer's message thus associating it in the database 10 with a transaction. The message is transmitted by the system 5 to a selected merchant e-mail address. The database 10 tracks the message thread and all other information regarding message status as described above. If the customer's offer is rejected by the merchant, a counter offer or return message may be sent to the database 10 at 308. Utilizing the customer administration menu 202, the customer is notified in a similar manner that a counter offer or return message has been received and has the option to link to or read the counter offer or return message at 310. ' Flow then returns to 302 where the customer may reply and continue to build a message thread within the database 10. The customer may alternatively receive the merchant's messages at a selected customer e-mail address. The messages are similarly transmitted by the system 5 from the database 10 to the customer e-mail address. The database 10 tracks the message thread and all other information regarding message status as described above. If the merchant elects to accept the customer's offer, at 312, an acceptance message may be sent to the customer utilizing the merchant administration menu 102 or the e-mail interface described above. Upon receipt of the acceptance, the customer, utilizing the customer administration menu 202 or the e-mail interface may place the order at 314.

In the scenario where the merchant and customer elect to use e-mail software for the interface to the system 5, a set up procedure is required wherein the merchant installs software in addition to the merchant module 40. This software adds a Java agent to the merchant adniinistration menu functions. The merchant assigns a central mailbox for receiving messages from both the customer and merchant. The merchant also installs settings for the JAVA agent to process mail in the central mailbox. These settings include items such as instructions for the JAVA agent to direct mail from the customer received in the central mailbox to the merchant at a designated merchant mailbox or a designated plurality of merchant mailboxes. Additionally instructions for merchant messages to be sent from the central mailbox to the customer mailboxes are included. Additionally, settings are made in the JAVA agent for the database 10. These settings include tables for matching selected message threads with data in the database 10. Mail templates are also created having data from the database 10 inserted at desired locations in the templates. Buttons are set which may appear in e-mail messages. These buttons may be tagged to various merchant products or functions.

Operation of the e-mail agent will be described in greater detail with reference now to Figure 8. The customer first uses a standard a browser at step 450 to view a merchants webpage having product offerings at step 452. At this step, the customer may elect to utilize an e-mail interface for further communications with the merchant by entering an e-mail address where they elect to receive messages from the merchant. This information is transmitted to the merchant mail system at step 454. Recall that this merchant mailbox was set up by the merchant to have a central mailbox for receiving messages from the customer. The java agent processes messages in the designated mailbox according to the settings the merchant has selected during the set up process at step 456. The JANA agent assigns an identifier according to the merchant settings and stores message threads in the merchant database at step 460. In addition, the JANA agent sends the customer's message from the central mailbox at 454 to a merchant e-mail address assigned during set up for viewing by the merchant. It should be understood that the JANA agent may send the messages from the central mailbox either through e-mail to the merchant or to a phone message, a fax, or beeper or some other communication device in the merchants possession. If the merchant elects to respond, a reply is sent from the merchant's communication device which received the message from the JANA agent back to the central mailbox in the mail system at 454. The JANA agent then appends appropriate information such as price updates or other updated information from the merchant database and the appropriate identifier for the message thread and also stores the reply from the merchant into the merchant database at 460. The JANA agent also sends the message from the central mailbox at 454 back to the customer at 450 for viewing. This process may be repeated until a negotiation is completed and flow proceeds to order processing. Order processing proceeds with credit card processing as was described with reference to Figure 3 beginning at step 206. Once the credit card is processed, flow continues to delivery acceptance of goods which will now be described in greater detail with reference to Figure 5. Beginning at 402, if the credit card processing is successful, a notification is sent to the customer at 404. The merchant then ships the product at 406 unless an order modification is received before the order has been processed as described with reference to Figure 3 at 216. Once shipping occurs, a shipping notification is sent to the customer at 408. If the customer receives the product without defects as indicated at 410 and 412, the customer is returned to the customer administration menu 202 and may continue to find other products, check orders, check the status of messages or conduct any the other functions previously described from the customer administration menu 202. If the customer receives the product and takes exception to it for any reason, they may dispute the charge at 414 utilizing the customer administration menu 202. In the preferred embodiment, this dispute messaging between the merchant and customer will be attached to the order and contain the last message identification number of the message thread that was previously stored in the database 10. The dispute messaging may optionally be included in or appended to the original message thread. In the event that the credit card processing is unsuccessful a rejection message is sent to the customer at 416 and the customer is returned to the customer administration menu 202. The merchant may also return a customer order that is incorrect at 416 prior to processing. The customer is returned to the customer administration menu at 202 and the order status is marked return. The customer may review the order, read a message attached by the merchant and modify the order. In an alternative embodiment, an administration module may be provided. This module would receive notice of a customer message or dispute. An administrator or group of administrators receiving the notice, could monitor the dispute, or message either the customer or the merchant during the dispute. The administrator may effect a customer refund. The database 10 tracks the resolution and the administrator who take action in such a dispute.

Although the invention has been described here with respect to the preferred embodiment of facilitating a merchant customer transaction, other uses of the system 5 are anticipated. For example, the system 5 can be used for customer relationship management. In providing technical support, technical support personnel of the merchant, may publish a list of employee names, department titles, or a list of frequently asked questions in the database 10. A registered customer can then access the list and begin the messaging thread by composing a comment or question which would then be routed electronically through the database to the posting author. The two parties would then be able to carry on a controlled, accountable and private conversation which is facilitated by the messaging system described above. The outcome may be as simple as having the customer's question answered or may involve additional negotiations such as a rebate, coupon, or some other action on the part of the recipient. A similar use would be in human resource management. For example, human resource personnel, departments and responsibilities could be listed in the database for all employees to see. An employee could access a particular person or department and enter into a secure, accountable and private conversation utilizing the messaging system described above.

Project management is another use of the system 5. A list of tasks, equipment used, or project milestones may be generated by a project manager and stored in the database. The project participants utilize the system 5 to carry on an ongoing, secure, accountable dialogue with the project manager. The outcome of the dialogue may be independent of the dialogue itself. For example a project may be modified, or responsibilities of a project participants changed, based on the dialogue.

The system 5 may also be used as the training and education tool. A teacher could post questions, milestones, or assignments and then conduct private, accountable individualized dialogue with students or colleagues. A student may respond to a posted question and the teacher could respond to the message with feedback or clarification. This allows for private, self paced and accountable education between teachers and individual students.

Counseling and therapy applications are also anticipated uses of the system 5. A counselor or therapist could post one or more questions or topic areas for discussion with the patient. The patient recipient may respond by providing additional information or answers to the questions. The counselor or therapist may respond with additional guidance or direction based upon the content of the recipient's message received. The message thread between the counselor and the patient is secure so that only the counselor and patient can view the thread.

Arbitration and dispute resolution applications would include a dialogue between parties which is secure and accountable. For example, the message thread of the system 5 is useful in deterrnining the outcome of the arbitration or current status of any dispute. One party or an arbitrator may post the series of facts that the other party or parties respond to in a secure accountable way. The outcome of a message, or series of messages may be the acceptance a rejection of the fact by one or both parties.

An advantage of the invention is that allows for the standardization of a body of knowledge such as: a list of products, course work, project milestones, or a list of employees names and posted electronically with inquiries coming from multiple sources and channeled to specific recipients. The invention provides the convenience of allowing senders and recipients to work independent of each other as well as providing multiple notification methods when new data is available for review. The invention also encompasses a high degree of privacy and accountability in having all dialogue conducted in a secure manner viewable only by the parties to the transaction. An additional advantage of the invention is that utilizing a user interface a participant can delete messages from a status display but the integrity of the dialogue remains intact because the entire message thread is stored in the database 10. Each party may view the status of messages at any time. An additional advantage of the present invention is that a message exchange or negotiation between users is tracked and memorialized for defining a transaction. The system also allows for product offerings to be stored as well as customer information related to the sale while providing order processing at the trailing end of the negotiation.

Claims

What is claimed is:

1. A transaction processing system comprising: a database being linked to a network; a first module being linked to the network and having a user interface wherein a first user may post offerings, receive message notices, reply to a message, and delete the message, the messages and replies being stored in the form of a message thread within the database; and, a second module being linked to the network and having a second user interface wherein a second user may search the offerings, select from the posted offerings, send the message regarding the selected offering, receive notice of a reply, review replies from the first user regarding the selected offering, the message and reply being stored in the same message thread within the database.

2. The transaction processing system of claim 1 wherein the message notices to the first user include a link to the received message.

3. The transaction processing system of claim 1 wherein the notice of a reply to the second user includes a link to the received reply.

4. The transaction processing system of claim 1 wherein the first user may delete messages utilizing the first module, the deleted messages being tagged as deleted and maintained within the message thread.

5. The transaction processing system of claim 1 wherein the first module may be utilized to display a status of each message in the message thread.

6. The transaction processing system of claim 5 wherein the status is selected from one of the group of unread, read, deleted, or replied to.

7. The transaction processing system of claim 1 wherein the second module may be utilized to display a status of each message in the message thread.

8. The transaction processing system of claim 7 wherein the status is selected from one of the group of unread, read, deleted, or replied to.

9. The transaction processing system of claim 1 wherein the first module allows the first user to post offerings in a plurality of formats.

10. The transaction processing system of claim 9 wherein the format is a negotiation format allowing for repeated exchange of the messages between the first and second users.

11. The transaction processing system of claim 10 wherein the format is a direct sale format.

12. The transaction processing system of claim 1 further comprising a credit card processing module.

13. The transaction processing system of claim 1 wherein the first module allows the first user to send a notice of return to the second user alerting the second user to an inaccuracy in an order prior to processing.

14. The transaction processing system of claim 1 wherein the first module allows the first user to send a notice of shipment to the second user, the notice being stored in a message thread.

15. The transaction processing system of claim 1 wherein the database alerts the first user after period of time to ship goods associated with a transaction defined by a message thread including the messages and replies.

16. The transaction processing system of claim 15 wherein the database alerts the second user to a pending release of funds to the first user based upon the second user's receipt and acceptance of goods associated with the transaction.

17. The transaction processing system of claim 1 wherein the second module further comprises a dispute function for rejecting a shipped offering, the dispute function generating a dispute notice which is stored in the message thread.

18. The transaction processing system of claim 1 further comprising an administration module being linked to the network, the administration module having the capability of monitoring message activity between the first and second users.

19. The transaction processing system of claim 18 wherein the administration module allows an administrator to message the first and second users..

20. A method of conducting electronic transaction comprising the steps of: registration of a first user utilizing a first software module being connected to a network; storing the first user's registration information in a database being connected to the network; posting offerings utilizing the first software module, the offerings being stored in the database; selecting a negotiating format for the offerings; searching the offerings by a second user utilizing a second software module being connected to the network;

selecting among the offerings utilizing the second software module; sending a first message to the first user creating a message thread in the database utilizing the second software module; receiving notice of the message including a link to the message and reviewing the message utilizing the first software module; t replying to the message utilizing the first software module, the reply being added to the message thread stored in the database; and, receiving notice of the reply including a link to the reply and reviewing the reply utilizing the second software module.

21. A transaction processing system comprising: a first user interface means for performing the functions of registering a first user, posting user offerings, reviewing received messages regarding the offerings, and responding to the received messages; a second user interface means for performing the functions of locating posted offerings, sending the messages regarding the offerings, receiving message replies from the first user interface means and responding to the message replies; and, a database means for storing each of functions of the first and second user interface means and for creating a sequential message thread which defines the transaction.

22. The transaction processing system of claim 21 wherein the first user interface means, the second user interface means, and the database means are connected to a network.

23. The transaction processing system of claim 22 wherein the first user interface means further comprises a message status display wherein the first user may check the status of each of the received messages and responses and may link to each message and response.

24. The transaction processing system of claim 22 wherein the second user interface means further comprises a message status display wherein the second user may check the status of the received messages and replies and may link to each message and reply.

25. The transaction processing system of claim 23 wherein the first user interface means further comprises the function of receiving a message notification having a link to the received message.

26. The transaction processing system of claim 24 wherein the second user interface means further comprises the function of receiving a message notification having a link to the received message.

27. The transaction processing system of claim 25 wherein the first user interface means also performs the functions of allowing the first user to delete messages on a message status display.

28. The transaction processing system of claim 27 wherein the database means stores the entire message thread regardless of whether the first user has deleted messages on the message status display.

29. The transaction processing system of claim 26 wherein the second user interface means also performs the function of allowing the second user to delete messages on a message status display.

30. The transaction processing system of claim 29 wherein the database means stores the entire message thread regardless of whether the second user has deleted messages on the message status display.

31. The transaction processing system of claim 24 wherein the first user interface means further comprises the function of a credit card processing module for automatically processing credit card transaction.

32. The transaction processing system of claim 31 wherein the first user interface means further comprises the function of sending an order acceptance to the second user interface means after automatically processing the credit card transaction.

33. The transaction processing system of claim 32 wherein the second user interface means further comprises the function of checking the status of pending orders.

34. The transaction processing system of claim 32 wherein the second user interface means further comprises the function of modifying a pending order.

35. The transaction processing system of claim 21 further comprising an administration user interface means for monitoring a message thread containing messages exchanged between the first and second user and stored in the database means.

36. The transaction processing system of claim 35 wherein the aά mnistration user interface allows an administrator to message the first and second users.

37. A fransaction processing system comprising: a first user interface being linked to a network for reviewing received messages regarding a matter, and responding to the received messages; a second user interface being linked to the network for sending the messages regarding the matter, receiving message replies from the first user interface and responding to the message replies; and, a database being linked to the network for storing a sequential message thread which defines a transaction and comprises the messages and replies.

38. The transaction processing system of claim 37 wherein the first user interface further comprises a message status display wherein the first user may check the status of each of the received messages and responses and may link to each message and response.

39. The transaction processing system of claim 37 wherein the second user interface further comprises a message status display wherein the second user may check the status of the received messages and replies and may link to each message and reply.

40. The transaction processing system of claim 38 wherein the first user interface further comprises the function of receiving a message notification having a link to the received message.

41. The transaction processing system of claim 39 wherein the second user interface further comprises the function of receiving a message notification having a link to the received message.

42. The transaction processing system of claim 38 wherein the first user interface also performs the functions of allowing the first user to delete messages on a message status display.

43. The transaction processing system of claim 42 wherein the database stores the entire message thread regardless of whether the first user has deleted messages on the message status display.

44. The transaction processing system of claim 39 wherein the second user interface also performs the function of allowing the second user to delete messages on a message status display.

45. The transaction processing system of claim 44 wherein the database stores the entire message thread regardless of whether the second user has deleted messages on the message status display.

46. The transaction processing system of claim 38 wherein the first user interface further comprises the function of a credit card processing module for automatically processing credit card transaction.

47. The transaction processing system of claim 46 wherein the first user interface further comprises the function of sending an order acceptance to the second user interface after automatically processing the credit card transaction.

48. The transaction processing system of claim 39 wherein the second user interface further comprises the function of checking the status of pending orders.

49. The transaction processing system of claim 48 wherein the second user interface further comprises the function of modifying a pending order.

50. The transaction processing system of claim 37 further comprising an administration user interface for monitoring a message thread containing messages exchanged between the first and second user and stored in the database.

51. The transaction processing system of claim 50 wherein the administration user interface allows an administrator to message the first and second users.

52. The transaction processing system of claim 37 wherein the first user interface further comprises e-mail software allowing the first user to view and check the status of each of the received messages and responses.

53. The transaction processing system of claim 37 wherein the second user interface further comprises e-mail software allowing the second user to view and check the status of each of the received messages and responses.

54.. The transaction processing system of claim 52 wherein the first user interface also performs the functions of allowing the first user to delete messages on a message status display.

55. The transaction processing system of claim 54 wherein the database stores the entire message thread regardless of whether the first user has deleted messages on the message status display.

56. The transaction processing system of claim 53 wherein the second user interface also performs the function of allowing the second user to delete messages on a message status display.

57. The transaction processing system of claim 56 wherein the database stores the entire message thread regardless of whether the second user has deleted messages on the message status display.

58. The transaction processing system of claim 52 wherein the first user interface further comprises the function of a credit card processing module for automatically processing credit card transaction.

59. The transaction processing system of claim 58 wherein the first user interface further comprises the function of sending an order acceptance to the second user interface after automatically processing the credit card transaction.

60. The transaction processing system of claim 52 wherein the first user interface further comprises the function of a agent for managing a central mailbox.

61. The transaction processing system of claim 60 wherein the agent manages message flow into and out of the central mailbox.

62. The transaction processing system of claim 61 wherein messages are received in the central mailbox from both the customer and the merchant.

63. The transaction processing system of claim 62 wherein the agent directs messages for the merchant to a merchant communication device and directs messages for the customer to a customer e-mail address.

64. The transaction processing system of claim 63 wherein the agent simultaneously stores messages in the database including messages sent to both the merchant and the customer.

65. The transaction processing system of claim 64 wherein the agent further comprises the function of appending data from the database into templates to modify or initiate messages to the merchant and the customer.

66. The transaction processing system of claim 65 wherein the agent further comprises the function of directing a customer message from the central mailbox to multiple mailboxes of the merchant.

67. The transaction processing system of claim 64 wherein the agent updates data while storing messages in the database.