WO2002003267A1

WO2002003267A1 - Aggregated transaction and fulfilment workflow

Info

Publication number: WO2002003267A1
Application number: PCT/AU2001/000770
Authority: WO
Inventors: Daniel Austin; Kevin Bungard; Scott Hurst; Dana Kedzier
Original assignee: Westfield Limited
Priority date: 2000-06-30
Filing date: 2001-06-29
Publication date: 2002-01-10
Also published as: WO2002003243A1; WO2002003268A1

Abstract

A web site structure and a method of building a web site for an internet shopping mall in which a number of different and independent retailers are represented on web pages produced on the shopping mall site but under each retailers individual control. The web sit is structured to provide seamless integration of resident and third party internet sites into a portal shopping site, while maintaining the integrity of the third party sites, and providing access to shopper service functions aggregated across and accessible from the resident and third party internet sites. The site also provides product and consumer profiling to provide an enhanced shopping experience, by matching product and consumer profiles when serving pages to a consumer. The web site also provides a transaction management system which manages an aggregated transaction and fulfilment workflow for a plurality of transactions of con current transactions.

Description

Aggregated transaction and fulfilment workflow

Introduction

The present invention relates generally to the field of e-commerce and in particular the invention provides a web site structure and a method of building a web site for an internet shopping mall in which a number of different and independent retailers are represented on web pages produced on the shopping mall site but under each retailers individual control. Background

Prior art web sites that linked different retail services were initially simply web pages with links through to independent retailer web sites, however this mechanism did not allow any aggregation of services at the mall site.

Subsequent improvements to such sites involved passing information between the Mall site and the retailer site to enable checkout functions to appear to be aggregated at the mall site but in fact the transaction details were sent back to the individual retailers who then performed the financial transactions with an appropriate bureau and arranged delivery. Such sites still did not provide any aggregation of services other than checkout services and provision of a pseudo-shopping cart to enable the purchaser to collect items from one or more retailers before completing the purchases. Further the building of the retailer site was done by the retailer and no integration of the pages of the Mall and retailer sites was possible.

Some more recent sites have been created which collect together retail services that would have previously been provided by different retailers (eg. Books and Hardware) and provided the services in different pseudo-stores on the "Mall" site but in effect the retail services were all provided by the one provider and the design and construction of the web pages of the individual pseudo-stores were all performed centrally by the mall site operator.

Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Any description of prior art documents herein is not an admission that the documents form part of the common general knowledge of the relevant art in Australia. Summary of the invention

According to a first aspect, the present invention consists in a method of managing an aggregated transaction and fulfilment workflow for a plurality of transactions of a predetermined type characterized by a set of mandatory fulfilment process types common to the transaction type, the transaction being between two or more transaction parties including at least two primary transaction parties, and facilitated by at least one intervening fulfilment party, where the transaction parties and fulfilment parties may differ from one transaction to the next, each transaction comprising one fulfilment process of each of the mandatory process types, and each fulfilment process selected from a plurality of possible fulfilment processes, each fulfilment process involving at least two transaction parties, at least one fulfilment party, and comprising one or more fulfilment mechanisms, wherein the fulfilment mechanisms for a given fulfilment process must be specified as acceptable by the transaction and fulfilment parties involved with the respective fulfilment process, the method including the steps of: a) a fulfilment manager maintaining a database of possible transaction parties, fulfilment parties, and fulfilment mechanisms and recording for each transaction or fulfilment party in the database those fulfilment mechanisms which are acceptable to that party; b) separating each transaction into its fulfilment process types; c) for each fulfilment process type of each transaction, determining the transaction parties; d) for each fulfilment process type of each transaction, determining a working set of all of the fulfilment processes of that type which only use fulfilment mechanisms acceptable to the transaction parties involved in that fulfilment process type; e) for each fulfilment process type selecting a fulfilment process from the respective working set; f) for each fulfilment process type aggregating the fulfilment processes by fulfilment party; g) for each selected fulfilment process communicating relevant transaction details to the respective fulfilment party in respect of each transaction for which that fulfilment process has been selected; h) each fulfilment party managing the one or more fulfilment mechanisms of each of the fulfilment processes in which it is involved, to complete a fulfilment step between the two or more transaction parties involved in each respective fulfilment process; i) reporting the progress of each fulfilment process involving the respective fulfilment party to the fulfilment manager; j) the fulfilment manager, separating the progress reports from each fulfilment process and re-aggregating them by transaction; k) establishing progress report information with regard to the fulfilment processes for each transaction, and storing the report information; and 1) providing the report information to at least the primary transaction parties via an enquiry facility.

Preferably, the primary transaction parties are a shopper and a vendor and the transaction is a purchase of a product or service whereby one fulfilment processes is a delivery process for delivery of the product or service to the shopper or a shoppers agent, and a second fulfilment process is a settlement process for settlement of the vendor's fee or charge.

In the case where the transaction is a purchase of a service, the fulfilment process preferably further includes, as a fulfilment party, a vendor's supply agent and the delivery service comprises the supply agent arranging delivery of the service to the shopper or a shopper's agent. In the case where the supply of the service requires the supply of a supporting product to the shopper or the shoppers agent to enable receipt of the service, the fulfilment process preferably further includes, as a fulfilment party, a vendor's delivery agent and a delivery service comprises the delivery agent collecting the supporting product from the vendor, the vendor's supply agent, or an agent of the vendor or the vendor's supply agent, and delivering it to the shopper or a shopper's agent.

In the case where the transaction is a purchase of a product the fulfilment process preferably further includes, as a fulfilment party, a vendor's delivery agent and the delivery service comprises the delivery agent collecting the vendor's product from the vendor or a vendor's agent and delivering it to the shopper or a shopper's agent.

In the preferred embodiment, the transaction parties further include, as a secondary transaction party, a vendor's supplier and a supply process comprises delivering the product from the vendors supplier to the vendor or vendors agent. The preferred embodiment may also include a case where a warehousing and packing agent is acting as the vendor's agent in respect of one or more vendors and the delivery processes of a plurality of transactions between a single shopper and the one or more vendors are aggregated using the warehousing and packing agent as their common agent whereby one delivery agent delivers the products in respect of the plurality of transactions in a single delivery.

Preferably the transaction parties will further include, as a secondary transaction party, a vendor's supplier and the delivery process comprises delivering the product from the vendor's supplier to the shopper or a shopper's agent.

The fulfilment process preferably further includes, as a fulfilment party, a vendor's delivery agent and the delivery service comprises the delivery agent collecting the vendor's product from the vendor's supplier and delivering it to the shopper or the shopper's agent.

The possible fulfilment mechanisms of a settlement process for achieving settlement of the vendor's fee or charge are preferably by credit card payment against a shoppers credit card account, direct debit of a shoppers financial institution account, B-Pay payment from a shoppers account. In the preferred embodiment, there is also the possibility of more than one fulfilment process being used, employing more than one settlement mechanism to achieve settlement of the vendor's fee or charge. Embodiments of the invention envisage using a settlement gateway as an intervening fulfilment party in a settlement process for achieving settlement of the vendor's fee or charge, whereby the settlement gateway receives details of a fulfilment mechanism acceptable to the shopper, details of the shopper's account at the shoppers financial institution and the vendor's account at the vendors financial institution, and initiates a withdrawal against the shoppers account and a deposit against the vendors account. One further optional fulfilment mechanism of a settlement process for achieving settlement of the vendor's fee or charge is by redeeming points on a loyalty card. In this case the settlement gateway acting as an intervening fulfilment party: i) receives details of the shopper's loyalty card; ii) verifies with a loyalty card issuer, that issued the shopper's loyalty card, the loyalty points accrued by the shopper on the card; iii) obtains details of a loyalty card issuer's account at the loyalty card issuer's financial institution iv) obtains details of a vendor's account at a vendor's financial institution; and v) initiates a withdrawal against the loyalty card issuer's account and a deposit against the vendor's account.

Another optional fulfilment mechanism is by redeeming a gift voucher. In this case the settlement gateway acting as an intervening fulfilment party: i) receives details of the shopper's gift voucher; ii) verifies with a gift voucher issuer, that issued the shopper's gift voucher, the validity and value of the gift voucher; iii) obtains details of a gift voucher issuer's account at a gift voucher issuer's financial institution; iv) obtains details of the vendor's account at the vendor's financial institution; and v) initiates a withdrawal against the gift voucher issuer's account and a deposit against the vendor's account.

When a gift voucher is issued by the vendor, the preferred settlement process involves the settlement gateway receiving details of the shopper's gift voucher, verifying with the vendor the validity and value of the gift voucher, and advising the vendor to cancel the gift voucher.

In one embodiment of the invention, the fulfilment process is capable of tracking transactions where the progress of a first one of the fulfilment processes is dependant upon the status of a second one of the fulfilment processes, in which case the fulfilment manager monitors the status of the second fulfilment process and reports changes in status to the first fulfilment process.

In a preferred embodiment of the invention, the fulfilment process is capable of tracking transactions where the progress of first and second ones of the fulfilment processes are inter-dependant upon the status of each other in which case the fulfilment manager monitors the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process. In one embodiment of the invention, the first fulfilment processes comprises the delivery process for delivery of the product or service to the shopper, the second fulfilment processes comprises the settlement process for settlement of the vendor's fee or charge, and the delivery process will not commence until the settlement process has verified that the shopper's financial institution will meet the vendor's fee or charge. Preferably also the settlement process will not complete the settlement of the vendor's fee or charge until the delivery process has verified that the product or service is available to the vendor for delivery.

In an alternate embodiment the first fulfilment processes may comprise the supply process for supply of the product or service to the vendor or the vendor's agent, the second fulfilment processes may comprise the delivery process for delivery of the product or service to the shopper, and the delivery process will not commence until the supply process has supplied the product or service to the vendor or the vendor's agent.

According to yet a further aspect, the present invention provides a internet shopping mall in which Transaction Fulfilment services to a user are aggregated over a plurality of independent retailers integrally represented on the Internet Shopping Mall Site, such that purchases from a plurality of retailers may be completed in a single set of operations on the Internet Shopping Mall and delivery services are aggregated for a plurality of purchased goods. In a preferred embodiment Warehousing and packing functions are also aggregated.

Brief Description of the Drawings

Embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which:

Figure 1 is a high level block diagram of the overall structure of an Internet Shopping Mall according to the present invention;

Figure 2 is a block diagram showing the functional structure of an Internet Shopping Mall according to the present invention;

Figure 3 is a block diagram showing the integration structure of the Mall Site of Figures 1 and 2; Figure 4 is a block diagram illustrating a shop building function within the Internet Shopping mall of Figures 1, 2 and 3;

Figure 5 is a block diagram illustrating a possible hardware configuration for the Internet Shopping Mall of Figures 1, 2, 3 and 4;

Figure 6 is a block diagram illustrating a possible logical configuration for the Internet Shopping Mall of Figures 1, 2, 3 and 4;

Figure 7 illustrates an example of a retailer webpage; and Figure 8 is a workflow diagram for an auto-management system. Detailed Description of the Preferred Embodiment

In a preferred embodiment of the invention, an Internet Shopping Mall is provided, in which multiple retailers will be aggregated under the one banner of the Mall operator. This site includes a number of innovative functions including:

• Simple integration of Retailers from their existing Web Sites into the Mall Site.

• Merchandising facilities across all retailers, including search. • Aggregated shopping cart with single transactions and fulfilment.

Internet Shopping Mall Architecture

Figure 1 illustrates the Internet Shopping Mall site architecture of the preferred embodiment. Users will be able to access the Internet Shopping

Mall shopping functions via a web browser 11 and the Internet 12. The Internet Shopping Mall of the present invention is preferably implemented around three major components:

1) The Internet Shopping Mall System (ISMS) 17; and

2) The Transaction and Fulfilment Server (TFS) 18; and

3) The Retailer Enablement Server (RES) . These three components interact to provide the full functionality required by an internet shopper. The Internet Shopping Mall System (ISMS)

The public "face" of the internet shopping mall is the Internet Shopping Mall Server (ISMS). It is the job of the ISMS to present pages to shoppers, accept orders, and provide updates to shoppers of an orders progress. Pages will be served via a web server 13 connected to a Java based application server 14. The application server contains a common code library that control access to a JDBC (Java Database Connectivity) relational database. Also contained on the application server are the Customer Applications 16 that are built using the common services layer contained in the common code library.

In the preferred embodiment, the ISMS 17 provides the following databases:

• Product / S U database (catalogue and stock details) • Retailer database (participating retailer information)

• Shopper database (including user profile information) • Content databases (including matching profiles)

In addition, the ISMS will provide the following required functionality:

• provide a means for the Customer Applications to access the database tables, and for committing and rolling back database transactions

• manage user profile information

• manage the association of user profile information with products in the database

• house the business rule that decide which content will be displayed to which users based on profile information

• house the consumer applications that allow shoppers to organise products they are interested in, such as adding products to shopping carts, wish lists, gift registries or reminders.

The Transaction and Fulfilment Server (TFS) For payments and orders, the Customer Applications will communicate with the Transaction and Fulfilment Server (TFS) 18. It is the job of the TFS to process orders, including payment, shipping, and "track and trace" of parcels in shipment. Communication with the TFS will be via XML messages 19 passed over a CORBA bus or using HTTP. In turn the TFS will communicate 22 with a bank and payment gateway for merchant payment processing, and communicate with either (a) a central warehouse; or (b) individual retailer stock points to perform order fulfilment 21.

As part of its functional requirements, the TFS contains a single database: the orders database. This database tracks the status of every order. The ISMS may query this database, via the TFS, on behalf of a shopper or retailer requesting the status of a particular order.

In the preferred embodiment, the TFS is also responsible for the following functionality:

• handle the transaction and fulfilment of orders. • manage partially fulfilled orders.

• provide a HTTP/XML API for order management.

• provide a HTTP/XML API for committing and rolling back transactions on the order database.

The Retailer Enablement Server (RES) The third feature of the preferred embodiment for an Internet

Shopping Mall is the Retailer Enablement Server (RES). The job of the RES is to act as the coordinator between the shopper facing ISMS, the bank, warehouse and courier facing TFS, and the retailers who must fulfil the orders and respond to customer inquiries. In the preferred embodiment, the RES contains both an XML and HTTP based API to assist in direct integration with a retailer's legacy stock control or point of sale system, as well as an HTML based interface for those retailers wishing to defer integration. Through either the API or the HTML "back office" system, the retailer will check orders, respond to customer enquiries, and update order status through to the TFS. The RES is the mechanism by which a retailer is able to access all the pending orders for goods that it has received via the ISMS; update the status of such orders (eg "pending", "shipped", "delivered"); and respond to customer enquiries such as when ordered goods are out of stock.

In the preferred embodiment, the RES provides the following functionality:

• a HTTP/XML API to allow retailers to retrieve lists of pending orders and to update the status of orders

• provide an API and functioning back office system that utilises that API to allow retailers to update stock data, or integrate legacy systems into the ISMS stock database.

Internet Shopping Mall Integration

The Functional Structure of The Internet Shopping Mall site is illustrated in Figure 2 and the Integration Structure of the site is illustrated in Figure 3. Shoppers

The shoppers 31 represent an important point of interface with the site 100. Their interaction with the site may be limited to a single point, the web server 13, and their connection method will usually be HTTP (or HTTP + SSL), plus SMTP. Alternatives may include wireless protocols such as WAP Shoppers 31 will be able to transact on the site and use the advanced functionality with a basic web browser and without special plugins - however they will either need to have cookies enabled or the ISMS Application Server will need to embed a session identifier in the page URLs. Retailers Retailers 32 are preferably integrated on three levels (refer to Figure 4): 1. database:

• stock control integration: connections with legacy stock control databases to maintain very up to date stock information on the Internet Shopping Mall site; • Point of Sale databases integration, for recording of purchase orders and managing fulfilment. The integration point is with the RES.

2. pages: management of page templates to define the display of product and supporting pages. The integration point is with the ISMS. 3. functionality: integration with advanced retailer functionality currently offered on a retailer's existing web site beyond that already offered on the Internet Shopping Mall site.

In addition, retailers 32 may want to use a Content Management System accessed via the XML gateway 121 to define promotions, manage content on home pages (etc). Retailer Stock Integration

The present invention addresses, inter alia, two crucial aspects of managing an internet shopping mall site. Both are concerned with retail "stock" or product data. 1. Available stock information: This involves maintaining accurate product information concerning available stock (ie what is available for sale via the ISMS), including price, availability and shipping times. 2. Purchased stock information: This involves maintaining accurate information concerning stock that has already been sold, including shipping details, whether the product must be ordered from a supplier (a "back order") and when it has been delivered. The preferred embodiment encompasses the present invention by addressing these two points within the RES. The RES provides an interface for updating both available stock information and purchased stock information.

In the preferred embodiment, the RES provides an XML based API. The transport mechanism is SOAP, an HTTP based protocol that includes an XML encapsulation layer. The XML API addresses all stages of the product data lifecycle. The utilisation of SOAP as the preferred transport mechanism allows for relatively cheap, easy and open integration with legacy systems. The XML messages may be based on industry standards, or may be a proprietary standard that uses XSL to convert between the industry and proprietary standards. This allows very wide integration with legacy components. The single RES API may be accessed by multiple retailer legacy systems, dealing with either point of sale, stock control or product catalogue information. The RES API can also allow integration directly with retail suppliers.

However, not all retailers have sufficiently sophisticated systems to achieve this kind of integration. Other retailers may wish to defer investment in integration during difficult market periods or when IT resources are stretched. For these retailers, a separate "back office" system can be provided. The Back Office would essentially be a stand alone point of sale system, allowing retailers to updating product catalogue information (description, price, images); stock availability (stock on hand, shipping times); and order processing (order status, changes in order contents). The Back Office would utilise the RES API like any other point of sale or stock control system. In fact, the Back Office would be provided to retailers in source code form, or released under an open source license such as the GNU Public License.

The RES API allows for retailers to have their stock control information can be integrated at varying levels. In order of sophistication (and broad preference), they are:

1. live: A copy of the retailer's products database is kept on Internet Shopping Mall. Updates are maintained in real time, with retailer and web site updates being synchronised between databases.

2. batch: Same technical setup as live, however changes are 'batched' and processed at timed intervals (e.g. every hour).

3. manual: Retailer does not have their own stock control database, or wants to keep stock control separate. All stock is maintained manually using the RES Back Office. Retailer HTML Page integration

The Retailers 32 on the Internet Shopping Mall will generally fall into different classes of e-commerce readiness. It should be noted that a retailer's web sophistication is independent of their stock control database sophistication (for example, a retailer with no existing site may nevertheless have very good stock control databases).

Depending on the retailer's satisfaction with their existing e-commerce site, or whether or not they have an existing e-commerce site at all, a retailer may chose to design new pages for their ISMS presence, or have their existing pages automatically fetched by the ISMS for presentation to the shopper. Through a retailer management centre 33 retailers 32 use a page loader to either (1) load new HTML pages for the Internet Shopping Mall site ("custom page template model"); (2) nominate URLs where Internet Shopping Mall can load the required pages from their existing site ("reverse proxy template model"); or (3) a mix of 1 and 2.

To serve a page to a shopper 31, the page server 110 can follow a number of possible paths, however, essentially the differences generally relate to the source of information rather that the process. The page server pulls information from several sources to build a single page as follows: 1. Page server receives a request from the application server for a page relating to a specific retailer, possibly including a request for information on a specific category (eg "men's shoes"), product, or both. 2. Page server identifies correct source for the relevant template, based on the template model (custom or reverse-proxy) that relates to that retailer, category and/or product. If the custom model is being used, fetches the template from the retailer's mall site template database 116. If the reverse-proxy model is being used, retrieves the template from the retailer's non-mall site template database 216 (usually, the retailers preexisting e-commerce site). Commonly requested elements may be retrieved directly from a cache 112, no matter which model is being used. 3. Page server retrieves the retailer's product catalogue data held in the retailer's mall site stock database 111, which is updated from the retailer's non-mall stock database 211 on a regular basis. The page server then inserts the information into the relevant areas on the page, as indicated by the template code. If the reverse-proxy model is being used, additionally strips out content indicated by the retailer as not being relevant to the mall site, and inserts new content indicated by the retailer as being required for the mall site; 4. Page Server adds the mall site "power-bar" template or other mall defined templates which are retrieved from the mall site template database 117 (applies to all pages); and

5. The mall provided content which is retrieved from the mall site content. These components are assembled by the page server 111 to produce a composite page for serving to the shopper 31. Referring to Figure 5, an image of a retailer page as served to a user by the shopping mall site is illustrated by way of example. The page is divided into a retailer area 250 which occupies most of the screen and a mall site area 150 which occupies the upper and right hand edges. The retailer area is defined by a retailer page template which includes locaters to indicate insertion points for the page content. The page content may include a retailer's logo or banner 252, a number of other graphics or descriptive items 253 from the contents database 113 or 213 and stock information (such as price and availability) from the stock database 111. The shopping mall area 150 is merged with the retailer area by merging the respective templates. The mall area will include a variety of content including current news items 153 or, promotional items 153, navigational buttons 151 to allow the user to navigate around the mall and a house icon or banner 152 which are all obtained from the mall sites content database 114. Retailer Advanced Functionality Integration

Many retailers 32 on the Internet Shopping Mall site 100 will not offer any functionality beyond that outlined below for the Internet Shopping Mall. However a small number of advanced retailers have specialised functionality. An advantage of the page integration mechanism described above is that it can cater for retailers with existing e-commerce sites that have advanced functionality (eg a computer reseller that allows a shopper to design and "build" their own computer based on custom requirements). This is achieved by using the "reverse proxy" method of fetching a page template described above. Payment Processing (Banks)

Integration with the banks or payment gateways 301 is required to facilitate shopper transactions through payments from credit card accounts to merchants 32.

The web server (ISMS) receives the initial transaction request from the shopper in aggregate form (ie contains the requested products across all retailers). The web server passes the transaction to the Transaction and Fulfilment Server (TFS) which disaggregates the transaction, processes the component parts, and passes status information back to the web server for further processing (e.g. displaying receipt numbers, reporting failed transactions, etc). Communication occurs via XML objects passed over a CORBA bus. Alternatively, an HTTP interface may be available, similar to the RES SOAP model.

The transaction module within the TFS is designed to be able to handle the numerous bank errors, service outages and rollbacks that will arise in a running system. The system can also handle multiple payment methods within the one aggregated transaction. This is achieved by the use of server-side e-wallets to hold multiple payment method information. Process overview:

1. The shopper, after accumulating goods and services in their shopping cart and filling in their payment and delivery details, clicks Buy to complete the transaction.

2. The web server fetches the contents of the shopping basket from the session manager and formats an XML transaction request object. The object is passed to the TFS.

3. The TFS disaggregates the transaction. That is, it divides the transaction into merchants, calculates totals for each merchant, and loops through the merchants in a pre-defined order: a) for each merchant, pass a transaction request to the payment gateway; b) the payment gateway selects a transaction gateway 301 based on the preferred acquiring bank for that merchant. It is the payment gateway that contains the routing table for each merchant; c) the payment gateway is responsible for any immediate retries (e.g. due to connection timeout or broken link), possibly switching the transaction to a second (backup) acquiring bank 300 or gateway 301 if the first is not responding; d) the payment gateway returns the response from the transaction gateway 301 using a common XML response object.

4. After receiving final responses from all gateways, the TFS aggregates them into a new XML response object, and passes it back to the web server. The web server may need to initiate new transactions (e.g. with a different shopper credit card) but these are not distinguished from initial transactions and follow the same pattern. Stock point Integration (Warehouse & Retailers)

The Internet Shopping Mall provides a central warehouse to facilitate most retailer fulfilment needs. In addition to the Internet Shopping Mall warehouse(s), some retailers will wish to fulfil orders out of existing facilities without holding stock at the Internet Shopping Mall warehouse. Cross- docking is therefore provided to facilitate aggregated delivery. In a cross- dock, a retailer sends their goods to the warehouse to be packed into the same shipping parcels as a customer's other orders. The retailer saves on shipping costs, since they can send all their internet-ordered products to one location in one shipment. The customer also saves on shipping costs, since all their goods are shipped together.

After payment processing and retailer notification the TFS: • for retailers aggregating fulfilment with Internet Shopping Mall: notify the warehouse (fulfilment partner 400) to pick, pack and ship.

• for retailers performing their own fulfilment: notify retailer (i.e. acting as fulfilment partner 400) of goods to ship and delivery details;

• for both: track the shipment from purchase to Proof Of Delivery (POD) by accepting updates from fulfilment providers 400 and third parties.

The architecture is very similar to that of the payment gateway 301, consisting of a pseudo-gateway which will route to the warehouse or retailer as appropriate (via the RES).

The fulfilment gateway 401 sends orders to the warehouse and allows fulfilment providers 400 and couriers to update the status of an order on its way to the shopper's delivery address(es). Aggregate orders are disaggregated and re-grouped by shipping address (since a single aggregate order can involve multiple delivery addresses). The gateway can feed information back through the retailer gateway to notify retailers of shipping status (e.g. return to retailer - no such address). The gateway also receives information back from the fulfilment providers to allow shoppers to query delivery status online. Internet Shopping Mall Construction Overview

The information below is intended to illustrate how the present invention may be used in the preferred embodiment to build an Internet Shopping Mall site that addresses limitations in the prior art. System Modules

The system comprises the following modules:

• Shopper Web Interface: Specifies components visible to shoppers or supporting infrastructure. Consists of entry points (home pages); precincts; shop fronts, merchandising services and transaction services.

• Back End Services: Specifies supporting infrastructure not otherwise covered above, usually because it does not have an interface directly visible to users.

• Back Office Services: Management supporting services for both Internet Shopping Mall and the retailers. For example: promotion management, content management, reports.

• Internet Shopping Mall Interface: Interface .components and supporting infrastructure for the Internet Shopping Mall Management Centre (WMC).

• Retailer Interface: Interface components and supporting infrastructure for the retailers and their Retailer Management Centre (RMC).

• Transaction Fulfilment Server: Components supporting the transaction and fulfilment server.

Shopper Web Interface

Entry into the Shopper Web Interface is via a series of electronic 'doorways' into the site - enhancing the basic catchment to encompass affiliate and partner relationships. All pages except the Main Page require a single click access to 'home'.

Internet Shopping Mall Main Page: The main page provides a primary entry to the site, featuring the most significant retailers, providing single click access to the key features and promoting high value elements.

The following functionality is associated with the Main Page:

1. Single click access to all the major precincts.

2. Single click access to each of the key site services (merchandising services and transaction support services). 3. Shop logos for retailers on the main page, which will rotate through the various available retailers dynamically. Retailer icons may be chosen at random, with the distribution being skewed based on popularity or license fees. Where a user is a repeat visitor and profiling information is available, retailers may be selected based on that user's profile.

4. Promotion space for some merchants, generated from the content management system (promotions subsystem).

5. Promotion space for Internet Shopping Mall and the site services.

6. The page may also include: voting spaces (to help build a user's profile, collect demographic information, etc); key news regarding Internet Shopping Mall physical centres; and a single large promotion space for a particular Internet Shopping Mall precinct (rotating through the various precincts at random).

7. Links to best-selling products and retailers.

Precincts: Precincts are a core merchandising component of the site, collecting retailers into areas of common interest to consumers and segmenting retailers to allow them to retain a point of difference. Retailers may appear in multiple precincts where relevant (indeed, they may appear in a number of different locations within a single precinct). The top level precincts may be chosen along different lines, for example:

• Category: Products and retailers grouped by category or subject matter. For example: fashion, health and beauty, food, home, gifts, SOHO, sports, toys, etc.

• Event: Products and retailers grouped by life stage event (e.g. birth, birthday, party, wedding, Christmas, etc).

• Sale: Collection of retailers and products currently on sale. • Centres: Broken down by real-world mall. Each mall would contain the retailers who have a presence in that mall. Mall staff will also need to be able to add mall-specific content (e.g. current events at Miranda). Core Precinct Requirements: Precincts share some common elements and structure. The following are goals and requirements that all precincts share. Functionality that may be provided from the various Precincts includes:

1. Single click access to all the other major precincts and to the Internet Shopping Mall Main Page.

2. Single click access to each of the key site services. 3. Shop fronts for most significant retailers in precinct (only in precinct sub- categories). 4. Promotion and logo spaces for merchants and for Internet Shopping Mall services. Where retailers are listed in specific precincts, or have specific promotions, the capability to link to that specific area within the retailers' site (and not just to the retailers' home page). 5. Voting spaces, including feedback from previous surveys. Once a user has voted, the page should display aggregate results collected so far.

6. Key content relating to the particular precinct, pulled from the CMS.

7. List of precincts best-selling products and retailers.

8. Retailers may be listed in all precincts where they are relevant - as configured in the precincts database under the control of Internet

Shopping Mall.

9. Space for 'rotating' retailers, with the share of impressions based on popularity, user profile or fees paid.

Shops: The shops are the arrangements of all products, content and information relating to a particular retailer.

The functionality required to support Shops on the site are:

1. All shops should also have access to the common services in this section (e.g. gift registry) on a shop-wide scale.

2. All shop pages will contain the Internet Shopping Mall navigation bar, however the design of the rest of the page is entirely up to the retailer.

3. The minimum number of pages that may constitute a shop site is 4 or 5:

• a main page (home page)

• top-level category template

• second-level category template (optional) • product template

• an 'about us' page with contact information, return policy, etc.

The HTML pages define page structure - not content. In the preferred embodiment, the content is built dynamically from database sources (either the products database or CMS). • The Internet Shopping Mall offers to retailers a service that utilises any investments they have already made in their web presence. The Internet Shopping Mall therefore reproduces only the HTML pages - leaving content and product data to be sourced from their databases via the retailer gateway and Internet Shopping Mall products database (which acts almost as a cache). • The Mall of the present invention differs from previous attempts at mall design which shoehorned retailers to fit into a particular template and page layout. The result was no branding or differentiating factors for retailers and a less than compelling experience for shoppers. Search: The search facility provides rapid non-linear access to the site and allows shoppers to categorise the search by a variety of criteria.

• Useability research shows that users often resort to a search engine when it is not immediately apparent where they should proceed from a given page. In order to meet users requirements from a search engine, the preferred embodiment of the present invention would use thesauri and phonetic matching as well as freeform style search queries and use the inherently structured nature of the data to maximise relevance. Locate a Store: A service that allows shoppers to get the address and directions to the nearest outlet for a nominated retailer. This function provides accurate information (including map) on the location, and opening hours, of the nearest outlet of a given retailer, given a postcode or suburb / state of the shopper. Back End Services Shop Build Engine: The shop builder allows retailers to build and maintain best-practice internet shops at significantly reduced cost by dynamically populating marked templates with product content.

The Shop Builder can support a scalable architecture for the site that can manage 400 retailers, by moving common functionality into a base engine and allowing the full retailer site to be built out of no more than a handful of templates by populating pages dynamically with database content. Dual-site generation facility is also supported, so that the shop build engine can build a Internet Shopping Mall integrated shop site as well as a 'neutral' shop site that does refer to Internet Shopping Mall but uses the same technical infrastructure to generate the site. The above is achieved without resorting to prior art templating techniques that homogenise retailers or restrict their design freedom beyond the requirements of the shop site specification. An overriding consideration of the Shop Builders that Pages must be built and returned to users quickly. Shop Site Staging Area: The purpose of the Shop Site Staging Area (SSSA) is to provide a transition area for a retailer's web site design (HTML pages) to move to the Internet Shopping Mall Internet structure, format and architecture. It provides the retailer (or their web developer) a secure environment where they can:

• upload their web site;

• preview the uploaded web site (in HTML format); • convert the web site to the Internet Shopping Mall format;

• preview their web site in the Internet Shopping Mall format.

• The SSSA also provides the environment for Internet Shopping Mall "mall" administrators to review and publish the web site to the live Internet Shopping Mall Internet mall. Shop Site Construction

To provide a process to the retailer that applies minimal creative restriction in shop design while requiring no intervention from the retailer (or Internet Shopping Mall) to move the shop design into the Internet Shopping Mall Internet format necessitates a number of guidelines. Although the SSSA could be used as a development platform it is envisaged that the retailer's web developer will prefer to prototype and develop the web site on their own development environment. Site Directory

The Internet Shopping Mall shop implementation is based upon a retailer defining templates for differing categories of products and templates for products within a category.

A key issue is to allow the web developer 500 and retailer 32 the freedom to organise and develop their site with no or minimal restrictions whilst being able to move the site into the Internet Shopping Mall format with no or little re-work.

To facilitate this process the web developer is required to define and implement the site category hierarchy in a web directory structure (there is potential to do this at various levels). Within each category directory would be a template (or pointer to a template) that would define how that category is to be displayed or how the products for that category are to be displayed. An example is a web developer developing a site for a camping goods retailer that has level 1 categories of Tents, Clothes and Camping. Under Camping it had level 2 categories of Sleeping Bags, Tools, Cooking and Lights. Under Sleeping Bags it had level 3 categories of Mont, MacPac, Paddy Palin which were the companies that made sleeping bags. Under each of these brand names were listed their products. The web developer 500 would create a web directory structure to mimic the category hierarchy: eg. web nome\paddypalin\camping\sleepingbags\mont. This directory structure will define the URL to each category and product ie. to list the sleeping bags at Paddy Palin the user will enter: http://Internet Shopping Mall.com/paddypalin/camping/sleepingbags

In each of these directories held in the template database 116, would be the template (or pointer to the template) that defines how this category is to be displayed. In the case of the bottom most category then the template defines how the product is to be displayed.

The benefits of this approach are:

• the web designer and retailer can easily define the hierarchy and of the site;

• the retailer can define different templates for categories at the same "level";

• the web designer can demonstrate a site to the retailer as it will be viewed in the Internet Shopping Mall (in their own environment or Internet Shopping Mall's);

• "hard coded" pages and hyperlinks (eg. help and about us pages) will still be resolved when placed in the Internet Shopping Mall environment

(assuming relative addressing is used);

• no re-work is required to convert the site into the Internet Shopping Mall environment (assuming all guidelines are adhered to).

A detraction of this approach is the effort to construct and maintain a directory structure for retailers that have a large category hierarchy Templates and dynamic data

Template files define the layout and style for presenting category or product information. A template file is an HTML file within the shop site that contains a Dynamic Data Stub (DDS). A DDS is a placeholder that signals to the Internet Shopping Mall environment that content external to this page is to be inserted at this location (eg. from the CMS database 113, 114 or product database 111).

DDSs are supplied to web designers in the form of GLFs with guidelines on the syntax to be provided within the HTML to allow the Internet Shopping Mall environment to associate the GIF placeholder with the target data source. The collection of DDS placeholders will be enhanced as web designers/retailers require differing interaction and presentation for their customers. Through plug-ins to popular web design environments (eg. Dreamweaver™), a DDS toolbox will allow the designer to quickly select and place the appropriate DDS placeholder prompting the designer for the DDS data source (if appropriate) and presentation requirements (eg. style, layout, colour etc.)

It is anticipated that the majority of templates will be a collection of HTML tables consisting of any number of DDS GIFs. Site approval

When the retailer is satisfied with their site they will submit a request for Internet Shopping Mall to publish their site in the live mall. On internal approval to publish (copy) the site then the Internet Shopping Mall staff release the site in the live Internet Shopping Mall environment. In essence, this act will copy the appropriate static HTML files and supporting images, and template lookup information from the SA pre- approval area to the live mall environment.

A "live" timestamp will be recorded for all site, category and static page activations. Back Office Services

Content Management: The Content Management System (CMS) 101 is a service for both retailers and the Internet Shopping Mall to create and define content which is then dynamically 'plugged' into HTML pages prior to being sent to users. The CMS allows non-technical staff operating a client terminal 120 to quickly and easily create content for display in various parts of the retailer sites or Internet Shopping Mall precincts. The CMS is used to facilitate a dynamic and ever-changing content matrix to entice shoppers and encourage both purchases and repeat visits. It provides a single point of control to manage security issues relating to the introduction of content on the Internet Shopping Mall site.

The functions required to support the CMS are:

1. Authentication of retailer or Internet Shopping Mall staff member.

2. Create content either in HTML form, or allow the uploading of richer content objects (Flash files, images, sounds, QuickTime movies, etc). 3. Allow content to be time limited (e.g. only display from l-Jan-00 to 2-Jan- 00). 4. Allow content to be targeted to particular user profiles or triggered by events (e.g. viewing a particular product).

Just as retailer pages are populated with content from the products database 111 so too can they be populated with additional content from a content database 113, 114. The web developer may specify for example "top headline goes here" and the page builder will fetch the content from the content database 113, 114 and populate the HTML page with it. Note that the content can be from the retailer's private content database 113 or the mall operator's universal database 114. The mall operator may also have a content database for exclusive use in mall generated areas of the site.

Internet Shopping Mall Management Centre: The Internet Shopping Mall management centre allows Internet Shopping Mall to manage the centre and view key metrics. This function facilitates technical and non- technical Internet Shopping Mall staff managing all aspects of the Internet Shopping Mall site: content and promotions; preview and approval of shops and precincts; performance and merchandising metrics and billing. It also provides a single point of interface for centre management to facilitate security and auditing.

Most aspects of the operating of the Internet Shopping Mall site will be managed by business managers with no technical background. To best perform this role the ISMS management centre is organised around business functions, rather than reflect the underlying technology or architecture.

A major security threat comes from authorised staff members making unauthorised changes, or unauthorised staff members gaining any access at all. Most security compromises come from internal threats - therefore strong authentication, auditing and accountability are required to minimise risk. 1. The functions provided by the Internet Shopping Mall Management Centre interface are: Ability to preview and rebuild online shops and precincts. 2. Performance metrics for site, categories and shops and ability to generate reports.

3. Stock management tools to alter stock if needed.

4. Real-time monitoring of site traffic and sales by segment.

5. Promotions and direct marketing tools to manage campaigns. 6. Content management tools to manage other content requirements.

7. Order status information for all site orders. 8. Data mining centre to examine shopper, transaction and product information throughout the site and by category.

9. Billing information for the site.

Retailer Interface: The retailer interface consists of two parts: stock database integration (RES) and the Retailer Management Centre (RES Back Office). Inventory and Product Database: This module provides integration of retailers existing stock and inventory control databases, or point of sales (POS) systems, to provide real-time or batch updates of Internet Shopping Mall's products database. This is provided using the RES, as described above.

E-commerce sites must present users with up to date stock information, including stock availability and expected shipping times if they are to add sufficient value to users to be worth using. This information must come from the retailer and must be updated as frequently as the data requires.

A major concern for a retailers operating on the Internet Shopping Mall site is cost, and a major goal of the project is to substantially reduce the cost of retailers wishing to operate online. Integration with existing systems allows retailers to leverage off existing investments in IT infrastructure and expertise and also ensures high quality data reaches the Internet Shopping Mall site.

The Inventory and Product Database enables accurate collection of retailers products data (including stock levels) for use on the Internet Shopping Mall site to facilitate high quality, accurate and up to date stock information for consumers. This function adds value to retailers by integrating with their POS, minimising the retailer's overhead in conducting e-commerce and reducing their costs.

The Inventory and Product Database provides the following functions: 1. Facilitate an integration at a level that the retailer is comfortable with. 2. Accommodate full range of available retailer information, minimising the amount of 'normalisation' that must occur to accommodate the retailers legacy systems. 3. Stock information must be updated either when (1) the retailer makes a sale and takes the stock from the same area that online sales are filled from; or (2) a sale occurs on the Internet Shopping Mall site. 4. Internet Shopping Mall stock records may be updated from multiple sources: e.g. retailer POS system, inventory control system, agency system. Stock Management (RES Back Office): The stock management service allows retailers to update and manage their stock levels in their Internet Shopping Mall internet shops.

By allowing integration with existing systems the stock management service again allows retailers to leverage off existing investments in IT infrastructure and expertise and also ensures high quality data reaches the Internet Shopping Mall site.

The stock management service provides a facility for retailers to create, edit and delete SKUs and fill-in gaps in their product profiles and information. Information includes stock levels, with notification of when stock falls below the alert level. The stock management service also provides a stock and inventory management system for those retailers lacking a sufficiently sophisticated POS system.

The stock management service provides the following functions to the retailer: 1. Ability to add / remove and edit product content.

2. Access to stock level history over recent period.

3. Email-based notification of low-stock levels.

4. Ability to define profiles for products matching shopper and event profiles. 5. The typical operation of the stock management service is as follows:

6. Retailers log on to the RMC and access the Stock Management screen. The screen lists all categories and SKUs and allows retailers to create, edit or delete SKUs.

7. Retailers can view stock whose stock level has fallen below the alert level, sort stock by sales volume or other criteria. 8. Retailers can upload new content, such as product images, or edit any part of the stock information.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A method of managing an aggregated transaction and fulfilment workflow for a plurality of transactions of a predetermined type characterized by a set of mandatory fulfilment process types common to the transaction type, the transaction being between two or more transaction parties including at least two primary transaction parties, and facilitated by at least one intervening fulfilment party, where the transaction parties and fulfilment parties may differ from one transaction to the next, each transaction comprising one fulfilment process of each of the mandatory process types, and each fulfilment process selected from a plurality of possible fulfilment processes, each fulfilment process involving at least two transaction parties, at least one fulfilment party, and comprising one or more fulfilment mechanisms, wherein the fulfilment mechanisms for a given fulfilment process must be specified as acceptable by the transaction and fulfilment parties involved with the respective fulfilment process, the method including the steps of: a) a fulfilment manager maintaining a database of possible transaction parties, fulfilment parties, and fulfilment mechanisms and recording for each transaction or fulfilment party in the database those fulfilment mechanisms which are acceptable to that party; b) separating each transaction into its fulfilment process types; c) for each fulfilment process type of each transaction, determining the transaction parties; d) for each fulfilment process type of each transaction, determining a working set of all of the fulfilment processes of that type which only use fulfilment mechanisms acceptable to the transaction parties involved in that fulfilment process type; e) for each fulfilment process type selecting a fulfilment process from the respective working set; f) for each fulfilment process type aggregating the fulfilment processes by fulfilment party; g) for each selected fulfilment process communicating relevant transaction details to the respective fulfilment party in respect of each transaction for which that fulfilment process has been selected; h) each fulfilment party managing the one or more fulfilment mechanisms of each of the fulfilment processes in which it is involved, to complete a fulfilment step between the two or more transaction parties involved in each respective fulfilment process; i) reporting the progress of each fulfilment process involving the respective fulfilment party to the fulfilment manager; j) the fulfilment manager, separating the progress reports from each fulfilment process and re-aggregating them by transaction; k) establishing progress report information with regard to the fulfilment processes for each transaction, and storing the report information; and 1) providing the report information to at least the primary transaction parties via an enquiry facility.

2. The method of claim 1 wherein the primary transaction parties are a shopper and a vendor and the transaction is a purchase of a product or service whereby one fulfilment processes is a delivery process for delivery of the product or service to the shopper or a shoppers agent, and a second fulfilment process is a settlement process for settlement of the vendor's fee or charge.

3. The method of claim 2 wherein the transaction is a purchase of a service and the fulfilment process further includes, as a fulfilment party, a vendor's supply agent and the delivery service comprises the supply agent arranging delivery of the service to the shopper or a shopper's agent.

4. The method of claim 2 wherein the supply of the service requires the supply of a supporting product to the shopper or the shoppers agent to enable receipt of the service, and the fulfilment process further includes, as a fulfilment party, a vendor's delivery agent and a delivery service comprises the delivery agent collecting the supporting product from the vendor, the vendor's supply agent, or an agent of the vendor or the vendor's supply agent, and delivering it to the shopper or a shopper's agent.

5. The method of claim 2 wherein the transaction is a purchase of a product and the fulfilment process further includes, as a fulfilment party, a vendor's delivery agent and the delivery service comprises the delivery agent collecting the vendor's product from the vendor or a vendor's agent and delivering it to the shopper or a shopper's agent.

6. The method of claim 4 or 5 wherein the transaction parties further include, as a secondary transaction party, a vendor's supplier and a supply process comprises delivering the product from the vendors supplier to the vendor or vendors agent.

7. The method of claim 4, 5, or 6 wherein a warehousing and packing agent acts as the vendor's agent in respect of one or more vendors and the delivery processes of a plurality of transactions between a single shopper and the one or more vendors using the warehousing and packing agent as their common agent are aggregated whereby one delivery agent delivers the products in respect of the plurality of transactions in a single delivery.

8. The method of claim 4, 5, 6 or 7 wherein the transaction parties further include, as a secondary transaction party, a vendor's supplier and the delivery process comprises delivering the product from the vendor's supplier to the shopper or a shopper's agent.

9. The method of claim 8 wherein the fulfilment process further includes, as a fulfilment party, a vendor's delivery agent and the delivery service comprises the delivery agent collecting the vendor's product from the vendor's supplier and delivering it to the shopper or the shopper's agent.

10. The method as claimed in any one of claims 2 to 9 wherein the possible fulfilment mechanisms of a settlement process for achieving settlement of the vendor's fee or charge are by credit card payment against a shoppers credit card account, direct debit of a shoppers financial institution account, B-Pay payment from a shoppers account.

11. The method as claimed in claim 10 wherein more than one fulfilment process is used, employing more than one settlement mechanism to achieve settlement of the vendor's fee or charge.

12. The method of claim 10 or 11 wherein a settlement process for achieving settlement of the vendor's fee or charge involves a settlement gateway as an intervening fulfilment party, whereby the settlement gateway receives details of a fulfilment mechanism acceptable to the shopper, details of the shopper's account at the shoppers financial institution and the vendor's account at the vendors financial institution, and initiates a withdrawal against the shopper's account and a deposit against the vendor's account.

13. The method as claimed in any one of claims 2 to 12 wherein a fulfilment mechanism of a settlement process for achieving settlement of the vendor's fee or charge is by redeeming points on a loyalty card.

14. The method of claim 13 wherein a settlement process for achieving settlement of the vendor's fee or charge involves a settlement gateway as an intervening fulfilment party, whereby the settlement gateway: i) receives details of the shopper's loyalty card; ii) verifies with a loyalty card issuer, that issued the shopper's loyalty card, the loyalty points accrued by the shopper on the card; iii) obtains details of a loyalty card issuer's account at the loyalty card issuer's financial institution iv) obtains details of a vendor's account at a vendor's financial institution; and v) initiates a withdrawal against the loyalty card issuer's account and a deposit against the vendor's account.

15. The method as claimed in any one of claims 2 to 14 wherein a fulfilment mechanism of a settlement process for achieving settlement of the vendor's fee or charge is by redeeming a gift voucher.

16. The method of claim 15 wherein a settlement process for achieving settlement of the vendor's fee or charge involves a settlement gateway as an intervening fulfilment party, whereby the settlement gateway: i) receives details of the shopper's gift voucher; ii) verifies with a gift voucher issuer, that issued the shopper's gift voucher, the validity and value of the gift voucher; iii) obtains details of a gift voucher issuer's account at a gift voucher issuer's financial institution; iv) obtains details of the vendor's account at the vendor's financial institution; and v) initiates a withdrawal against the gift voucher issuer's account and a deposit against the vendor's account.

17. The method of claim 15 wherein the gift voucher is issued by the vendor, and the settlement process involves a settlement gateway as an intervening fulfilment party, whereby the settlement gateway receives details of the shopper's gift voucher, verifies with the vendor the validity and value of the gift voucher, and advises the vendor to cancel the gift voucher.

18. The method as claimed in any one of claims 1 to 17 wherein the progress of a first one of the fulfilment processes is dependant upon the status of a second one of the fulfilment processes and the fulfilment manager monitors the status of the second fulfilment process and reports changes in status to the first fulfilment process.

19. The method as claimed in any one of claims 1 to 18 wherein the progress of first and second ones of the fulfilment processes are inter- dependant upon the status of each other and the fulfilment manager monitors the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process.

20. The method as claimed in any one of claims 2 to 18 wherein the progress of first and second ones of the fulfilment processes are inter- dependant upon the status of each other and the fulfilment manager monitors the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process, the first fulfilment processes comprising the delivery process for delivery of the product or service to the shopper, the second fulfilment processes comprising the settlement process for settlement of the vendor's fee or charge, and the delivery process will not commence until the settlement process has verified that the shopper's financial institution will meet the vendor's fee or charge. 21. The method as claimed in claim 20 wherein settlement process will not complete the settlement of the vendor's fee or charge until the delivery process has verified that the product or service is available to the vendor for delivery. 22. The method as claimed in any one of claims 6 to 18 wherein the progress of first and second ones of the fulfilment processes are inter- dependant upon the status of each other and the fulfilment manager monitors the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process, the first fulfilment processes comprising the supply process for supply of the product or service to the vendor or the vendor's agent, the second fulfilment processes comprising the delivery process for delivery of the product or service to the shopper, and the delivery process will not commence until the supply process has supplied the product or service to the vendor or the vendor's agent. 31

the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process.

20. The method as claimed in any one of claims 2 to 18 wherein the progress of first and second ones of the fulfilment processes are inter- dependant upon the status of each other and the fulfilment manager monitors the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process, the first fulfilment processes comprising the delivery process for delivery of the product or service to the shopper, the second fulfilment processes comprising the settlement process for settlement of the vendor's fee or charge, and the delivery process will not commence until the settlement process has verified that the shopper's financial institution will meet the vendor's fee or charge.

21. The method as claimed in claim 20 wherein settlement process will not complete the settlement of the vendor's fee or charge until the delivery process has verified that the product or service is available to the vendor for delivery.

22. The method as claimed in any one of claims 6 to 18 wherein the progress of first and second ones of the fulfilment processes are inter- dependant upon the status of each other and the fulfilment manager monitors the status of the first and second fulfilment processes and reports changes in status of one of the first and second fulfilment processes to the respective other fulfilment process, the first fulfilment processes comprising the supply process for supply of the product or service to the vendor or the vendor's agent, the second fulfilment processes comprising the delivery process for delivery of the product or service to the shopper, and the delivery process will not commence until the supply process has supplied the product or service to the vendor or the vendor's agent.

23. The method as claimed in claim 1, substantially as hereinbefore described.