WO1999050771A1

WO1999050771A1 - A method and apparatus for creating an electronic commerce system

Info

Publication number: WO1999050771A1
Application number: PCT/GB1998/003852
Authority: WO
Inventors: Victor S. Moore; Glen R. Walters
Original assignee: International Business Machines Corporation; Ibm United Kingdom Limited
Priority date: 1998-03-31
Filing date: 1998-12-21
Publication date: 1999-10-07
Also published as: TW381239B

Abstract

A method and system for transacting commerce in a distributed communications system over the Internet comprises the reception and transmission of shopping requests, product requests, and payment information between distributed Web sites. The distributed communications system comprises: a server system; and a customer system which is coupled to the server system. The server system comprises a virtual cashier for receiving product requests and payment information. The virtual cashier responds to a first network address. The server system also comprises a virtual store for shopping. The virtual store responds to a second network address. The customer system allows a customer to make shopping requests. Java applets and servlets running at distinct network addresses provide much of the functionality. The system allows greater efficiencies and lower costs for World Wide Web ('WWW') merchants and for Web site hosting services.

Description

1

A METHOD AND APPARATUS FOR CREATING AN ELECTRONIC COMMERCE SYSTEM

The present invention relates generally to computer networks and more particularly to methods and apparatus for providing a scaleable distπbuted Internet commerce system

The World-Wide- Web ("Web") has become immensely popular largely because of the ease of finding information and the user-fπendhness of today's browsers A feature known as hypertext allows a user to access information from one Web page to another by simply pointing (using a pointing device such as a mouse) at the hypertext and clicking Another feature that makes the Web attractive is having the ability to process the information (or content) in remote Web pages without the requirement of having a specialised application program for each kind of content accessed Thus, the same content is viewed across different platforms Browser technology has evolved to enable the running of applications that manipulate this content across platforms

The Web relies on an application protocol called HTML (Hyper-Text Mark Up Language), which is an interpretative scripting language, for rendering text, graphics, images, audio, real-time video, and other types of content on a Web compliant browser HTML is independent of client operating systems Therefore, HTML renders the same content across a wide vaπety of software and hardware operating platforms The software platforms include without limitation Windows 3 1, Windows NT, Apple's Copeland and Macintosh, and IBM's AIX and OS/2, and HP Unix Popular compliant Web-Browsers include without limitation Microsoft's Internet Explorer, Netscape Navigator, Lynx, and Mosaic HTML interprets links to files, images, sound clips, and other types of content through the use of hypertext links Upon user invocation of a hypertext link to a Web page, the browser initiates a network request to receive the desired Web page 2

The use of electronic commerce on the Web is growing A variety of traditional larger retailers and larger mail order catalogue compames have been offering their goods for sale electronically over the Web Everything from the actual shopping to the determination of available inventory and the acceptance of payment is accomplished electronically The merchant's Web site or Web storefront handles all shopping, selection, and acceptance of payment transactions automatically Unlike traditional storefronts, these automatic capabilities enable a merchant to have its goods offered for sale twenty four hours a day, every day of the year (for an example of a traditional catalogue company with its goods available via the Web refer to L L BEAN of Freeport, Maine, whose URL is www llbean com) But the ability to host retail merchandise on the Web is not without difficulties

It is difficult to integrate the major functions of electronic Web commerce Three functions, in particular, are typically integrated in a retail Web site The first function is the virtual presentation, using text, graphics, or otherwise, of a merchant's products to customers

This is sometimes called the "electronic storefront" or "Web storefront," or in the case of a catalogue merchant, the "electronic catalogue " The second function is the maintenance of inventory, stock, pπcing, and availability of each product, as well as tracking sales and revenues The third function is performing the electronic transactions for payment in a secure environment, where the collection of a customer' s payment information, such as a credit card, is performed Typically, most electronic commerce sites integrate all three of these functions at one physical site

Companies desinng to do business over the Web face many problems A first problem is the expense and complexity of setting up the necessary elements of an electronic commerce server This difficulty includes (1) hosting of the Web storefront, (2) maintenance of an inventory and financial database, and (3) the roll out of a secured Transaction Server The initial up-front cost is a significant barrier for most small businesses desiπng to gain a presence on the Web Therefore, a need exists to lower or even to eliminate the high-cost 3 barrier typically associated with setting up electronic commerce on the Web. The cost not only involves software design and implementation, and setting up the necessary equipment, but the initial hardware investment capable of running all three elements of an electronic commerce server for one business.

A second problem is meeting the requirement that the Web storefront or Web catalogue be constantly up-to-date. Many businesses pay dedicated personnel to update, create, and modify their Web sites. The cost of the service to maintain a merchant's Web site can be significant. A need exists to provide a merchant with the capability of easily creating, modifying, and updating its own Web storefront.

A third problem is meeting the requirement that the Web storefront inventory and financial database must be maintained and updated. Sales, advertised specials, and other changes in pricing need to be reflected in the inventory database. For many smaller businesses the requirement to keep inventory and financial records electronically, not to mention the requirement to be electronically connected to their Web storefront, is too complex and too costly. Many smaller businesses use simple written ledgers or standalone software applications to control their inventories and finances. For merchants desiring to sell goods and services over the Internet, a need exists to be able to have their inventory and finances maintained in a scaleable fashion. In this way, as the business grows, the merchant can migrate from a pencil and ledger, through a stand-alone electronic database, up to a fully connected and automated database.

A fourth problem is meeting the requirement to automatically accept secure, electronic forms of payments. The need to have encryption and clearance software, secure server hardware, and secure firewalls makes this requirement expensive. For merchants desiring to set up Web storefronts, a need exists to be able to scale electronic payments to meet their needs. 4

A fifth problem is achieving the ability to advertise to news groups and other Internet text-based users, as opposed to graphics-based users Popular text-only viewers such as Lynx do not have graphical HTML capabilities A need thus exists for merchants to be able to advertise anywhere and to process payment information even in text-only based electronic commerce

As mentioned earlier, one of the concerns for a merchant desiring to do electronic commerce is the Web site development In the case of a large company that wants to have all three functions integrated into one Web site, these costs can easily exceed SI million In addition, even though the programming will usually not be done by the merchant, the merchant will have to devote substantial amounts of time to the layout design and to the review These costs, in time and money, are significant Smaller companies may opt to create their own Web sites This undertaking can be quite difficult, however, for the merchant who is not a sophisticated computer user While it is relatively easy to create a Web site, without competent guidance the site may be poorly designed and therefore of little economic value There is, therefore, a need for a development tool which simplifies the design, creation, and maintenance of a Web site for merchants.

Briefly, in accordance with one aspect of the invention, a method for transacting business in a distributed communications system comprises, receiving a shopping request at a virtual store from a customer system; and sending a product request to a virtual cashier from the virtual store The distributed communications system comprises a server system, and a customer system which is coupled to the server system The server system comprises the virtual cashier for receiving product requests and payment information. The virtual cashier responds to a first network address The server system also comprises the viπual store for shopping The virtual store responds to a second network address The customer system allows a customer to make shopping requests 5

Briefly, in accordance with another aspect of the invention, a method for transacting business in the distπbuted communications system compπses receiving product requests at the virtual cashier from the virtual store, and receiving payment information at the virtual cashier from the customer system

Briefly, in accordance with other aspects of the invention, computer readable media contain program instructions for implementing the above methods

Briefly in accordance with other aspects of the invention, virtual stores and virtual cashiers implement the above methods

FIG 1 is a functional block diagram of a non-distributed electronic commerce system for the World Wide Web ("WWW"), according to the pπor art

FIG 2 is a functional block diagram of a distributed electronic commerce system for the

WWW, according to the present invention

FIG 3 is a functional block diagram of another distributed electronic commerce system for the WWW, according to the present invention

FIG 4 is a functional block diagram of another distπbuted electronic commerce system for the WWW, according to the present invention

FIG 5 is a flow diagram of the functions that are performed in a typical shopping experience by a WWW customer using the distributed electronic commerce system depicted in FIG 4 6

1 Introduction and Overview

Referπng to FIG 1, there is shown a system 100, according to the prior art, in which the three functions of product presentation, database management, and transaction processing are contained in one server 108 and are, therefore, not distπbuted The server 108 refers to a specific computer These three functions are performed by the Web storefront 106, the inventory and financial database 104, and the Transaction Server 102, respectively An example of a provider of this type of non-distπbuted service is Net Commerce It is quite possible, however, to distπbute the three functions amongst two or more separate servers

FIG 1 also illustrates a functional diagram of a computer network for World Wide Web

("WWW") access from customers 114, 116 to the server 108 Access to the server 108 can be accomplished directly through a local Internet Service Provider ("ISP") 1 10, or through an on-line service provider ("OLSP") 112 such as CompuServe, Prodigy, or America Online

One method of distributing the electronic commerce functions is to separate out the function of the Transaction Server from the Web storefront and the inventory and financial database Referπng to FIG 2, there is shown a system 200 containing a Transaction Processor 102 on one server (the Transaction Server 202), and a Web storefront 106 and inventory and financial database 104 both on a second server (the Store Server 204) This may be desirable, for instance, when the Web merchant desires to maintain its own Web storefront, whether due to the merchant's expertise, physical distance from the transaction service provider, or otherwise Such a merchant could use any of the many hosting service providers such as CyberGate, Magg Net, and UUNet

FIG 3 shows a system 300 with a further distribution, in which the database 104 is not on-line The dashed line in FIG 3 indicates that the inventory and financial system may or may not be electrically connected to the server A computeπsed system could have an electrical interface to the server and not be located on the server itself Alternatively, the 7 inventory and financial system may be stand alone. This may be the case if the Web merchant does not have a computerised inventory and financial database system, or if the merchant has a computerised database system but simply does not have it connected to the server.

Referring to FIG. 2, the Store Server 204 is a conventional HTTPd (Hyper-Text Transfer Protocol daemon). In the preferred embodiment, it is a Sun Micro systems' s Java compliant HTTPd server running Java compliant supporting standard servlet interfaces such as Netscape Java Server software or Lotus Domino Go Java software. By using a Java compliant implementation, the same code can run on a variety of operating systems supporting the Java Virtual Machine including without limitation Solaris, Unix, AIX, OS/2, and Windows 95 NT operating systems.

As an overview, and referring to FIG. 3, the Transaction Server 202 now does not host the Web storefront 106. However, the Transaction Server 202 need not store any of the inventory or financial data nor any other information on the product line of the merchant. All the information that the Transaction Server 202 needs in order to process a purchase (for example, from customer 114) is sent to it every time that a purchase is requested. The Transaction Server 202 verifies that the customer 114 wants to make a purchase of a specific "shopping basket" of products and prompts the customer 114 for payment information. Either the merchant or the Transaction Server 202 can perform the tasks of credit card verification, authorisation of the total purchase amount, and funds transfer. When the Transaction Server 202 has finished its tasks, it then provides the merchant with a status report of the transaction and the customer with a confirmation.

The Web storefront 106 acts as the virtual store for the customer 114, and contains whatever information the merchant has built into the Web-site (e.g. pictures, prices, search engines, etc.). In the Development Tool Application, there is provided a Development Tool for designing the Web storefront 106. This tool greatly simplifies the task of creating the 8

Web storefront initially and of modifying it and updating it The Tool also ensures that the operation with the Transaction Server 202 is seamless for the customer 114

The Tool derives much of its utility from the fact that it contains a series of templates, tailored to different industπes, for creating pages The fields on these templates can be filled with text, or with images from clip art (also included with the tool) or can be tailored to suit a specific merchant's needs The task is greatly simplified by the inclusion of a prompting mode in which the tool will actually step a user through the process As an additional tailoπng feature, the tool can be adapted to whatever "look and feel" the customer may desire The customer may want to match the look and feel to that of other applications that the customer uses, or may simply feel more comfortable with another look and feel

In the preferred embodiment, the Tool, as either an applet which would run on top of a browser or as an application, would be downloaded from a Store Builder Server Referring to FIG 4, there is shown a distributed electronic commerce system 400 with a Store Builder Server 402 The merchant would download the Java wizard applet to build the pages for the Web storefront, which will reside on the Store Server 204 The Store Builder Server 402 would also contain Java servlets that would receive the HTML from the wizard applet for the storefront pages that the merchant designed and would build the store pages from this HTML This, of course, would happen when the merchant initially designed the pages, or whenever the merchant updated or modified them The servlet, on the Store Builder Server 402, would then publish the Web storefront pages wherever the merchant designates The commerce system is thereby distπbuted even more, by separating (if desired) the tasks associated with designing the merchant's Web site In alternate embodiments, the Tool could be downloaded from the Transaction Server 206 or obtained on a CD ROM or other recordable medium 9

2 Detailed Description of the Shopping Flow

Referring to FIG 5, flow diagram 500 illustrates the high-level functions that each of the servers (see FIG 4), or each of the Web sites hosted thereon, performs in a typical shopping experience of a customer

The customer, using a browser, goes to the Store Server and begins shopping, that is, browsing the content of the Web storefront 502 When the customer finds a product that the customer would like to buy, he selects that product 504 The Store Server then jumps to the Store Builder Server by using a Uniform Resource Locator ("URL") 506 The URL, called a price URL, contains all of the relevant information on the product, and all the information necessary to build a "Buy Page " The relevant product information includes a picture of the product, the product's price, and a description of the product

The Store Builder Server receives the price URL, which is encrypted, and a Java "Buy Page" servlet builds a Buy Page from the received HTML 508 The customer can now either accept by selecting the option that puts the product in the customer's "shopping basket," or cancel the buy 510 If the buy operation is cancelled, then the customer is returned to the Store Server and can continue shopping If the buy operation is accepted the Store Builder Server then presents the customer with his entire shopping basket up to that point, which the Store Builder Server creates and maintains The customer can now delete items from the basket, change the quantities, "purchase" the entire basket, or return to the Store Server to continue shopping 512 It should be clear that the previous buy operation was equivalent to dropping the product in the shopping basket, and the purchase operation is equivalent to going to the check-out counter The Java servlet that maintains the shopping basket could use any of a variety of means, including without limitation tracking the Web customer's browser address or prompting the customer for a name, for keeping track of which customer belongs to which basket 10

The customer leaves his shopping basket page by either making a purchase or continuing shopping If the customer decides to make the purchase, he is hyperlinked to the Transaction Server 514 The Transaction Server, thus, is not involved until money is ready to be transferred The Transaction Server, therefore, immediately establishes a secure link between itself and the customer's browser 516 Any security protocol could be used, but the secure sockets layer ("SSL") protocol is preferred After establishing a secure link, the Transaction Server prompts the customer for the necessary identification, delivery, and payment information 518

In an alternate embodiment, the functions of establishing a secure link and getting the customer's payment information could be done in the Store Builder Server The Transaction Server would then receive this information from the Store Builder Server, in an encrypted form, and decrypt it This would provide an embodiment in which the Transaction Server did not need to interact in real-time with the customer, but merely provide a confirmation if desired

The Transaction Server may, optionally, verify the credit card information, authorise the payment amount, and transfer the funds to the merchant's account 520 The Transaction Server would do this by using a third party credit card clearinghouse such as IC Verify or Automated Transaction Services (ATS) The merchant need not request this service from the Transaction Server, however Low-volume merchants may prefer simply to be e-mailed (securely) or faxed the entire purchase order, and perform these functions themselves, thereby saving the associated cost that the transaction service provider would have charged Additionally, the merchant may prefer to check his inventory before charging the customer

In either case, the Transaction Server will notify the merchant of the status of the transaction and supply all of the product, customer, delivery, and payment information 522 If the customer provided an e-mail account, then the Transaction Server will also send a confirmation of the transaction to the customer 522 1 1

The Transaction Server could also perform, in alternate embodiments, the functions of the Store Builder Server. In such an embodiment, the price URL would hyperlink to the Transaction Server which would contain the Java servlet that builds the Buy Page, and the Java servlet that maintains the shopping basket.

3. High-Level Functions Performed by each Server

Having explained the sequence of events and communications between the servers during a typical transaction, it will be instructive to summarise, individually, the functions performed by each of the servers.

a. Functions Performed by the Store Server

The Web storefront performs one basic service, and that is to present the multi-media content to the customer in order to let the customer shop. The format of this presentation is controlled by the merchant, and can easily be designed using the Development Tool disclosed in the Development Tool Application of the applicant under IBM reference number BC9-98-020.

The Web storefront could have a variety of other functions associated with it. For instance, background information on the merchant, contact information, news items of interest to the merchant's customers, etc. can all be displayed on the Web storefront.

As discussed earlier, the merchant can control inventory and financial data in any manner desired. If the merchant utilises a computer-based database, then the merchant can also interface this to the Web storefront. This could be used to supply information on backorders, quantities available, current prices, etc. to the customer. In a sophisticated system, the database could even possibly be interfaced electronically with the Transaction Server by creating a program that processes the e-mail order notifications sent by the Transaction Server. 12 b. Functions Performed by the Store Builder Server

The first major function of the Store Builder Server is to help the merchant get his Web storefront up and running. The Store Builder Server first provides the wizard applet or application, which allows the merchant to create his Web storefront. The Store Builder Server then accepts the HTML for the Web storefront from the merchant and builds the Web storefront. The Store Builder Server then publishes the Web storefront at a site of the merchant's choosing. The merchant supplies a user ID and a password to the Store Builder Server, and the Store Builder Server uses file transfer protocol ("FTP"), or some other service, to send the Web pages to the chosen hosting site.

The second major function of the Store Builder Server is to provide the shopping basket for the customer. The Store Builder Server places each product in the basket as the customer selects or buys them and holds them until the customer is ready to check out. At that point, the Store Builder Server transfers control, and the relevant information, to the Transaction Server.

c. Functions Performed by the Transaction Server

The Transaction Server has only one general responsibility, and that is to process the customer's information. This involves getting the information from the customer and transferring it to the merchant. As explained earlier, it may also involve verifying the information, getting the purchase authorised, and transferring the funds. Additionally, the Transaction Server can also send the customer a confirmation of the transaction.

Also of importance is the fact that the Transaction Server, like the Store Builder Server, need not know where the Store Server is located. That is, the Transaction Server does not require that the Store Server, or even the Store Builder Server, be at any particular Internet address. Even in an embodiment in which the Transaction Server also performed the functions of the Store Builder Server, the Transaction Server would not need to know where the Store Server was located. In such a case, the Transaction Server would receive 13 the price URL with the product information It is evident, however, that once the pπce URL is sent, the location of the Store Server (or rather, the location from which the pπce URL was sent) is, and needs to be, known Knowing where the price URL was sent from (typically a page from the Store Server) allows the Transaction Server or the Store Builder Server to hyperlink the Web customer back there to continue shopping

4 Advantages associated with the Preferred Embodiment a Advantages for the Merchant

The preferred embodiment has a number of significant advantages for the merchant who desires to participate in electronic commerce First, it is less expensive than the non-distπbuted system The merchant need only buy the Development Tool to create the Web site, pay for hosting of the Web storefront at an ISP of the merchant's choice, and pay the charge for the transaction services (usually based on volume) Hosting fees can be as low as twenty dollars per month depending on the memory and the bandwidth required

Second, it is much simpler to create the Web storefront than to create an ordinary electronic commerce Web site The Development Tool, which is descπbed in the Development Tool Application mentioned earlier, allows the merchant to design, build, and publish a web site in a short period of time It also makes it easy to modify the site This is to be compared with the process of hiring a professional to do it, or with educating oneself about the process and doing it alone

Third, it offers a great deal of control to the merchant The merchant can redesign the site, change pπces, decide to have a sale, add or delete products, update the site with pictures or other content, expand the number of places that offer the products for sale on-line, change hosting sites, and much more, all without even notifying the Store Builder Server or the

Transaction Server The merchant has almost complete control The merchant can do anything the merchant wants with the site or with the information on the site The only restriction is that the price URLs, which allow the Store Builder Server to build the Buy Pages, have to be included on the site, or elsewhere, in order for the Web customer to place 14 an order The merchant can even totally remove the Web storefront, and simply post the price URLs on news groups or on another web site

It should be clear that the distributed electronic commerce system offers significant advantages to all merchants, particularly those of small to medium size

b Advantages for the Transaction Service Provider

There are a number of distinct advantages that this embodiment offers the transaction service provider First, overhead is minimised Much of the overhead and cost of hosting a commerce Web site comes from the bandwidth requirement Every time that a Web site gets a "hit," information must be transmitted If the transaction service provider chooses not to host the Web storefronts, then it does not have to process any of the hits associated with all of the shopping that occurs on the Web storefronts The bandwidth usage will be even lower because, presumably, many of the merchants will choose to do their own credit card verification, thereby eliminating those transmissions as well Further, in embodiments utilising a Store Builder Server, the Transaction Server does not need to maintain the shopping baskets, nor process the hits associated with each of the buys

Second, the amount of memory required is minimised The Transaction Server does not need to host any of the Web storefronts, nor does it need to maintain any shopping baskets nor any information on the products being offered for sale by the merchants, nor does it need to keep any data regarding the Store Servers In the preferred embodiment, the primary merchant-related data that the Transaction Server needs to store is a list of all of the registered merchants and their contact information Clearly, however, Transaction

Servers will want to keep track of sales so that they can bill the merchant's for their services, and may want to store additional information and statistics about the merchants as well 15

Third, the barrier to entering into electronic commerce is lowered for the merchants. This benefits the transaction service provider because it opens up a whole new group of potential customers. These potential customers are the merchants who could not afford to do non-distributed Web commerce.

Fourth, the technique is also scaleable. The transaction service provider can serve a much larger number of merchants with a given Transaction Server (due to the advantages above). If the number of sales grows and a particular Transaction Server reaches its threshold in memory or bandwidth, then the transaction service provider can simply add another Transaction Server and have the Store Builder Server direct some of the traffic to it. The

Store Builder Server is also scaleable, and if an additional server is needed due to volume it can be added. In that case, the provider can use the new server for future merchants or even direct current merchants to create any future price URLs (for new products or changes for existing products) using the new server.

5. Virtual Commerce

It is useful to broaden some of the concepts introduced or discussed above in order to see how they fit into the broader concept of virtual commerce. The merchant's web site, that is the actual web pages, can be considered to be a virtual store. The virtual store could span across one or more physical servers or computers, and these servers can collectively be referred to as the store server system. Analogously, the transaction service provider's web site can be considered to be a virtual cashier, spanning across a cashier server system comprised of one or more servers. The store builder j server web site could be considered to be yet a third virtual entity, or it can more simply be considered to be either part of the virtual store or the virtual cashier.

Numerous criteria could be developed to determine when these virtual entities could be considered to be distributed. Some such criteria include: different servers or computers hosting the web sites; different processors executing the instructions associated with each 16 web site, with each processor potentially accessing the same memory; or each web site merely responding to a different network address, possibly residing in the same memory on a common server, running on the same processor, and accessing the network over the same hardware such as a communications card. Each of these ideas is meant to be encompassed in the present application when referring to distributed systems. For this reason, the computers or servers that are part of the store server system may also form part of the cashier server system.

These virtual stores and cashiers are presently displayed over the World Wide Web and the Internet, but future networks will surely arise for which virtual commerce will be applicable.

Further, the present means of accessing and displaying virtual entities will change. Presently, web browsers running on personal computers processing HTML pages with HTTP requests and using URLs to link between pages is the preferred mechanism or system for customers to access the content. Software and computer technology will quickly replace many of these standards. Additionally, other technologies involving optics, magnetics, and other sciences could also produce viable methods of accessing and displaying virtual entities. Each of these potential advances, when used to enable a distributed commerce system over a network, can be viewed as a further embodiment of the present invention.

6. General Implementation

Distributed commerce systems, in accordance with the present invention can be, at least partially, implemented by hardware, software, or a combination of both. This may be done for example, by Java applets and servlets running on a variety of host equipment. Moreover, this functionality may be embodied in computer readable media such as 3.5 inch diskettes to be used in programming an information-processing apparatus to perform in accordance with the invention. This functionality may also be embodied in computer readable media such as a transmitted waveform to be used in transmitting the information or functionality. 17

Although a specific embodiment of the invention has been disclosed, it will be understood by those having skill in the art that changes can be made to this specific embodiment without departing from the scope of the invention as defined in the appended claims.

Claims

18CLAIMS

1. A communications system for transacting business comprising a customer system (110, 114, 112, 116) for allowing a customer to make shopping requests, and a server system (108) which is coupled to the customer system, wherein the server system comprises a virtual cashier (104) for receiving product requests and payment information, and wherein the virtual cashier responds to a first network address; a virtual store (106), and wherein the virtual store responds to a second network address, the virtual store comprising: first receiving means (102) for receiving a shopping request from the customer system; and/or sending means (102) for sending a product request to the virtual cashier; and/or second receiving means for receiving payment information from the customer system characterised in that the server (108) is distributed so that at least one of the virtual cashier (104), the virtual store (106) and the receiving and sending means (102) is not contained in the server (108) but is separate from it (202, 204).

2. The system of claim 1, wherein: the receiving means comprises using a hyper-text markup language ("HTML") page containing uniform resource locators ("URLs") attached to specific products allowing the customer system to select a given product and to thereby issue the corresponding URL to the virtual store; and the sending means comprises means for sending product information describing at least one product and a merchant identifier which identifies the seller of the at least one product.

3. The system of claim 1 or 2, wherein the first receiving means comprises a means for receiving a URL containing information about a single product.

4. The system of claim 1 or 2, wherein the first receiving means (102) comprises a means for receiving a list of products which a customer has selected. 19

5 The system of claim 1 or 2, wherein the second receiving means comp╧Çses a means for securing the transmission link between the virtual cashier and the customer

6 A method of operating a communications system for transacting business, wherein the communications system comp╧Çses a customer system (110, 114, 112, 116) for allowing a customer to make shopping requests, and a server system (108) which is coupled to the customer system, wherein the server system comp╧Çses a virtual cashier (104) for receiving product requests and payment information, the virtual cashier responding to a first network address, and a virtual store (106) for shopping, the virtual store responding to a second network address, the method for transacting business including any one or more of the steps of receiving a shopping request at the virtual store (106) from the customer system, and sending a product request to the virtual cashier (104) from the virtual store, receiving product requests at the virtual cashier from the virtual store, and/orreceiving payment information at the virtual cashier from the customer system, and/or sending notification of the transaction to the owner of the virtual store, and/or sending confirmation of the transaction to the customer, characte╧Çsed by the step of having the server system (108) distributed so that at least one of the virtual cashier (104), the virtual store (106) and the receiving and sending steps are located in at least two servers (202,204)

7 A computer readable medium for use in communications system for transacting business, wherein the communications system comprises a customer system for allowing a customer to make shopping requests, and a server system which is coupled to the customer system, wherein the server system comprises a virtual cashier for receiving product requests and payment information, the virtual cashier responding to a first network address, and a virtual store for shopping, the virtual store responding to a second network address, the computer readable medium containing program instructions for transacting business, the program instructions comprising instructions for 20 receiving a shopping request at the virtual store from the customer system, and/or sending a product request to the virtual cashier from the virtual store, and/or receiving product requests at the virtual cashier from the virtual store; and/or receiving payment information at the virtual cashier from the customer system and/or sending notification of the transaction to the owner of the virtual store, and/or sending confirmation of the transaction to the customer

8 A virtual store comprising a transaction processor (102), an inventory and financial database (104), a web storefront (106) and a server (108), characterised in that the server (108) is distributed so that the processor (102), the database (104) and the storefront (106) are distributed between at least two servers (202,204)

9 A virtual store comprising a transaction processor (202), a web storefront (204) and an inventory and financial database (104) characterised in that the transaction processor (102) comprises a transaction server (202) and the web storefront (106) comprises a store server (204)

10 A virtual store (400) comprising a transaction processor (102) and a web storefront (106) and a server, characterised in that the transaction processor comprises a transaction server (202), the web storefront comprises a store server (204) and there is a store builder server (402) which in use can act as a tool whereby a user can download therefrom to build pages of the web storefront (106).