WO2014127444A1

WO2014127444A1 - Methods and systems for facilitating on-line commerce

Info

Publication number: WO2014127444A1
Application number: PCT/CA2013/000430
Authority: WO
Inventors: Jean-François RENÉ
Original assignee: Likisoft Stores Inc.
Priority date: 2013-02-19
Filing date: 2013-04-29
Publication date: 2014-08-28

Abstract

A method for facilitating commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace is provided. New orders are received and processed in the common marketplace to cause at least part of the orders to be fulfilled. The processing of the orders may include communicating with a remote transporter entity using a same common marketplace transporter account to arrange for pick-up and delivery of ordered products originating from at least two member merchants in the common marketplace. The processing of the orders may also include communicating with a remote financial services entity to arrange for payment of ordered products, wherein a same common marketplace payment account is used when arranging for payment of products originating from at least two member merchants in the common marketplace. A reconciliation process is performed between the common marketplace transporter account (and/or payment account) and accounts associated with the member merchants in the common marketplace to reflect pick-up and delivery services and product payments.

Description

TITLE: METHODS AND SYSTEMS FOR FACILITATING ON-LINE COMMERCE CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 USC § 1 19(e) of U.S. provisional patent application serial number 61/766,452 filed February 19, 2013 and presently pending. The contents of the above-mentioned patent application are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to computer implemented methods and systems for facilitating on-line commerce. Particularly, this application relates to a computer implemented common marketplace where customers can shop and purchase products from multiple independent merchants and where payment processing functions/services and/or pick-up and delivery coordination services are provided through such a marketplace in a centralized manner. This application also relates to methods, systems and computer program products for facilitating the creation of online stores, more particularly at least in part by facilitating establishing necessary functionality related to the logistics of ordering online including payment and shipping considerations.

BACKGROUND

Electronic commerce, or e-commerce, represents a highly convenient and efficient way for buyers and sellers to conduct transactions. In the past few years, the number of electronic commerce transactions, conducted using personal computers and more recently using mobile devices such as smartphones and tablets, has increased at what is an essentially exponential rate and this growth is expected to continue for at least the next few years. More and more businesses are setting up virtual stores on websites to allow their customers to shop and purchase products on-line.

For a merchant looking to use electronic commerce to increase his revenue/sales, different options are available. A first option is for the merchant to develop himself (or have someone else develop on his behalf) a customized/personal transactional website. This approach however has some drawbacks. A first significant drawback is cost. Generally speaking, the cost associated with developing such a website using a Web consulting firm can easily be between $5000 and $25000 or more depending on the complexity of the desired functionalities, without taking into account management fees, hosting and updates. Moreover, once the website is created and functional, the merchant must manage publicity campaigns and thus will incur further costs to attract clientele on his site amongst all the sites available on the Web. If the merchant's site is not well known or if the merchant does not have a lot of experience with on-line sales, he must create fidelity and trust with the new clients that he has attracted. Frequently, the merchant must also open his own merchant payment accounts if he chooses to accept credit or debit card payments, he must manage the transactions himself through his website and must also manage transactions by opening delivery accounts with transporters. This represents a significant barrier to entry into e-commerce for many merchants.

A second option is for the merchant to open a boutique on a platform such as the eBay™ platform or the like. Using such a platform, the merchant may somewhat maintain his identity and manage his on-line inventory. However, a deficiency with a platform such as the eBay™ platform is that it uses old technology that is ill suited to new tendencies/fads on the Web and cannot easily be adjusted to improve the user experience. Also, in the majority of cases, the merchant may not accept payments other than through PayPal™ and must assume all responsibilities related to shipping the ordered articles by opening accounts with carriers (such as Canada Post™, Purolator™, UPS™ etc .). Moreover, a new merchant on the eBay™ platform faces a huge challenge in order to stand out since there are several thousands of PowerSellers™ merchants, who have already developed a reputation and a certain amount of goodwill with clients. Several potential clients may be reluctant to make purchases from new merchants who have not yet been vetted by other customers and have not yet proved their reliability in terms of efficiency in delivery and product quality. Another problem with platforms such as the eBay™ platform is that purchases made from different merchants require separate transactions to be performed for each merchant. This implies increased time spent by the customer to enter what frequently amounts to redundant information. Another deficiency with platforms such as eBay™ is that the user's experience is often inconsistent from one merchant to the other. Each merchant has its own delivery methods, delays and follow-ups. As a result, a buyer may have several different experiences, some of which may leave the buyer feeling unsatisfied with his buying experience through this platform. A customer who has a negative experience buying from one merchant on the eBay™ platform may be reluctant to make another purchase on the eBay™ platform even if such purchase would be made through a different merchant.

A third option is for the merchant to open a boutique on a platform such as the one provided by the Amazon™ platform. However, this is may not be advantageous for most merchants as Amazon is also a merchant for all types of products. As a result, merchants using the Amazon™ platform sometimes compete head-to-head with Amazon for similar product offerings. An additional deficiency of a platform such as the one provided by the Amazon™ platform is that third party merchants are given almost no visibility, which prevents such merchants from fully developing their image on the web. Moreover, in a manner similar to the eBay™ platform, the merchant must open a transporter account with a transporter entity and negotiate delivery prices on his own. A merchant with a low sales volume may not be able to stand out with competitive delivery prices. The merchant must also open his own merchant payment accounts, if he chooses to accept credit or debit card payments, and must manage the transactions himself.

Another option is for the merchant to opt for solutions of the type offered by the Shopify™ or Volusion™ platforms. These companies offer merchants the possibility of creating an online website with shopping carts by using a few simple steps for a monthly fee varying from $20 to $180 depending on the selected package. Once the website is created, it is placed in a sub-domain or unique domain. However, merchants using such services must open their own payment accounts if they choose to accept credit or debit card payments, they must manage their transactions themselves through their website and must also manage delivery related functions by once more opening transporter accounts with carriers. In both cases, merchants must manage their own publicity in order to attract clientele to their sub-domain or to the site they have created. Furthermore, the merchant must on his own build fidelity and trust with his customers.

As will be appreciated, solutions of the type described above require a merchant desirous of having an e-commerce site to open an actively manage multiple accounts in order to be in a position to establish an on-line store, for instance:

1. A merchant account to create a shopping cart (to manage inventory) 2. One or more payment accounts (to process credit card payments, PayPal™ and the like).

For example in order to accept credit card payments, the merchant would typically need to open and negotiate a payment account with a company (such as Moneris™). This may take between 10 days and 4 weeks and requires a credit check. In addition, if the merchant want to accept payment through PayPal™, a PayPal™ account would also need to be opened.

3. One or more transporter accounts (for example UPS™, Canada Post™, Purolator™).

Typically opening a transporter account involves contacting a transporter company, such as Canada Post™, in order to open an account and negotiate prices based on sales predictions. In addition, if the merchant wants to support different transporters (for example to have the option of providing express and regular delivery), each transporter must be contacted individually and separately to open separate accounts.

4. An e-mail account to communicate by email with customers.

Once a merchant has an on-line store that is up and running, in a typical process, in order to process an order, the merchant must obtain information relative to the order in the shopping cart (date of order, product identification of the product sold, quantity of products, client identification, chosen carrier for delivery, amount of transaction), process payment information through his payment account, provide the order information to his transporter account (name of client, client's address, client's telephone number, order number, weight and dimensions of the product to be delivered, type of delivery, and selected services) in order to create and print a shipping label. Finally, the merchant would typically send an email confirmation to the customer in order to give the customer a tracking number to follow-up on their order.

The currently available tools of the type described above for creating and managing operations related to online transactions are costly and cumbersome to create and operate and as such are not well suited for many businesses, in particular smaller merchants, for which an on-line commercial presence may be beneficial.

In light of the above, it is clear that there is a need in the industry to provide tools for facilitating the creation of on-line stores and for managing the payment and delivery processes that alleviate at least in part the deficiencies associated with currently available tools. SUMMARY

In a first aspect, the invention relates to a system implementing a common marketplace wherein customer account information, customer authentication functions, payment processing functions/services and/or pick-up and delivery coordination services may be shared across multiple independent merchants that are members/subscribers of the common marketplace.

In some specific implementations, a common marketplace transporter account may be shared between multiple independent member merchants in the common marketplace when conducting transactions with a transporter entity to arrange for delivery of ordered products. In such implementations, the system implements a transporter account reconciliation process to attribute transportations costs incurred in the common marketplace transporter account to respective merchant accounts, the merchant accounts being associated with respective independent member merchants in the common marketplace.

An advantage of using a transporter account associated with the common marketplace is that it relieves member merchants from the burden (and associated costs) of having to create and manage their own transporter accounts with the transporter entity (such as UPS™, Purolator™, Federal Express™ (FedEx™), Canada Post™ and the like).

Another advantage of using a transporter account associated with a common marketplace is that it may allow, for example, more advantageous shipping rates to be negotiated with the transporter entity since the common marketplace including a plurality of member merchants is likely to have a greater volume of shipment than any individual member merchant.

In some specific implementations, a common marketplace payment account may be shared between multiple independent member merchants in the common marketplace when conducting transactions with a financial services entity to arrange for payment of ordered products. In such implementations, the system implements a payment account reconciliation process to attribute payments made in connection with purchased products to respective merchant accounts, the merchant accounts being associated with respective independent member merchants in the common marketplace.

An advantage of using a payment account associated with the common marketplace is that it relieves member merchants from the burden (and associated costs) of having to create and manage their own payment accounts with the financial services entity (such as Optimal Payments™, Pivotal Payments™, Beanstream™, Chase Paymentech™, PayPal™ or the like).

In accordance with another aspect, the invention relates to a method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace. The method is implemented by a system including at least one programmable processor and comprises receiving over the computer network a new order from a computing device associated with a customer, the new order specifying a product originating from a specific member merchant amongst the member merchants in the common marketplace. The method also comprises processing the new order to cause at least part of the new order to be fulfilled. The processing of the new order includes communicating with the specific member merchant in the common marketplace to convey receipt of an order involving the specific member merchant. The method also comprises, following receipt of a communication from the specific member merchant conveying that the product specified by the new order is ready for pick-up, communicating with a transporter entity for arranging pickup of the product originating from the specific member merchant specified by the new order from a pick-up location associated with the specific member merchant.

In a specific implementation, arranging pickup of the product includes using a transporter account with the transporter entity, the transporter account being associated with the common marketplace.

In accordance with a specific implementation, the step of communicating with the specific member merchant to convey the receipt of the order involving the specific member merchant includes transmitting an electronic notification message to the specific member merchant. The electronic notification message transmitted may include information conveying the product originating from the specific member merchant specified by the new order or, alternatively, may simply convey that a new order involving the specific member merchant has been placed in the common marketplace thereby prompting the specific member merchant to access his merchant account to view information pertaining to the new order. The electronic notification message may be transmitted by the system in any suitable manner including, but not limited to, an e-mail message sent to an address associated with the specific member merchant, a short message service (SMS) message, a facsimile and a voice-messaging service. Optionally, in cases where the format of the electronic notification message allows it, an electronic link (or web-address) to a merchant web-page in the common marketplace may be included as part of the electronic notification message such that activation of the electronic link allows the merchant to access his merchant account in the common marketplace.

In a specific non-limiting example of implementation, the transporter entity with which pickup of the product is arranged may be a third party transporter (for example UPS™, Purolator™, Federal Express™ (FedEx™), Canada Post™ and the like) or alternatively may be a transportation service offered by the specific member merchant thereby allowing the specific merchant to directly arrange for transportation of the product to the customer. In another specific non-limiting example of implementation, the transporter entity with which pickup of the product is arranged is associated with an on-site pickup operation thereby allowing the customer to pick-up the product in person at the pick-up location associated with the specific member merchant.

In a specific implementation, the method further comprises causing a merchant interface to be displayed on a display device associated with the specific merchant, the merchant interface conveying a listing of outstanding deliveries involving the specific merchant. The listing of outstanding deliveries includes a plurality of entries at least one of which is associated with the new order. Through the merchant interface, control options are displayed for enabling the specific merchant to:

a. select an outstanding delivery from the listing of outstanding deliveries; and b. provide information conveying that at least one product specified by the selected outstanding delivery is ready for pick-up.

The control options presented may also allow the specific merchant to print a shipping label for use in shipping the product in the selected outstanding delivery. In a specific example of implementation, processing the new order further includes communicating with a payment server module to arrange for payment of the new order by the customer and reconciling an account associated with the specific member merchant to reflect payment by the customer of the product originating from the specific member merchant specified in the new order.

In a specific example of implement, the product originating from the specific member merchant specified by the new order is a first product originating from a first specific member merchant. The new order further specifies a second product originating from a second specific member merchant amongst the member merchants in the common marketplace, the second specific member merchant being distinct from the first specific member merchant. In this specific example, the processing of the new order includes communicating with the first specific member merchant in the common marketplace to convey receipt of an order involving the first specific member merchant as well as communicating with the second specific member merchant in the common marketplace to convey receipt of an order involving the second specific member merchant.

Advantageously, according to this specific example of implementation, a customer may place a single order including products originating from two or more distinct merchants.

In a first specific example, the method includes:

a) following receipt of a communication from the first specific member merchant conveying that the first product specified by the new order is ready for pick-up, communicating with the transporter entity for arranging pickup of the first product from a pick-up location associated with the first specific member merchant; and

b) following receipt of a communication from the second specific member merchant conveying that the second product specified by the new order is ready for pickup, communicating with the transporter entity for arranging pickup of the second product from a pick-up location associated with the second specific member merchant.

The arranging pickup of the first and second products may each include the use of a same transporter account with the transporter entity, the transporter account being associated with the common marketplace. In a second (alternative) specific example, the transporter entity with which the system communicates for arranging pickup of the first product originating from the first specific member merchant is a first transporter entity. The method comprises, following receipt of a communication from the second specific member merchant conveying that the second product specified by the new order is ready for pick-up, communicating with a second transporter entity for arranging pickup of the second product originating from the second specific member merchant specified by the new order from a pick-up location associated with the second specific member merchant, wherein the second transporter entity is distinct from the first transporter entity.

Advantageously, according to this specific implementation, the coordination for the pick-up and delivery is performed by the programmed system rather than individually by the merchants themselves. More specifically, the programmed system communicates with the specific member merchants to advise them of the respective products ordered as well as communicates with one or more transporter entities to arrange for pick-up of products from the respective merchants. This obviates the requirement for the merchants to deal with one or more transporter entities directly. In a specific example of implementation, the programmed system allows for the coordination of pickup and delivery to be performed through a number of different transporters in a manner that is transparent to the merchant by providing the merchant with a uniform merchant interface and by providing suitable APIs for the respective transporter entities that the common marketplace system supports.

In a specific implementation, the processing of the new order further includes communicating with a payment server module to arrange for payment of the new order by the customer, the communication with the payment server module being performed using a payment account associated with the common marketplace. The method also includes performing an account reconciliation process. In a case where the new order specifies a first product originating from a first specific member merchant and a second product originating from a second specific member merchant, the account reconciliation process includes:

i. reconciling a first account associated with the first specific member merchant to reflect payment of the first product by the customer; ii. reconciling a second account associated with the second specific member merchant to reflect payment of the second product by the customer.

In a specific example of implementation, an order confirmation message is transmitted to the customer. The timing of when the order confirmation may be transmitted may vary from one application to the other. In a non-limiting example, the order confirmation message may be transmitted after the new order is received and a payment has been successful processed. Alternatively, the order confirmation message may be transmitted substantially concurrently with the communicating with the specific member merchant in the common marketplace to convey receipt of an order involving the specific member merchant. Alternatively still, the order confirmation message may be transmitted following receipt of the communication from the specific member merchant conveying that the product specified by the new order is ready for pick-up. Alternately, multiple order confirmation messages may be sent to the customer at any of the times presented above or at other times to convey to the user progress in the processing of the new order.

Optionally, the method further comprises maintaining records of unfulfilled orders previously placed by customers in the common marketplace and providing an order modification interface accessible over the computer network. The order modification interface is configured for enabling the customer to view unfulfilled prior orders placed by the customer and for providing a user operable control for enabling the customer to issue a command to effect a modification to an unfulfilled prior order. In specific implementations, the order modification interface may provide input options for allowing the customer to perform, for example, at least one of:

i. removing a product originating from a specific member merchant in an unfulfilled prior order;

ii. adding a new product to an unfulfilled prior order;

iii. changing a transportation parameter associated with an unfulfilled prior order;

iv. changing a billing address associated with an unfulfilled prior order.

In accordance with another aspect, the invention relates to a method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace. The method is implemented by a system including at least one programmable processor and comprises receiving over the computer network orders from computing devices associated with customers, the orders specifying products originating from member merchants amongst the member merchants in the common marketplace. The method further comprises processing the orders to cause at least part of the orders to be fulfilled. The processing of the orders includes communicating with a remote transporter entity to arrange for pick-up and delivery of ordered products originating from member merchants in the common marketplace, wherein a same common marketplace transporter account is used when arranging for pick-up and delivery through the remote transporter entity of products originating from at least two member merchants in the common marketplace. The processing of the orders also includes communicating with a remote financial services entity to arrange for payment of ordered products originating from merchants member in the common marketplace, wherein a same common marketplace payment account is used when arranging for payment of products originating from at least two member merchants in the common marketplace. The processing of the orders also includes performing a reconciliation process between the common marketplace payment account and accounts associated with the member merchants in the common marketplace to reflect the payments of ordered products.

In accordance with another aspect, the invention relates to a method for facilitating commercial transactions in a common marketplace, the method being implemented by a programmable system including at least one programmable processor. The method comprises providing a common marketplace transporter account associated with a transporter entity and providing a common marketplace payment account associated with a financial services entity. The method further comprises processing orders specifying one or more products originating from a specific merchant in the common marketplace to cause at least part of the orders to be fulfilled. The processing of the orders including:

i. using the common marketplace transporter account to arrange for pickup of products originating from the specific merchant by the transporter entity; ii. using the common marketplace payment account to arrange for payment of the orders through the financial services entity;

iii. performing a reconciliation process between the common marketplace payment account and an account associated with the specific merchant to reflect payment of the one or more products originating from the specific merchant.

In accordance with another aspect, the invention relates to a computer program product, tangibly stored on one or more tangible computer readable storage media, for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace. The program product comprises instructions that, when executed, cause a programmable system including at least one programmable processor to perform the above-described method.

In accordance with another aspect, the invention relates to a computing system for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace. The computing system comprises a memory unit for storing information related to one or more member merchants in the common marketplace and at least one processor programmed with software, which when executed, configures the at least one processor for implementing the above-described method.

In accordance with another aspect, the invention relates to a method for facilitating creating e- commerce points of transaction in a common marketplace, the method implemented by a programmable system including at least one programmable processor. The method comprises presenting a merchant interface on a display device associated with a specific merchant, the merchant interface providing the specific merchant with a plurality of user interface tools for specifying a plurality of information elements associated with the specific merchant The method also comprises providing a user operable control at the display device associated with the specific merchant, the user operable control allowing the specific merchant to issue to the programmable system a command to create an account for the specific merchant in the common marketplace at least in part based on information provided by the specific merchant through the user interface tools provided by the merchant interface. The method further comprises processing the command issued by the specific merchant to create the account for the specific merchant in the common marketplace to create an e-commerce point of transaction for the specific merchant. The created e-commerce point of transaction for the specific merchant is associated with a common marketplace transporter account associated with a transporter entity, the common marketplace transporter account being shared between different merchants having accounts in the common marketplace. The created e- commerce point of transaction for the specific merchant is also associated with a common marketplace payment account associated with a financial services entity, the common marketplace payment account being shared between different merchants having accounts in the common marketplace. In use, at least some orders to purchase products placed through the e-commerce point of transaction for the specific merchant are processed at least in part using the common marketplace transporter account to arrange for pickup of the products from the specific merchant and using the common marketplace payment account to arrange for payment of the products.

In a specific example of implementation, the user interface tools provided through the graphic display may comprise an inventory details interface tool providing user editable controls for allowing the specific merchant to provide information related to products to be offered for sale by the specific merchant through the e-commerce point of transaction. The user interface tools may alternately/also comprise a new account creation user interface tool enabling entry of information for identifying the specific merchant, such as for example a merchant user name and a merchant password.

In a specific example of implementation, the user interface tools provided through the graphic display may alternately/also comprise a delivery details user interface tool. The delivery details user interface tool may enable entry of information conveying a location where orders can be picked-up from the specific merchant by a transporter entity and, optionally, timing information conveying when orders can be picked up from the specific merchant by the transporter entity. The delivery details user interface tool may also enable selection by the specific merchant of the transporter entity amongst a set of available transporter entities supported by the common marketplace. In such specific implementation, common marketplace transporter accounts may be associated with respective transporter entities in the set of available transporter entities supported by the common marketplace.

Optionally, in cases where the specific merchant has the capacity to offer "self-delivery" (where the merchant himself acts as the transporter entity) or where the specific merchant would like to allow for the customer to pick-up the ordered product in person (pick-up on location) at a locations associated with the merchant, the programmed system allows for the coordination of pick-up and delivery to be performed through the specific merchant himself by treating the merchant (or the on- site pick-up) as another transporter entity in the set of available transporter entities.

In a specific example, the delivery details user interface tools enable selection by the specific merchant of a first transporter entity and of at least a second transporter entity amongst a set of available transporter entities supported by the common marketplace, a first common marketplace transporter account being associates with the first transporter entity and a second common marketplace transporter account being associated with the second transporter entity. In such example, the e-commerce point of transaction for the specific merchant created by the processing of the command issued by the merchant would be able to provide delivery through either one of the first and second transport entities (for example one of the entities may be a regular delivery service and the other may be an express service). In particular, the e-commerce point of transaction for the specific merchant would be associated with:

a. the first common marketplace transporter account associated with the first transporter entity, the first common marketplace transporter account being shared between different merchants having accounts in the common marketplace; and b. the second common marketplace transporter account associated with the second transporter entity, the second common marketplace transporter account being shared between different merchants having accounts in the common marketplace.

In use at least some orders to purchase products placed through the e-commerce point of transaction for the specific merchant would be processed at least in part using the first common marketplace transporter accounts to arrange for pickup of products from the specific merchant while at least some other orders to purchase products placed through the e-commerce point of transaction for the specific merchant would be processed at least in part using the second common marketplace transporter accounts to arrange for pickup of products from the specific merchant.

In accordance with a specific implementation, the user interface tools comprise a payment details interface tool enabling selection by the specific merchant of the financial services entity amongst a set of available financial services entities supported by the common marketplace. In such specific implementation, common marketplace payment accounts may be associated with respective financial services entities in the set of available financial services entities supported by the common marketplace. In a specific example, the payment details user interface tools enable selection by the specific merchant of a first financial services entity and of at least a second financial services entity amongst a set of available financial services entities supported by the common marketplace. A first common marketplace payment account is associated with the first financial services entity and a second common marketplace payment account is associated with the second financial services entity. In such example, the e-commerce point of transaction for the specific merchant created by the processing of the command issued by the merchant would allow payments to be processed through either one of the first and second financial services entities (for example one of the entities may be PayPal and the other may be Chase Paymentech ). In particular, the e-commerce point of transaction for the specific merchant would be associated with:

a. the first common marketplace payment account associated with the first financial services entity, the first common marketplace payment account being shared between different merchants having accounts in the common marketplace;

b. the second common marketplace payment account associated with the second financial services entity, the second common marketplace payment account being shared between different merchants having accounts in the common marketplace.

In use, at least some orders to purchase products placed through the e-commerce point of transaction for the specific merchant would be processed at least in part using the first common marketplace payment account to arrange for payment of products in the at least some orders while at least some other orders to purchase products placed through the e-commerce point of transaction for the specific merchant would be processed at least in part using the second common marketplace transporter accounts to arrange for payment of products in the at least other orders.

In accordance with another aspect, the invention relates to a computer program product, tangibly stored on one or more tangible computer readable storage media, for facilitating creating e- commerce points of transaction in a common marketplace. The computer program product comprises instructions that, when executed, cause a programmable system including at least one programmable processor to perform the above-described method.

In accordance with another aspect, the invention relates to a computing system for facilitating creating e-commerce points of transaction in a common marketplace. The computing system comprises a memory unit for storing information related to one or more member merchants in the common marketplace and at least one processor programmed with software, which when executed, configures the at least one processor to implement the above described method.

In accordance with another aspect, the invention provides a method for facilitating commercial transactions involving purchase of products over a computer network in a common marketplace, the method being implemented by a system including at least one programmable processor. The method comprises maintaining orders previously placed by customers in a common marketplace, at least some previously placed orders including products originating from two or more merchants in the common marketplace. The method also comprises providing a merchant interface accessible over a computer network. The merchant interface is configured for enabling a specific merchant to view a listing of outstanding deliveries including a plurality of entries associated with ordered products originating from the specific merchant and for enabling the specific merchant to providing information to the system implementing the common marketplace conveying that a product associated with an entry in the listing of outstanding deliveries is ready for pick-up. The method further comprising, following receipt of information from the specific merchant conveying that a specific product associated with a specific entry in the listing of outstanding deliveries is ready for pick-up, communicating with a transporter entity to arrange for pick-up of the specific product from a pick-up location associated with the specific merchant.

In a specific implementation, arranging pickup of the specific product includes using a transporter account with the transporter entity, the transporter account being associated with the common marketplace.

In a specific implementation, the method further comprises, following receipt of a message confirming delivery of the specific product, performing an account reconciliation process to reconcile an account associated with the specific merchant to reflect a payment associated with the specific product. In practical implementations, the message confirming delivery of the specific product will originate from the transporter entity, however other embodiments may receive such confirmation from the specific merchant and/or from the customer. Since confirmation of delivery may be used to trigger a payment to the specific merchant, it may not be desirable to rely on the specific merchant's confirmation alone without some other type of verification. For example, in cases where the transporter entity is a delivery service provided by the specific merchant, an additional verification mechanism may be used to ensure that the customer has indeed received the specific product. For example a code may be provided to the customer by the system when the order is first placed (or in a confirmation message following the placing of the order). When the specific product is delivered, the customer provides the code to the merchant (or his transporter entity) and this code is used as part of the message confirming delivery of the specific product.

In accordance with a specific implementation, the specific product conveyed by the message received from the specific merchant is associated with specific transportation parameters. In this specific implementation, the step of communicating with the transporter entity to arrange for pickup of the specific product can be performed at least in part based on the specific transportation parameters associated with the specific product.

In a specific implementation, a first entry in the listing of outstanding deliveries is associated with transportation parameters conveying a first transporter entity and a second entry in the listing of outstanding deliveries is associated with transportation parameters conveying a second transporter entity. The method comprises, following receipt of information from the specific merchant conveying that a product associated with the first entry is ready for pick-up, communicating with the first transporter entity to arrange for pick-up of the product associated with the first entry from the pick-up location associated with the specific merchant and, following receipt of information from the specific merchant conveying that a product associated with the second entry is ready for pick-up, communicating with the second transporter entity to arrange for pick-up of the product associated with the second entry from a pick-up location associated with the specific merchant.

In a specific implementation, the merchant interface includes user operable controls for enabling the specific merchant:

a. to print a first shipping label for shipping the product associated with the first entry, the first shipping label being derived at least in part based on the transportation parameters conveying the first transporter entity;

b. to print a second shipping label for shipping the product associated with the second entry, the second shipping label being derived at least in part based on the transportation parameters conveying the second transporter entity. In accordance with another aspect, the invention relates to a computer program product, tangibly stored on one or more tangible computer readable storage media, for facilitating commercial transactions involving purchase of products over a computer network in a common marketplace. The program product comprises instructions that, when executed, cause a programmable system including at least one programmable processor to perform the above-described method.

In accordance with another aspect, the invention relates to a computing system for facilitating commercial transactions involving purchase of products over a computer network in a common marketplace. The computing system comprises a memory unit for storing information related to one or more member merchants in the common marketplace and at least one processor programmed with software, which when executed, configures the at least one processor for implementing the above described method.

In accordance with another aspect, the invention relates to a method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, the method being implemented by a system including at least one programmable processor. The method comprises maintaining orders previously placed by customers in a common marketplace and providing an order modification interface accessible over a computer network. The order modification interface is configured for enabling a specific customer to view unfulfilled prior orders placed by the specific customer and provides a user operable control for enabling the specific customer to issue a command to effect a modification to an unfulfilled prior order placed in the common marketplace. The method also comprises communicating with a specific member merchant to convey that an order modification has been made following receipt of a message from the specific customer conveying a command to effect a specific modification to a specific unfulfilled prior order, the specific unfulfilled prior order specifying a specific product originating from the specific member merchant amongst the member merchants in the common marketplace and the specific modification affecting the specific product.

In a specific implementation, the order modification interface provides input options allowing the customer to perform at least one of: i. removing a product originating from a specific member merchant in an unfulfilled prior order;

ii. adding a new product to an unfulfilled prior order;

iv. changing a billing address associated with an unfulfilled prior order.

Advantageously, providing an order modification interface provides some flexibility to the customer who can make a modification to a previously placed order that it yet unfulfilled by a merchant and allows the merchant to be notified of such modification before a product in an unfulfilled order is actually shipped. For example i) in cases where a product is removed from the order, the product does not need to be shipped (avoids having to then process a return from the customer); ii) in cases where a new product is added, a same shipment can be used to ship the original product and the new product (this reduces shipping costs, which is of interest to the customer and/or the merchant depending who is paying for shipping); iii) in cases where a change in transportation parameters associated with the order is provided, this may allow the shipping method to be modified after the order is originally placed, for example this may allow a customer to change his/her mind after placing an order from a courier delivery to a "on-site" pick-up or vice- versa or, alternatively, this may allow the customer to specify a different delivery address; iv) in cases where a change in the billing address associated with an unfulfilled prior order is provided, this allows the billing address to be modified as desired by the customer.

In a specific example of implementation, the above described methods (as well as associated computer program products and systems) provide functionality of the type described above while allowing individual member merchants in the marketplace to maintain their image/identity through the use of individual websites. Customers wishing to access an e-commerce points of transaction for a specific merchant may do so either by accessing the specific website of the specific merchant directly (by providing the website's URL for the e-commerce points of transaction) or may access the specific website through a link provided on a website associate with the common marketplace.

Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying Figures. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a system implementing a common marketplace comprising a marketplace server in accordance with a specific example of implementation of the invention;

Figure 2 shows a functional diagram of the marketplace server depicted in Figure 1 according to a specific example of implementation;

Figure 3A shows a graphical representation of multiple common marketplace transporter accounts being mapped to a member merchant account in the common marketplace implemented by the system shown in Figure 1 ;

Figure 3B shows a graphical representation of a same common marketplace transporter account being mapped to a plurality of member merchant accounts in the common marketplace implemented by the system shown in Figure 1 ;

Figure 4A shows a graphical representation of multiple common marketplace payment accounts being mapped to a member merchant account in the common marketplace implemented by the system shown in Figure 1 ;

Figure 4B shows a graphical representation of a same common marketplace payment account being mapped to a plurality of member merchant accounts in the common marketplace implemented by the system shown in Figure 1 ;

Figure 5 is a flow diagram of a process for facilitating commercial transactions using the common marketplace implemented by the system shown in Figure 1 in accordance with a specific example of implementation of the invention;

Figure 6 is a flow diagram of a process for coordinating between a financial services entity and a customer to arrange for payment of an order in the common marketplace implemented by the system shown in Figure 1 in accordance with a specific example of implementation of the invention;

Figure 7A is a flow diagram of a process for coordinating pick-up and delivery of an order placed in the common marketplace implemented by the system shown in Figure 1, the order involving a single member merchant, in accordance with a specific example of implementation of the invention;

Figure 7B is a flow diagram of a process for coordinating pick-up and delivery of an order placed in the common marketplace implemented by the system shown in Figure 1 , the order involving multiple member merchants, in accordance with a specific example of implementation of the invention;

Figure 7C is a variant of the process for coordinating pick-up and delivery of an order placed in the common marketplace depicted in Figure 7A;

Figure 8 shows a process implemented by the marketplace server depicted in Figure 1 for facilitating fulfilling orders by a member merchant in the common marketplace in accordance with a specific example of implementation of the invention;

Figure 9 shows a process for facilitating fulfilling orders by a specific member merchant in the common marketplace implemented by the system shown in Figure 1 in accordance with a specific example of implementation of the invention;

Figure 10 is a flow diagram of a process for facilitating commercial transactions using the common marketplace implemented by the system shown in Figure 1 providing order modification capabilities in accordance with a specific example of implementation of the invention;

Figures 1 1 A, 1 I B, 1 1 C, 1 I D and HE show examples of merchant interface pages for enabling specific member merchants to manage orders placed in the common marketplace implemented by the system shown in Figure 1 in accordance with a specific example of implementation of the invention; Figure 12 shows a flow diagram of a process for facilitating the creation of an e-commerce point of transaction for a new member merchant in the common marketplace implemented by the system shown in Figure 1 in accordance with a specific example of implementation of the invention;

Figures 13, 14A, 14B, 15A, 15B, 16, 17A and 17B show examples of some merchant interface pages for enabling a new member merchant to create an e-commerce point of transaction in the common marketplace implemented by the system shown in Figure 1 in accordance with a specific example of implementation of the invention;

Figure 18 is a block diagram of a computing apparatus suitable for implementing a marketplace server in a system of the type depicted in Figure 1 in accordance with a specific non-limiting example of implementation of the invention.

In the drawings, embodiments of the invention are illustrated by way of example. It is to be expressly understood that the description and drawings are only for purposes of illustration and as an aid to understanding, and are not intended to be a definition of the limits of the invention.

DETAILED DESCRIPTION

In accordance with one embodiment of the present invention, there is provided a common marketplace system which aims to provide both customer user-friendliness and ease of setup and maintenance for a plurality of merchants.

An embodiment of a system 100 providing a common marketplace is shown in Figure 1. As depicted, the system 100 includes a marketplace server 150 which, in order to facilitate commercial transactions involving purchase of products from member merchants in a common marketplace, interacts over a computer network with different entities in the system 100. The marketplace server 150, which may include one or more programmable processors, implements a method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in the common marketplace. In the example shown in Figure 1 , the marketplace server 150 interacts with merchants computing units 160(a-c), a customer computing unit 170, a financial services server 190 and a transporter entity server 180. It is to be noted that in practical implementations of the system 100, the marketplace server 150 may interact with many other entities, which have been omitted from Figure 1 for the purpose of simplicity. The marketplace server 150 may also implements a method for facilitating creation of e- commerce points of transaction for new member merchant in the common marketplace implemented by system 100, as will be described in further detail in the present document.

Customer computing unit 170

The customer computing unit 170 is a device that a user would typically use to access the Internet and would generally be in the form of a personal computer, although other types of computing units may also be used including laptops, notebooks, hand-held computers, set top boxes, tablets, smartphones and the likes. The computing unit 170 communicates with the marketplace server 150 over a computer network (not shown in the figures). The connection over the network may be a permanent connection, or alternatively, the computing unit 170 may occasionally connect to the network through the use of a WiFi connection using suitable devices such as a modem for example. The customer computing unit 170 is programmed with software implementing a conventional browser (e.g. Internet Explorer™, Mozilla Firefox™, Google Chrome™, Safari™ and the like) allowing the customer to view web pages on the network including web pages implemented by computer programs stored in the marketplace server 150. It is to be noted that, while for the purpose of simplicity the embodiment depicted in Figure 1 shows a single customer computing unit 170, alternate practical implementations of the marketplace server 150 may communicate with any number of customer computing units associated with respective potential customers the member merchants in the common marketplace.

Merchant computing units 160a-c

Merchant computing unit 160a is a device that a merchant would typically use to access a computer network, including a public computer network such as the Internet. Such device would generally be in the form of a personal computer, although other types of computing units may also be used including laptops, notebooks, hand-held computers, tablets, smart phones and the likes. In a manner similar to the customer computing unit 170, the merchant computing unit 160a communicates with the marketplace server 150 over a computer network (not shown in the figures). The merchant computing unit 160a is programmed with software implementing a conventional browser (e.g. Internet Explorer™, Mozilla Firefox™, Google Chrome™, Safari™ and the like) allowing the merchant to view web pages including web pages implemented by computer programs stored in the marketplace server 150. Merchant computing unit 160a is associated with a specific member merchant in the common marketplace implemented by system 100. Merchant computing units 160b and 160c are similar to merchant computing unit 160a and are also each associated with respective member merchants in the common marketplace implemented by system 100. The merchant computing units 160a-c may also be associated with printing devices for allowing merchants to print shipping labels provided through the marketplace server 150. A printer device 162 is shown in connection with merchant computing unit 160c however it will be appreciated that each merchant computing unit may be associated with its own respective printed device. It is to be noted that, while the embodiment depicted in Figure 1 shows only three merchant computing units 160a 160b and 160c, alternate practical implementations of the marketplace server 150 may communicate with any number of merchant computing units, each merchant computing unit being associated with a respective merchant in the common marketplace.

Transporter entity server 180

The transporter entity server 180 is an external system that would typically be associated with an external transporter entity such as UPS™, Purolator™, FedEx™, Canada Post™ and the like. The transporter entity server 180 may also be associated with the merchant entity in a situation where the merchant entity provides a delivery service and/or allow on-site pick-up of packages. The transporter entity server 180 exchanges messages with the marketplace server 150 related to the pick-up and delivery of packages including for example but not limited to: a) pick-up requests indicating items to pick-up, locations from which they are to be picked up and where they are to be delivered; b) delivery notifications. The specific manner in which the transporter entity server 180 is implemented may vary from one transporter to the other and is not critical to the invention and thus will not be described further here. It is to be noted that, while for the purpose of simplicity the embodiment depicted in Figure 1 shows a single transporter entity server 1 80, alternate practical implementations of the marketplace server 150 may communicate with any number of transporter entity servers, each transporter entity server being associated with a respective transporter entity. Financial services server 190

The financial services server 190 is an external system that would typically be associated with a financial services entity such as Optimal™ Payments, Beanstream™, Chase Paymentech™, PayPal™ or the like. The financial services server 190 exchanges messages with the marketplace server 150 related to payments made by a customer 140 in connection with a specific merchant that is a member/subscriber of common marketplace. The specific manner in which the financial services server 190 is implemented may vary from one financial services entity to the other and is not critical to the invention and thus will not be described further here. It is to be noted that, while for the purpose of simplicity the embodiment depicted in Figure 1 shows a financial services server 190, alternate practical implementations of the marketplace server 150 may communicate with any number of financial services servers, each financial services server being associated with a respective financial services entity.

Marketplace server 150

The marketplace server 150 implements various functionality associated with the common marketplace and exchanges messages with the other components in the system shown in Figure 1 . Amongst other, the marketplace server 1 50 manages the processing of orders (commercial transactions) on behalf of the merchants that are members of the common marketplace. In connection with the processing of transactions, the common marketplace server 150 is configured for coordinating the different communications between the merchants computing units 160(a-c), a customer computing unit 170, a financial services server 190 and a transporter entity server 180. In accordance with a specific implementation, the common marketplace server 150 implements various functions, including functions that are shared amongst the member merchants in the common marketplace system 100. By providing these shared functions, the individual merchants that are members of the common marketplace system 100 are relieved from the burden of setting up and maintaining at least some functionality related to operating e-commerce points of transaction.

From the perspective of merchants computing units 160(a-c), the fact that functionality may be shared among many different merchants is substantially transparent, except for the additional benefits that may be derived from sharing resources, as will be described hereinafter. Similarly, from the perspective of the customer 140 making purchases from merchants in the common marketplace system 100, it may be substantially transparent that the tools that implement, for example, payment processing functions and pick-up and delivery functions are not implemented by the individual merchants from which purchases are made. In specific implementations, the marketplace server 150 may provide one of more of the following services:

1. Shared payment processing functions/services. Payment processing functions/services can be shared across multiple independent merchants that are members/subscribers of the common marketplace. In a specific example, a financial transaction for a specific order placed by a customer can be performed between the common marketplace server 150 and the financial services server 190 using a common marketplace payment account irrespective of the merchant(s) from which products in the specific order originate. In order for the merchants to receive payments for their products, the server 150 is programmed to reconcile the payments between the one or more merchants from which products in the specific order originate.

2. Shared pick-up and delivery coordination services. Pick-up and delivery coordination services can be shared across multiple independent merchants that are members/subscribers of the common marketplace system 100. In a specific example, the pick-up and delivery coordination services can be performed between the common marketplace server 150 and the transporter entity server 180 using a common transporter account associated with the common marketplace, irrespective from which merchant(s) products are to be picked up. This allows for example more advantageous shipping rates to be negotiated since the common marketplace system 100 is likely to have a greater volume of shipment than any individual merchant that is a member of the common marketplace system 100. The common marketplace server 150 may also be programmed to attribute shipping fees to the one or more merchants from which products in the order originate.

3. Added visibility for independent merchants that are members/subscribers of the common marketplace system 100. In a non-limiting example, the common marketplace server 150 is programmed to implement a centralized access page which allows a customer using customer computing module 170 to access websites associated with different independent merchants that are members/subscribers of the common marketplace system 100. The centralized access page may display links (and optionally advertising) associated with the members/subscribers of the common marketplace system 150. In this manner, a small independent merchant who may have only a limited customer database may benefit from additional visibility when customers (including customers of other merchants in the common marketplace) access the centralized access page.

Shared customer account information between multiple independent merchants. Shared customer account information may allow authentication functionality to be shared amongst multiple member merchants. In this regard, a customer 140 using customer computing module 170 only needs to authenticate itself once during a session in the common marketplace to perform transactions with any merchant that is a member/subscriber of the common marketplace system 100, which in Figure 1 would include any of the merchants associated with merchant computing units 160a 160b and 160c. In addition, once a customer account has been created in connection with any one merchant in the common marketplace system 100 (for example by providing shipping address information, payment information and the like), such information does not need to be re-entered and can be used when conducting transaction with any other merchant in the common marketplace system 100. In addition to the above, the shared account information may allow, for example, designing and coordinating promotional campaigns for members/subscribers of the common marketplace system 100 that leverage customer account information obtained through multiple independent merchants. As such, a small independent merchant that may have only a limited customer database may benefit from additional visibility through marketplace server 150 through access to customer information for different merchants by running a campaign that benefits all (or a subset of) customers in the common marketplace system 100. Since customer information is often considered confidential, such campaigns can be executed by the common marketplace system 100 without providing direct access to customer information to the individual member merchants of the common marketplace system for which the campaign is being run. For example, information regarding a specific campaign for a specific merchant can be displayed on a centralized website associated with the common marketplace so that a customer 140 accessing the common marketplace through the centralized website would be exposed to this specific campaign irrespective of whether the customer is a customer of the specific merchant or of another merchant in the common marketplace system 100. Alternatively, targeted e-mail campaigns can be designed based on the purchase behavior of customers at respective merchants by using the purchase behavior of customers with one merchant to predict the purchase behavior for other merchants in the common marketplace. The specific design of targeted marketing campaigns is beyond the scope of present invention and thus will not be described further here.

A functional diagram of a specific implementation of the marketplace server 150 is shown in Figure 2. In the example shown, the common marketplace server 150 includes a number of functional modules including: a merchant accounts module 208, a customer accounts module 210, a transaction module 206, a finance module 204 and a delivery/transport coordinator module 202. In the example shown, the marketplace server 150 further includes a transporter reconciliation module 203 and a payment reconciliation module 205. The different modules 208 210 206 204 202 203 205 interact with one another as well as with entities external to the marketplace server 150, in order to provide various services associated with the common marketplace system 100 (shown in Figure 1).

Merchant accounts module 208

The merchant accounts module 208 coordinates interactions between the marketplace server 150 and member merchants using merchant computing units 160(a-c) (shown in Figure 1) and provides functionality for managing merchant accounts associated with multiple independent merchants that are members are the commonplace implemented by system 100 (shown in Figure 1).

In a specific implementation, the merchant accounts module 208 provides functionality for facilitating the creation of an e-commerce point of transaction for a new member merchant in the common marketplace, including creating a new merchant account. The merchant accounts module 208 also allows merchants that are already members of the common marketplace to make modifications to their existing e-commerce points of transaction. Examples of the type of processes and tools provided in part by the merchant accounts module 208 with regard to facilitating creation (and modification) of an e-commerce point of transaction will be described later on in the present document with reference to Figures 12, 13, 14A, 14B, 15A, 15B, 16, 17A and 17B.

In a specific implementation, the merchant accounts module 208 also provides functionality for facilitating the fulfilling of orders by merchants having merchant accounts in the common marketplace. In this regards, the merchant accounts module 208 provides functionality for maintaining listings of outstanding deliveries involving respective merchants in the common marketplace system 100 and provides tools for allowing the member merchants, through the used of merchant computing units 160a-c, to communicate with the common marketplace server 150 over a computer network to view and manage the entries in their respective listings of outstanding deliveries. Examples of the type of processes and tools provided in part by the merchant accounts module 208 with regard to facilitating the fulfilling of orders by member merchants in the common marketplace will be described later on in the present document with reference to Figures 8, 9 and 1 1A to 1 1 E.

The merchant accounts module 208 also provides website hosting functionality for the member merchants in the common marketplace. In this regard, website data is stored in the merchant accounts module 208 in connection with respective member merchants. Potential customers, using a customer computer module 170, may access a website associated with a particular merchant hosted by the marketplace server 150 in order to select products and conduct transactions with the member merchant through the common marketplace server 150.

The merchant accounts module 208 also includes a database of merchant accounts (not shown) for storing information associated with the respective member merchants in the common marketplace implemented by system 100. The database of merchant accounts stores various types of information that may be useful to facilitate conducting e-commerce transactions with member merchants. Such information may include, without being limited to:

Identification information for uniquely identifying respective member merchants and for communicating with the member merchants (including for example e-mail address information);

E-commerce point of transaction information including website data, inventory information and the like; and

Financial information including transaction information (credit/debit information (product payments, product re-imbursements, shipping charges)), banking information and the like;

A listing of outstanding deliveries involving the specific member merchant. The specific manner in which the merchant accounts module 208 is constructed and used is not critical and therefore will not be described in further detail here.

Customer accounts module 210

The customer accounts module 210 maintains information pertaining to customers of the common marketplace and provides functionality for managing customer accounts associated with multiple customers including maintaining listings order placed by respective customers (for example as part of an order history) and customer profile information. Customer profile information may include, for example, a customer identifier (username) and password, credit card information, delivery address and the like. An order history including unfulfilled, partly fulfilled and fully fulfilled orders may be stored in the customer accounts module in connection with the respective customer accounts. The customer accounts module 210 is in communication with the transaction module 206 to allow the customer accounts to be updated as new orders are placed and new customers are added to the common marketplace.

Advantageously, maintaining a customer profile in a centralized location shared by multiple merchants may improve the security of confidential customer data. In particular, a same customer account can be used from multiple merchants thereby eliminating the need for customer information, including payment information (e.g. credit card information) to be stored in multiple locations, thereby reducing risk that such confidential information may be compromised. In the described specific embodiment, personal confidential payment data is not kept at multiple merchants as it is not required since payment processing functionality is provided through the marketplace server 150.

Transaction module 206

The transaction module 206 coordinates interactions between the marketplace server 150 and customers using customers computing modules, such as customer computing module 170, in the common marketplace implemented by system 100.

In a specific implementation, the transaction module 206 provides functionality for facilitating commercial transactions involving the purchase of products over a computer network from member merchants in the common marketplace implemented by the system 100 shown in Figure 1. In this regards, the transaction module 206 provides functionality for allowing a customer 140 using a customer computing module 170 to place orders specifying one or more products originating from one or more merchants amongst the member merchants in the common marketplace and for coordinating various functions, including payment and pick-up and delivery functions, for allowing at least part of these orders to be fulfilled. The transaction module 206 may also update information stored in the customer accounts module 210 regarding orders previously placed by customer in the common marketplace. The transaction module 206 may also update information stored in the merchant accounts module 208 in connection with listings of outstanding deliveries associated with respective member merchants. Examples of the type of processes and tools provided in part by the transaction module 206 with regard to facilitating commercial transactions involving purchase of products over a computer network will be described throughout the present document and in particular with reference to Figures 5, 6, 7A, 7B, 7C and 10.

In a specific implementation, the transaction module 206 implements shopping cart logic enabling a customer using customer computing module 170 to select/remove products for purchase. In particular, the shopping cart logic implemented by the transaction module 206 is configured for allowing a customer to select and add to an electronic shipping cart (a) products originating from a single merchant in the common marketplace or (b) products originating from multiple (two or more) independent merchants in the common marketplace. In this regard, the transaction module 206 may provide functionality for maintaining the identity of the customer between different e-commerce points of transactions associated with different merchants (for example using cookies or other suitable mechanism). In the embodiment described, the websites associated with the e-commerce points of transactions for the different merchants in the common marketplace are hosted by the marketplace server 150 (for example by the merchant accounts module 208), which facilitates the process of maintaining the identity of the customer between different e-commerce points of transactions associated with different merchants.

In a specific implementation, the transaction module 206 implements checkout logic enabling a customer using customer computing module 170 to place an order to purchase products. In particular, the checkout logic implemented by the transaction module 206 is configured for allowing a customer to place a single order for the products in the shopping cart, wherein the shopping cart may include products originating from a single merchant in the common marketplace or, alternatively, may include products originating from multiple (two or more) independent merchants in the common marketplace. The checkout logic may include, amongst other, intelligence for calculating tax, shipping costs, and the like using data from such sources as the selected products, a customer database (in customer accounts module 210), a merchant database (in merchant accounts module 208), amongst other. The checkout logic may also perform the function of preparing invoices, presenting invoices to the customer, obtaining any necessary and/or additional information pertaining to payment/shipping preference, and receiving the approval from the customer for completing the transaction. For the customer, the need to use only a single shopping cart and a single checkout procedure irrespective or the number of merchants involved in the order substantially simplifies the process of making purchases from multiple merchants by at least essentially eliminating the need to enter redundant information for each merchant involved in the order.

The transaction module 206 also communicates with financial services entities and with transporter services entities through the finance module 204 and the delivery/transport coordinator module 202 respectively. Through the finance module 204, the transaction module 206 arranges for payment/re-imbursement of orders made by customers. As is described in the present application, the payment/re-imbursement of an order may be made by the finance module 204 using common marketplace payment accounts associated with respective financial services entities. Through the delivery/transport coordinator module 202, the transaction module 206 may obtain cost estimates for pick-up and delivery services for products in an order (and provide these estimates to the customer during the checkout operation).

The transaction module 206 communicates with the merchant accounts module 208 in order to update the merchants database (not shown in the figures) to reflect new orders placed through the transaction module 206 so that listings of outstanding deliveries associated with specific merchants reflect information in the new orders. The transaction module 206 may also communicate with specific merchants through the merchant accounts module 208 in order to notify specific merchants involved in an order, for example by causing an e-mail (or SMS or voice-mail or other) to be sent to these specific merchants, that an order has been received at the common marketplace.

Delivery/transport coordinator module 202 The delivery/transport coordinator module 202 receives transaction information from the transaction module 206 and communicates with the transporter entity server 180 through a computer network in order to complete certain steps of the transaction, including sending pick-up and delivery requests to a transporter entity. The delivery/transport coordinator module 202 also interacts with the merchant accounts module 208 in order to cause notifications to be sent to specific merchants regarding impending pickups and/or to update specific merchant accounts, through the transporter reconciliation module 203, so that delivery charges are reflected.

With respect to the communications with the transporter entity server 180, the delivery/transport coordinator module 202 is programmed with the required application program interface (API) to allow it to perform typical transactions including requesting a new pick-up/delivery, requesting a cost estimate for a shipment, tracking packages and the like. The API implemented by delivery/transport coordinator module 202 will vary in dependence on the nature of the transporter entity server 180 with which it needs to communicate. In cases where delivery/transport coordinator module 202 needs to interact with multiple external payment servers, a separate API for each payment service is programmed into the delivery/transport coordinator module 202. Providing an API for interacting with a transporter entity server such as transporter entity server 180 is known in the art and as such will not be described further here.

In a specific implementation, the delivery/transport coordinator module 202 depicted in Figure 2 is configured for providing shared tools for coordinating pick-up and delivery services for merchants in the common marketplace implemented by system 100.

Figure 3A and 3B of the drawings provide graphical representations of the manner in which coordination of pick-up and delivery services may be shared in the common marketplace.

With reference to Figure 3A, through the delivery/transport coordinator module 202, the common marketplace coordinates pick-up and delivery services with a set of transporter entities 304 that the common marketplace supports. The set of transporter entities 304 may include one or more distinct transporter entities. In this context, the delivery/transport coordinator module 202 of the common marketplace is programmed to communicate with the transporter entities in the set 304 using respective common marketplace transporter accounts to arrange for pick-up and delivery of products originating from member merchants in the common marketplace using any of the transporter entities in the set 304. The arranging for pick-up and delivery of products is performed by the delivery/transport coordinator module 202 using information stored in the customer accounts module 210 (for example delivery address) and information stored in the merchant accounts module 208 (for example pick-up address and pick-up time) using the appropriate API(s). In the example presented, the common marketplace is shown as supporting four distinct transporter entities each of which is associated with a respective common marketplace transporter account 308x, namely common marketplace transporter account #1 , 308a; common marketplace transporter account #2, 308b; common marketplace transporter account #3, 308c; and common marketplace transporter account #4 308d. The delivery/transport coordinator module 202 may also be configured for performing a reconciliation process 306, through the transporter reconciliation module 203 shown in Figure 2, between the one of more common marketplace transporter accounts 308a-d and a merchant account 300 associated a specific merchant in the common marketplace to reflect delivery charges associated with products originating from the member merchant 300. As will be appreciated, a member merchant can have the simplicity of a single account 300 in the common marketplace while being able to be benefit from the flexibility of being able to deliver products using different transporters by using the shared pick-up and delivery services provided in the common marketplace without the burden of opening and managing a separate account with each transporter entity.

With reference to Figure 3B, through the delivery/transport coordinator module 202, the common marketplace coordinates pick-up and delivery services using a same common marketplace transporter account when arranging for delivery/transport of products originating from any merchant in a group of member merchants in the common marketplace implemented by system 100 (shown in Figure 1). In this context, the delivery/transport coordinator module 202 of the common marketplace is programmed to communicate with a specific transporter entity using a common marketplace transporter account, namely common marketplace transporter account 308a in Figure 3B, to arrange for pick-up and delivery of products originating from any merchant in the group of member merchants. The arranging for pick-up and delivery of products is performed by the delivery/transport coordinator module 202 using information stored in the customer accounts module 210 (for example delivery addresses) and information stored in the merchant accounts module 208 (for example pick-up addresses and pick-up times) using the API associated with the specific transporter entity (POSTES CANADA in figure 3B). In the example presented, three merchants in the group of merchants are illustrated however the group of merchants may include any number of member merchants. The member merchants in the group of merchants are associated with respective merchant accounts 300a... c. The delivery/transport coordinator module 202 is also configured for performing a reconciliation process 306, through the transporter reconciliation module 203 shown in Figure 2, between the common marketplace transporter account 308a and the merchant accounts 300a... c associated with the merchants in the group of merchants to reflect delivery/transport charges incurring in connection with delivery/transport services provided by the specific transporter entity for products originating from the member merchants 300a... k. It is to be appreciated that the group of member merchants in the common marketplace need not include all member merchants in the common market but may include only a subset thereof, the subset including two or more member merchants. It is also to be appreciated that member merchants in the common marketplace may be organized in different groups of member merchants, wherein each group would be associated with a respective common marketplace transporter account when communicating with a specific transporter entity. Optionally, certain member merchants can "opt-out" from using a common marketplace transporter account and instead use their own merchant transporter accounts with specific transporter entities.

Transporter reconciliation module 203 (Fig. 2)

The transporter reconciliation module 203 interacts with the delivery/transport coordinator module 202 and with the merchant accounts module 208 in order to perform a reconciliation process, referred to by numeral 306 in Figures 3A and 3B, between the one of more common marketplace transporter accounts and one or more merchant accounts in the common marketplace to reflect delivery charges associated with products originating from member merchants. In a specific implementation, the reconciliation is performed by the transporter reconciliation module 203 periodically in a batch, for example once a day; a few times a day or once every few days, in order to update the specific merchant accounts so delivery charges are reflected therein.

Finance module 204 (Fig. 2)

The finance module 204 receives transaction information from the transaction module 206 and communicates with the financial services server 190 through a computer network in order to complete certain steps of the transaction, including the processing of a payment or of a re- imbursement. The finance module 204 also interacts with the merchant accounts module, through the payment reconciliation module 205, in order to reconcile information in a specific merchant account following a transaction. The finance module 204 also communicates with the customer accounts module 210 in order to obtain information regarding a client (including for example credit card information, delivery address and the like).

With respect to the communications with the financial services server 190, the finance module 204 is programmed with the required API to allow it to perform typical transactions including debits/credits to an account, requesting authorization etc... The API implemented by the finance module 204 will vary in dependence of the nature of the financial services server 190 with which it needs to communicate. In cases where finance module 204 needs to interact with multiple external payment servers, a separate API for each payment service is programmed into the finance module 204. Providing an API for interacting with a payment server such as financial services server 190 is known in the art and as such will not be described further here.

In a specific implementation, the finance module 204 depicted in Figure 2 is configured for providing shared payment processing functions/services to a plurality of merchants in the common marketplace implemented by system 100.

Figure 4A and 4B of the drawings provide graphical representations of the manner in which payment processing functions/services may be shared in the common marketplace.

With reference to Figure 4A, through the finance module 204, the common marketplace coordinates payment processing functions with a set of payment processing entities 310 that the common marketplace supports. The set of payment processing entities 310 may include one or more distinct payment processing entities. In this context, the finance module 204 of the common marketplace is programmed to communicate with the payment processing entities 310 using respective common marketplace payment accounts to arrange for payment (or for re-imbursement) of an order through any of the payment processing entities in the set 310. The arranging for payment (or re-imbursement) of an order is performed by the finance module 204 using information stored in the customer accounts module 210 (for example credit card information) using the appropriate API(s). In the example presented, the common marketplace is shown as supporting four distinct payment processing entities each of which is associated with a respective common marketplace payment account 314a-d, namely common marketplace payment account #1 , 314a; common marketplace payment account #2, 314b; common marketplace payment account #3, 314c; and common marketplace payment account #4 314d. The finance module 204 is also configured for performing a reconciliation process 312, through payment reconciliation module 205 shown in Figure 2, between the one or more common marketplace payment accounts 314a-d and a merchant account 300 associated with a specific merchant in the common marketplace to reflect payments (or re-imbursements) of products originating from the member merchant 300. As will be appreciated, a member merchant can have the simplicity of having a single merchant account 300 in the common marketplace while being able to be benefit from the flexibility of receiving different types of payments (through different payment processing entities) by using the shared payment processing functions/services provided in the common marketplace without the burden of having to open and manage a separate payment account with each payment processing entity.

With reference to Figure 4B, through the finance module 204, the common marketplace coordinates payment processing functions with a payment processing entity that the common marketplace supports using a same common marketplace payment account when arranging for payment (or re-imbursement) of products originating from any merchant in a group of member merchants in the common marketplace implemented by system 100 (shown in Figure 1). In this context, the finance module 204 of the common marketplace is programmed to communicate with a specific payment processing entity using a common marketplace payment account, namely common marketplace payment account 314a in Figure 4B, to arrange for payment (or re-imbursement) of products originating from any merchant in the group of member merchants. In the example presented, three merchants in the group of merchants are illustrated however the group of merchants may include any number of member merchants. The member merchants in the group of merchants are associated with respective merchant accounts 300a... c. The arranging for payment (or reimbursement) of an order is performed by the finance module 204 using information stored in the customer accounts module 210 (for example credit card information) using the API associated with the specific payment processing entity. The finance module 204 is also configured for performing a reconciliation process 312, through payment reconciliation module 205 shown in Figure 2, between the common marketplace payment account 314a and the merchant accounts 300a... c associated with the merchant in the group of merchants to reflect payments (or re-imbursements) made through the specific payment processing entity for products originating from the member merchant accounts 300a... c. It is to be appreciated that the group of member merchants in the common marketplace need not include all member merchants in the common market but may include only a subset thereof, the subset including two or more member merchants. It is also to be appreciated that member merchants in the common marketplace may be organized in different groups of member merchants, wherein each group would be associated with a respective common marketplace payment account when communicating with the specific payment processing entity. Optionally, certain member merchants can "opt-out" from using a common marketplace payment account and instead use their own merchant payment account with specific payment processing entity.

Payment reconciliation module 205

The payment reconciliation module 205 interacts with the finance module 204 and with the merchant accounts module 208 in order to perform a reconciliation process, referred to by numeral 312 in Figures 4A and 4B, between the one of more common marketplace payment accounts and merchant accounts in the common marketplace so that information in specific merchant accounts reflects payment(s) (or re-imbursement(s)) of products made using one or more common marketplace payment accounts.

In a specific implementation, the reconciliation process 312 is performed periodically, for example once a day; a few times a day or once every few days, in order to update the specific merchant accounts so that payment(s) (or re-imbursement(s)) of products are reflected therein.

Optionally, the reconciliation process 312 updates merchant accounts so that payments of products are reflected after the common marketplace server 150 receives a message confirming delivery of the products. In other words, the update of the merchant accounts to reflect payments is deferred until after delivery has been confirmed. Advantageously, deferring payment transfer to specific merchants until delivery is confirmed affords a greater level of security to a customer when purchasing products from member merchants in the common marketplace since payments are essentially kept by the common marketplace until product delivery. Thus merchants who have not yet individually established trust with customers can benefit from the trust established between the customers and the common marketplace implemented by system 100 (shown in Figure 1). In a specific example, in addition to communicating with the finance module 204 and with the merchant accounts module 208, the payment reconciliation module 205 further interacts with the delivery/transport coordinator module 202 to receive information originating from the transporter entity server 180 confirming delivery of specific products (or orders including specific products). While in this specific example, the message confirming delivery of specific orders originates from the transporter entities, in other embodiments the payment reconciliation module 205 may receive such confirmation messages from specific merchants and/or from customers, for example through the merchant accounts module 208 or through the customer accounts module 210. Since confirmation of delivery may be used to trigger transfers of payments to specific merchant accounts, for added security from the perspective of the customers, it may not be advantageous to rely on specific merchants' delivery confirmation messages alone without some other type of verification. For example, in cases where the transporter entity is a delivery service provided by the specific merchant, an additional verification mechanism may be used to ensure that the customer has indeed received the product. For example a code may be provided to the customer by the common marketplace server 150 when the order is first placed (or in a confirmation message following the placing of the order). When the product is delivered, the customer provides the code to the merchant (or to his transporter entity) and this code is used as part of the message confirming delivery of the product. This additional validation of product delivery provides a higher level of security to the customer.

FIGURES 5, 6, 7A. 7B and 7C

With reference to Figures 5, 6, 7A, 7B and 7C examples of processes for facilitating commercial transactions using the common marketplace implemented by the system 100 shown in Figure 1 will now be described.

At step 502, a customer using a customer computing module, such as customer 140 using customer computing module 170, accesses one or more e-commerce points of transaction associated with member merchants in the common marketplace through marketplace server 150. In a specific implementation, this is performed by the customer accessing a website associated with the one of member merchants, the websites being hosted by the marketplace server 150. Through these e- commerce points of transaction, the customer may select products and add/remove them to/from his shopping cart using the shopping cart logic provided by the transaction module 206. As described above, the shopping cart logic implemented by the transaction module 206 is configured for allowing a customer to select and add to an electronic shipping cart products originating from a single merchant in the common marketplace or products originating from multiple (two or more) independent merchants in the common marketplace. The shopping cart logic presents the customer with user interface tools allowing the user, through the customer computing module 170, to initiate a checkout procedure by launching the checkout logic provided by the transaction module 206. As described above, the checkout logic implemented by the transaction module 206 is configured for allowing a customer to place a single order for the products in the shopping cart, wherein the shopping cart may include products originating from a single merchant in the common marketplace or, alternatively, may include products originating from multiple (two or more) independent merchants in the common marketplace. Optionally, the check-out logic allows the customer to independently specify for each product in the shopping cart, the specific transporter and the specific delivery service that the customer would like to use. The checkout logic may include, amongst other, intelligence for calculating tax, shipping costs, and the like using data from such sources as the selected products, a customer database (in customer accounts module 210), a merchant database (in merchant accounts module 208), amongst other. The checkout logic may also perform the function of preparing invoices, presenting invoices to the customer, obtaining any necessary and/or additional information pertaining to payment/shipping preferences, and receiving the approval from the customer for completing the transaction. For the customer, the need to use only a single shopping cart and a single checkout procedure irrespective or the number of merchants involved in the order substantially simplifies the process of making purchases from multiple merchants by at least essentially eliminating (or at least reducing) the need of entering redundant information for each merchant involved in the order. The process then proceeds to step 504.

At step 504, the marketplace server 150, receives information pertaining to the new order from the customer computing module 170, the new order specifying one ore more products originating from one or more member merchant amongst the member merchants in the common marketplace. The process then proceeds to step 506.

At step 506, the marketplace server 150 determines if the identity of the customer using customer computing module 170 has already been verified. If the identity of the customer has not yet been verified, the process proceeds to step 508 where a customer identity verification (authentication) process is performed. If the identify of the customer has already been verified, either because the customer already provided login information or for some other reason, the process proceeds to step 514 where the checkout procedure continues.

At step 508, a process for identifying/authenticating the customer 140 using the customer computing module 170 is performed. In a first embodiment, in order to identify/authenticate a customer 140, the marketplace server 150 prompts the customer 140 to provide authentication information, in the form of a user identifier and password for example, through a browser displayed on the customer computing module 170. Alternatively, this could be done through a sign-on function on another website, such as Facebook™ or Twitter™, or using a dedicated application (an "App") on a mobile device. The authentication information provided by the customer 140 can be encrypted as it is passed over the network so that the information cannot be stolen by someone snooping on the network. An alternative to using manually entered user identifiers and passwords is to use a digital certificate stored on the customer computing device 170 (for example a cookie) or on a Smartcard. It is to be appreciated that any suitable manner for identifying/authenticating the customer 140 may be used in alternative examples implementation of the invention. The manually entered user identifier/password combination or the digital certificate provided by the customer 140 is verified against information stored in the customer database of the customer accounts module 210. If this is the first purchase performed by the customer 140 in the common marketplace, the marketplace server 150 creates a new customer account through the customer accounts module 210 and may prompt the user for various personal information, including for example delivery address information, payment information (for example credit card information) and the like. This information is stored in the customer database for later use. If the customer 140 has already made a purchase from any of the merchants in the common marketplace, a customer account associated with the customer 140 would have already been created and the information stored in the customer's account is retrieved from the customer database. Advantageously, once the customer 140 has made a single purchase involving a single merchant in the common marketplace, he can make purchase from any of the other member merchants in the common marketplace without being required to re-enter his personal information. In a specific implementation, the identification/authentication of customer 140 is performed once irrespective of the number of merchants involved in the newly placed order. By providing shared authentication functionality the marketplace server 150 allows, for example, a customer visiting multiple merchants that are part of the common marketplace to provide authentication information once in order to perform trans- actions with any number of merchants in the common marketplace. Once the identity verification (authentication) process is completed, the process proceeds to step 510.

At step 510, a determination is made as to whether the identification/authentication of the customer 140 was a success. In the negative, the process proceeds to step 512 and an error message is presented to customer 140 through customer computing module 170. If the identification/authentication of the customer 140 was a success, the process proceeds to step 514.

At step 514, the checkout procedure, implemented by the checkout logic provided by the transaction module 206, continues. At step 514, an estimate of the shipping charges associated with the new order is derived. In a specific implementation, this step may include communicating with one or more transporters in order to obtain delivery charge estimates for the products in the shopping cart however other suitable mechanisms for estimating shipping charges may be used. The checkout process then proceeds to step 516.

At step 516, the common marketplace server 150 performs a process to arrange for payment of the new order including coordinating between the financial services server 190 and the customer 140. Step 516 will be described in greater detail with reference to Figure 6. Once the processing of the payment of the new order has been completed, the process proceeds to step 518.

At step 518, the common marketplace server 150 coordinates the pick-up and delivery of products in the order between the one or more merchants involved in the order and one or more transporter entities. Step 518 will be described in greater detail with reference to Figures 7A, 7B and 7C.

Turning now to Figure 6, an example of the process for arranging for payment of the new order will now be described.

At step 600, the checkout process continues and the customer 140 is presented (through customer computing module 170), with cost information related to the new order. The cost information would typically include the price of the product, delivery charges (as would be provided by step 514), applicable taxes and the like. Optionally, the customer may be prompted to confirm the order. Following this the process proceeds to step 602. At step 602, payment information regarding the new order is received. The payment information may originate from the customer computing module 170, wherein payment information is provided as part of the order confirmation step. Alternatively, the payment information may be extracted from the customer account in the customer database in the customer accounts module 210 (shown in Figure 2). Following this the process proceeds to step 604.

At step 604, through the finance module 204, the marketplace server 150 communicates with the fmancials services entity associated with the mode of payment used by the customer in order to arrange for payment of the new order. In a specific example, communicating with the remote financial services entity to arrange for payment of the new order is made using a payment account associated with the common marketplace. The process then proceeds to step 606.

At step 606, a determination is made as to whether the payment of the order is successfully processed. If the payment of the order is not successfully processed, the process proceeds to step 608 where an error handling process is initiated. If the payment of the order is successfully processed, the process proceeds to step 610.

At step 610, a message is sent to the customer 140 confirming that the order was successfully placed and that the payment was processed. The message may also include information related to the delivery of the order, including expected date (or dates) of delivery and the like. The message may be sent to the customer via e-mail and/or SMS and/or may be displayed on an order confirmation web-page displayed on the customer's computing module 170. Once the order is placed, a new entry is created by the transaction module in an orders database in order to reflect the new order placed by the customer 140. The new order in the database maps each product therein with a respective member merchant account and with a respective customer account. In addition, the listings of outstanding deliveries involving specific member merchants in the common marketplace stored in connection with the merchant account in the merchant accounts module 208 may also be updated to reflect information in the new order. If the order includes products originating from multiple member merchants, this involves updating the listings of outstanding deliveries associated with the respective member merchants involved in the order. The process then proceeds to step 518. A first specific example of step 518 will be described with reference to figure 7A. In this first example, the new order placed by the customer 140 includes one or more products all originating from a same specific merchant and a same transporter entity is used for pick-up and delivery of the products in the order.

At step 702, an electronic notification message is sent to the specific member merchant to advise the specific member merchant that an order involving the specific merchant has been received in the common marketplace implemented by system 100. The contents of the electronic notification message may vary from one implementation to the other. For example the information conveyed by the electronic notification message may be limited to comply convey that an order has been received. Alternately, the electronic notification message may provide specific details regarding the order including, for example, a description of the products ordered, the quantity of products ordered, a level of urgency with the order and the like. The electronic notification message may be transmitted using any suitable communication mechanism including for example an e-mail message sent to an address associated with the specific member merchant, a SMS message, a facsimile and a voice-messaging service. The process proceeds to step 704.

At step 704, the marketplace server 150 waits to receive a communication from the specific member merchant conveying that the one or more products in the order are ready for pick-up. Once such a communication is received, the process proceeds to step 706.

At step 706, the marketplace server 150 communicates with a remote transporter entity using an appropriate API and arranges for pick-up of the one or more products from a location associated with the specific merchant. In a specific example, communicating with the remote transporter entity to arrange for pick-up and delivery of ordered products originating from the specific merchant is made using a transporter account associated with the common marketplace. Optionally, at this step, delivery charges associated with the pick-up and delivery of ordered products originating from the specific merchant are reflected in the merchant account through a transporter reconciliation process. Alternatively, the transporter reconciliation process may be performed later on, for example after confirmation of delivery has been received. The process then proceeds to step 707. At step 707, the marketplace server 150 through the delivery/transport coordinator module 202, monitors the delivery status of the ordered products. In this step, the specific order is essentially tracked as it travels between the pick-up location associated with the specific merchant and a delivery associated with the customer. The process then proceeds to step 708. Optionally, it is to be appreciated that, at step 707, a mechanism can provided to monitor the delay in delivery and identify delay that may be unreasonably long (for example delay exceeding a certain predetermined time duration). In cases where a delay that may be unreasonably long has been identified, an error handling process may be initiated, for example, sending an electronic notification to an administrator of the common marketplace implemented by system 100 advising of the delay and of the associated order. The administrator may then perform any suitable follow-up action in regards to the order, including for example contacting the transporter entity involved.

At step 708, the marketplace server 150 waits to receive a message confirming delivery of the specific order. In practical implementations, the message confirming delivery of the specific order will originate from the transporter entity however other embodiments may receive such confirmation from the specific merchant and/or from the customer. Since confirmation of delivery may in certain embodiments be used to trigger a payment transfer to the specific merchant, it may not be desirable to rely on the specific merchant's confirmation alone without some other type of verification. In addition, in cases where the transporter entity is a delivery service provided by the specific merchant or in the case where the transporter entity is associated with an "on-site" pickup, an additional verification mechanism may be used to ensure that the customer has indeed received the product(s). For example a code may be provided to the customer when the order is first placed (for example in the order confirmation message sent at step 610 in Figure 6). When the product is delivered, the customer provides the code to the merchant (or to the transporter entity associated with the merchant) and this code is used as part of the message confirming delivery of the product. It will be appreciated that many other suitable mechanisms may be used to confirm delivery of a shipment in connection with alternate embodiments. While no message confirming delivery of the specific order has been received, the process loops back to step 707 and the delivery status of the ordered products continues to be monitored. Once such a message confirming delivery of the specific order is received, the process proceeds to step 710. At step 710, a reconciliation process is performed in connection with a merchant account associated with the specific merchant to reflect the payment by the customer of the product originating from the specific member merchant. More specifically, and as described above with reference to step 604 (shown in Figure 6), the payment of the new order was arranged using a payment account associated with the common marketplace. Once a communication confirming delivery is received at step 708, the funds associated with that order are released by the common marketplace and reflected as a credit in the merchant account.

A second specific example of step 518 will be described with reference to Figure 7B (labeled 518' in Figure 7B). In this second example, the new order placed by the customer 140 includes at least a first product originating from a first specific member merchant and a second product originating from a second specific member merchant distinct from the first specific member merchant.

At step 750, an electronic notification message is sent to the first specific member merchant to advise the first specific member merchant that an order with which it is involved has been received in the common marketplace implemented by system 100. Similarly, in the parallel path, at step 760, an electronic notification message is sent to the second specific member merchant to advise the second specific member merchant that an order with which it is involved has been received in the common marketplace implemented by system 100. It is to be appreciated that the messages sent to the first and second member merchant need not be of the same type and need not have the same type of content. For example, for the first specific member merchant the notification message may be sent via e-mail only while for the second member merchant the notification message may be sent via SMS. Steps 750 and 760 are analogous to step 702 described with reference to Figures 7A and therefore will not be described in further detail here. The process then proceeds to steps 752 and 762 for the first specific member merchant and the second specific member merchant respectively.

At step 752, the marketplace server 150 waits to receive a communication from the first specific member merchant conveying that the first product in the order is ready for pick-up. Once such a communication is received, the process proceeds to step 754. Similarly, in the parallel path, at step 762, the marketplace server 150 waits to receive a communication from the second specific member merchant conveying that the second product in the order is ready for pick-up. Once such a communication is received, the process proceeds to step 764. Steps 752 and 762 are analogous to step 704 described with reference to Figures 7A and therefore will not be described in further detail here.

At step 754, the marketplace server 150 communicates with a remote transporter entity and arranges for pick-up of the first product from a location associated with the first specific merchant. In a specific example, communicating with the remote transporter entity to arrange for pick-up and delivery of the first product originating from the first specific merchant is made using a transporter account associated with the common marketplace. Optionally, at this step, delivery charges associated with the pick-up and delivery of ordered products originating from the first specific merchant are reflected in the merchant account associated with the first merchant through a transporter reconciliation process. Alternatively, the transporter reconciliation process may be performed later on, for example after confirmation of delivery has been received. Similarly, in the parallel path, at step 764, the marketplace server 150 communicates with a remote transporter entity and arranges for pick-up of the second product from a location associated with the second specific merchant. Optionally, at this step, delivery charges associated with the pick-up and delivery of ordered products originating from the second specific merchant are reflected in the merchant account associated with the second merchant through a transporter reconciliation process. Alternatively, the transporter reconciliation process may be performed later on, for example after confirmation of delivery has been received. In a situation whether the marketplace server 150 arranges for pick-up and delivery of the first product originating from the first specific merchant and of the second product originating from the second specific merchant through the same transporter entity, the same common marketplace transporter account is used to arrange for pick-up and delivery. In a situation whether the marketplace server 150 arranges for pick-up and delivery of the first product originating from the first specific merchant through a first transporter entity and arranges for pick-up and delivery of the second product originating from the second specific merchant through a second (distinct) transporter entity, respective common marketplace transporter accounts for each of the first and second transporter entities are used to arrange for pick-up and delivery. Steps 754 and 764 are analogous to step 706 described with reference to Figures 7A and therefore will not be described in further detail here. The process then proceeds to steps 755 and 765 for the first specific member merchant and the second specific member merchant respectively. At step 755, the marketplace server 150 through the delivery/transport coordinator module 202, monitors the delivery status of the first product originating from the first member merchant. Similarly, in the parallel path, at step 765, the marketplace server 150 through the delivery/transport coordinator module 202, monitors the delivery status of the second product originating from the second member merchant. Steps 755 and 765 are analogous to step 707 described with reference to Figures 7A and therefore will not be described in further detail here. The process then proceeds to steps 756 and 766 for the first specific member merchant and the second specific member merchant respectively.

At step 756, the marketplace server 150 waits to receive a message confirming delivery of the first product. Once such a communication is received, the process proceeds to step 758. Similarly, in the parallel path, at step 766, the marketplace server 150 waits to receive a message confirming delivery of the second product. Steps 756 and 766 are analogous to step 708 described with reference to Figures 7A and therefore will not be described in further detail here. The process then proceeds to steps 756 and 766 for the first specific member merchant and the second specific member merchant respectively.

At step 758, a reconciliation process is performed in connection with a merchant account associated with the first specific merchant to reflect the payment by the customer of the first product originating from the first specific member merchant. More specifically, and as described above with reference to step 604 (shown in Figure 6), the payment of the new order was arranged using a payment account associated with the common marketplace. Once a communication confirming delivery is received at step 756, the funds associated with payment of the first product are released by the common marketplace and reflected as a credit in the merchant account associated with the first specific merchant. Similarly, in the parallel path, at step 768, the marketplace server 150 a reconciliation process is performed in connection with a merchant account associated with the second specific merchant to reflect the payment by the customer of the second product originating from the second specific member merchant. More specifically, and as described above with reference to step 604 (shown in Figure 6), the payment of the new order (including the first and second product) was arranged using a payment account associated with the common marketplace. Once a communication confirming delivery is received at step 766, the funds associated with payment of the second product are released by the common marketplace and reflected as a credit in the merchant account associated with the second specific merchant. Steps 758 and 768 are analogous to step 710 described with reference to Figures 7A and therefore will not be described in further detail here.

While the above example was limited to only two products originating from two member merchants, a person skilled in the art in light of the present description will readily appreciate how this process may be adapted to any number of products originating from any number of merchants in the common marketplace. In addition, while the above example was limited to the use of one or two distinct transporter entities, a person skilled in the art in light of the present description will readily appreciate how this process may be adapted to use any number of any number of distinct transporter entities in the common marketplace.

A third specific example of step 518 will be described with reference to Figure 7C (labeled 518" in Figure 7C). As will be appreciated, steps 702, 704, 706, 707, 708 and 710 shown in Figure 7C have already been described with reference to Figure 7A and therefore will not be described further here. In this third specific example, additional steps 780, 782, 784 and 786 for providing functionality for monitoring the responsiveness of specific member merchants. Such functionality allows, for example, presenting an option to a customer to choose cancel an order for a product and obtain a refund when a merchant exceeds a certain delay in advising that the product in the order is ready for pick-up.

More specifically, at step 780, which is initiated either following step 702 or while waiting for a communication from the member merchant at step 704, the marketplace server 150 determines if a maximum delay has been exceeded. The maximum delay may be a same delay for all merchants, may be a merchant specific delay or may be a delay selected by the customer. While the maximum delay has not been exceeded, the marketplace server 150 waits (steps 704 and 780). Once the maximum delay has been exceeded without the receipt of a communication from the specific member merchant conveying that the one or more products in the order are ready for pick-up, the process proceeds to step 782.

At step 782, the marketplace server 150 transmits an electronic notification message to the customer advising the customer of the delay and presenting the customer with one or more options. These options may allow the customer, for example, to choose to cancel an order for a product and obtain a refund. The electronic notification message may be transmitted by the marketplace server 150 in any suitable manner including, but not limited to, an e-mail message sent to an address associated with the customer, a short message service (SMS) message, a facsimile and a voice-messaging service. Optionally, in cases where the format of the electronic notification message allows it, an electronic link (or web-address) to an order modification interface in the common marketplace may be included as part of the electronic notification message such that activation of the electronic link allows the customer to access in his customer account and view unfulfilled prior orders placed by the customer and make desired modifications. The process then proceeds to step 784.

While the customer does not request a refund and cancel his order, step 784 is answered in the negative and the marketplace server 150 remains in the process of steps 780 and 782. Although not shown in Figure 7C, while waiting for the customer to request a refund and cancel his order, if a communication from the specific member merchant conveying that the one or more products in the order are ready for pick-up is received, the process can proceed to step 704.

Following receipt of information from the customer that a refund is desired, step 784 is answered in the affirmative and the process proceeds to step 786.

At step 786, the received request for refund and order cancellation is processed by the marketplace server. This step includes communicating with the financial services entity that processing the original payment to perform a transaction including reimbursing the customer for the cancelled ordered. As was the case for the processing of a payment associated with a new order, the processing of a re-imbursement is performed with the remote financial services entity using a payment account associated with the common marketplace. This step may also include updating the listings of outstanding deliveries associated with the specific merchant and stored in the merchant accounts module 208 in order to reflect the cancelled ordered. This step may also include updating the listings of prior orders placed by the customer in the customer accounts module 210 in order to reflect the cancelled order. Optionally, an electronic notification message may be sent to the specific member merchant conveying the cancellation of the order.

FIGURE 8 With reference to Figure 8, a specific example of a process implemented by the marketplace server 150, shown in Figures 1 and 2, for facilitating fulfilling orders member merchants in the common marketplace implemented by the system 100 will now be described. Part of the functionality described below may be implemented by merchant accounts module 208 and the transaction module 206 (shown in Figure 2). While Figure 8 shows functionality from the perspective of the marketplace server 150, Figures 9 and 1 1A to 1 1 E, which are described later on in the present document, show related functionality described from the perspective of a member merchant.

At step 802, the marketplace server 150, through the customer accounts module 210, maintains an orders database including information related to orders previously placed by customers. In this regard, when a customer places a new order in the common marketplace, the transaction module 206 causes a new entry to be created in the orders database (not shown in the figures). As will be appreciated, the common marketplace implemented by system 100 allows customers to specify in a same order products originating from a single merchant as well as to specify in a same order products originating from multiple (two or more) independent merchants. In this regard, the orders database maps each product in each order with a respective member merchant account and with a respective customer account. Preferably, the orders previously placed by customers are maintained in the orders database at least until the orders are either fulfilled by the member merchants or cancelled by the customer, however some practical implementations may maintain records of orders even after the orders are fulfilled such as to be able to have a history of orders placed and/or for inventory management purposes. As such, the orders database also maps each product in each order with a identifier indicating whether the product has been delivered ("ordered for product is fulfilled or partly fulfilled") or whether it remains to be delivered ("ordered for product is unfulfilled"). In a specific implementation, the information in the orders database may be used to update listings of outstanding deliveries involving specific member merchants in the common marketplace. These listings of outstanding deliveries involving specific member merchants may be stored, for example, in a merchant database in the merchant accounts module 208. As mentioned above, since a single order may involve either a single merchant or multiple (two or more) merchants, the update of listings of outstanding deliveries involving specific member merchants may involved one or more listings of outstanding deliveries in merchant accounts module 208. The specific manner in which the orders database is maintained as well as the specific manner in which the listing of outstanding deliveries involving specific member merchants are updated are not critical and as such will not be described in further detail here. It is to be noted that step 802 is performed on a continuous basis and the orders database, and the listings of outstanding deliveries involving specific member merchants, are updated as new orders are placed and deliveries are made in connection with the common marketplace.

A step 804, the marketplace server 150 receives a request from a specific merchant using a merchant computing device, for example merchant computing device 160a in Figure 1 , to access an account associated with the specific merchant. The request to access the account associated with the specific merchant would include information identifying the specific merchant. The identification information may be provided automatically merchant computing device 160a using known methods (for example using a cookie or other suitable mechanism) or alternatively may be provided by the specific merchant through a merchant login interface including user editable fields. Assuming the request to access the account associated with the specific merchant is successful, the process proceeds to step 806 shown in Figure 8.

At step 806, the marketplace server 150 transmits, through the merchant accounts module 208, one or more electronic documents to the merchant computing device 160a to cause the latter to display a merchant interface. The merchant interface presents the specific merchant with a listing of outstanding deliveries involving the specific merchant. In a specific example, the listing of outstanding deliveries is stored in a merchant database in the merchant accounts module 208 and is associated with a merchant account associated with the specific merchant. The merchant interface presents user interface tools for enabling the specific merchant to select one or more specific entries from the listing or outstanding deliveries and provide information to the marketplace server 1 0 conveying that a product associated with an entry selected from the listings outstanding deliveries is ready for pick-up. The process then proceeds to step 808.

At step 808, the marketplace server 150 receives information from the merchant computing device 160a associated with the specific member merchant, the information conveying that a product associated with an entry in the listings outstanding deliveriesis ready for pick-up. Following receipt of such information, the marketplace server 150, through delivery/transporter module 202, communicates with a transporter entity to arrange for pick-up of the specific product from a pick-up location associated with the specific merchant. In a specific implementation, the entry associated with the product specified in the message is associated with specific transportation parameters. In such cases, the communication with the transporter entity to arrange for pick-up of the product is performed at least in part based on the specific transportation parameters associated with the corresponding entry in the listing of outstanding deliveries. The transportation parameters may specify, for example, the identity of the transporter entity to use (e.g. on-site pick-up; UPS™; Canada Post™ etc .), the type of service (regular delivery, express, etc .), the delivery address, the pick-up location, the desired pick-up time and the like.

FIGURES 9 and 11 A to 11E

With reference to Figures 9, 11A to 1 1 E, an example of a process, from the perspective of a specific member merchant, for facilitating fulfilling orders by the specific member merchant in the common marketplace implemented by the system 100 shown in Figure 1 will now be described. Part of the functionality described below may be implemented by merchant accounts module 208 (shown in Figure 2).

At step 902, a specific merchant accesses the common marketplace system 100 using a merchant computing device, for example merchant computing device 160a in Figure 1 , and performs a login operation in order to access an account associated with the specific merchant. In a specific practical implementation, this may performed by using a web browser on merchant computing device 160a to access a merchant management account website associated with the common marketplace and provide identification information associated with the specific merchant. The identification information may be provided automatically merchant computing device 160a using known methods (for example using a cookie or other suitable mechanism) or alternatively may be provided by the specific merchant through a merchant login interface including user editable fields. Figure 1 1A, shows a non-limiting example of a merchant login interface 1 100 including user editable fields 1 102 allowing the specific merchant to provide a username (in this example an e-mail address) and a password to identify the specific merchant. Once the login operation is complete the process proceeds to step 904 shown in Figure 9.

At step 904, the specific merchant using the merchant computing device 160a accesses his administration site in the common marketplace system 100 and a listing of outstanding deliveries involving the specific merchant is displayed on the display of merchant computing device 160a. Figure 1 IB shows a non-limiting example of an interface 1 130 in which a listing of outstanding deliveries 1 132 associated with a specific merchant is displayed. In the specific example depicted, the listing of outstanding deliveries 1 132 includes a plurality of entries. In this example, each entry corresponds to a row and conveys a customer's user name, time information (date and time) associated with the placement of the corresponding order 1 138, a shipping method (or choice of transporter) 1 136 and the quantity of products to deliver. Each entry is also associated with control options, for example a user operable control 1 134 labeled "PACK", allowing the specific merchant using the merchant computing device 160a to select a specific entry amongst the listing of outstanding deliveries. For the purpose of simplicity only, the example described in the present document will consider that a single entry is selected from the listing of outstanding deliveries displayed in the interface 1 130. It will however be appreciated that in alternative implementations the interface 1 130 may allow the specific merchant to select multiple entries in the listing of outstanding deliveries destined to a same customer and combine/group them in a same shipment. The process then proceeds to step 906.

At step 906, the specific merchant using the merchant computing device 160a performs a selection of a specific entry amongst the listing outstanding deliveries displayed. In connection with the interface 1 130 depicted in Figure 1 IB, selection of a specific entry is performed by the "clicking" of the user operable control 1 134 (labeled "PACK") corresponding to the desired entry. When the user operable control 1 134 (labeled "PACK") corresponding to the desired entry is "clicked", a shipping details interface is displayed merchant computing device 160a, allowing the merchant to provide specific details related to the shipping of the selected entry. Figure 1 1C shows a non- limiting example of a shipping details interface 1 150. In this specific example, the shipping details interface 1 150 conveys various parameters related to the shipping of the one or more products associated with the selected entry, including (for example but not limited to): a merchant's pick-up address, the customer's delivery address, the transporter service, the product(s) ordered, the weight and size of the package for shipping the product(s), and a proposed date of pick-up. The various parameters related to the shipping of the one or more products associated with the selected entry may be modified through the shipping details interface 1 150. In the example shown, the parameters related to the weight and size of the package for shipping the product(s) include user editable fields 1 154 allowing the merchant to modify these parameters as appropriate by entering the desired values using keyboard or other suitable input device. Similarly, the parameters related to the date of pick-up 1 158 and the transporter service 1 152 can also be modified by providing suitable user editable fields. Drop-down menus or other suitable mechanisms may be provided in the shipping details interface 1 150 for facilitating entry of information. Once the merchant has verified the parameters and made desirable modifications, he can select the "PROCEED" button 1 156 (by "clicking" on it using a suitable input mechanism). Activation of the "PROCEED" button 1 156 causes a shipment confirmation interface to be displayed on the merchant computing device 160a. Figure 1 ID shows a non-limiting example of a shipment confirmation interface 1 170. The process then proceeds to step 908.

At step 908, the specific merchant using the merchant computing device 160a activates a control option to cause information to be provided to the marketplace server 150 (all shown in Figure 1) conveying that the product(s) corresponding to the entry selected at step 906 is(are) ready for pickup at a location associated with the specific merchant. In connection with the shipment confirmation interface 1 170 depicted in Figure 1 1D, this interface displays information including the product(s) that is(are) to be shipped 1 176, the pick-up time 1 178 and the pick-up and delivering locations. The shipment confirmation interface 1 170 also includes some control options for enabling the specific merchant to perform some operations. In the example shown, the control options are in the form of user operable controls 1 174 and 1 172. Once the specific merchant has reviewed the information on the shipment confirmation interface 1 170, information (which may for example be in the form of a message) conveying that the product(s) associated with the selected entry is(are) ready for pick-up can be caused to be transmitted to the marketplace server 150 by "clicking" the user operable control 1 174 (labeled "PROCEED"). In the example depicted, the shipment confirmation interface 1 170 also includes user operable control 1 172, which allows the specific merchant to make corrections. Activation of user operable control 1 172 causes the shipping details interface 1 150 shown in Figure 1 1 C to be displayed once again. Activation of the "PROCEED" button 1 174 causes a print shipment/label interface to be displayed on the merchant computing device 160a. Figure H E shows a non-limiting example of a print shipment/label interface 1 190. The process then proceeds to step 910.

At step 910, the specific merchant, using the merchant computing device 160a, activates a control option to print a shipping label for use in shipping the order. In connection with the print shipment/label interface 1 190 depicted in Figure HE, this interface displays the order/shipping information 1 184 and provides a control option, in the form of user operable control 1 182, labeled "SELECT TO PRINT", for allowing the specific merchant to print a shipping label. In practice, the specific merchant activates the control 1 182, prints the label, sticks it on the box used for the shipment and waits for the transporter to pick it up.

FIGURE 10

With reference to Figure 10, an example of a process, for facilitating modification of unfulfilled orders by a customer in the common marketplace implemented by the system 100 shown in Figure 1 will now be described. Part of the functionality described below may be implemented by transaction module 206 (shown in Figure 2).

Generally speaking in the present application, an order placed by a customer is considered to be unfulfilled if none of the products in the order placed by the customer have yet been shipped. An order placed by a customer is considered to be partly fulfilled if at least some the products in the order placed by the customer have been shipped. An order placed by a customer is considered to be fulfilled if all products in the order placed by the customer have been shipped and delivered.

At step 1000, the marketplace server 150, through the transaction module 206 and the customer accounts module 210, maintains an orders database including information related to orders previously placed by customers. The orders database maps each product in each order with a respective member merchant account and with a respective customer account. Preferably, the orders previously placed by customers are maintained in the orders database at least until the orders are fulfilled by the member merchants however some practical implementations may maintain records of orders even after the orders are fulfilled such as to be able to have a history of orders placed and/or for inventory management purposes. As such, the orders database also maps each product in each order with an identifier indicating whether the product has been delivered ("ordered for product is fulfilled or partly fulfilled") or whether it remains to be delivered ( "ordered for product is unfulfilled"). Step 1000 is analogous to step 802 described with reference to Figure 8 and therefore for the purpose of conciseness will not be described in further detail here. It is to be noted that step 1000 is performed on a continuous basis and the orders database is updated as new orders are placed and deliveries are made in connection with the common marketplace. A step 1002, the marketplace server 150 receives a request from a specific customer using a customer computing module, for example customer computing module 170 in Figure 1 , to access an account associated with the specific customer. The request to access the account associated with the specific customer would include information identifying the specific customer. The identification information may be provided automatically by customer computing module 170 using known methods (for example using a cookie or other suitable mechanism) or alternatively may be provided by the specific customer through a customer login interface including user editable fields. Assuming the request to access the customer account is successful, the marketplace server 150 transmits, through the customer accounts module 210, one or more electronic documents to the customer computing module 170 to cause the latter to display an order modification interface. The order modification interface presents the specific customer with a listing of unfulfilled prior orders placed by the specific customer. The order modification interface provides user interface tools for enabling the specific customer to modify at least one of the unfulfilled prior orders displayed. In a specific example, the order modification interface includes a user operable control for enabling the specific customer to issue a command to effect a modification to an unfulfilled prior order placed in the common marketplace. In a non-limiting example, the user operable control includes a set of input options allowing the customer, using suitable input devices, to:

remove a product originating from a specific member merchant in an unfulfilled prior order;

adding a new product to an unfulfilled prior order; and/or change a transportation parameter associated with an unfulfilled prior order, change a billing address associated with an unfulfilled prior order.

The process then proceeds to step 1004.

At step 1004, the marketplace server 150 receives information from the customer computing module 170, the information conveying a command to effect a specific modification (or a set of specific modifications) to a specific unfulfilled prior order. The process proceeds to step 1006.

At step 1006, the server 150 updates the database of orders in the customer accounts module 210 so that the unfulfilled orders associated with the specific customer reflect the specific modification or modifications. In addition, the listings of outstanding deliveries stored in the merchant accounts module 208 and associated with the member merchant(s) affected by the modification are also updated so that the listings reflect the requested modification. If the specific modification results in a change in the total cost of the original order, a process is initiated for either i) obtaining an additional payment from the specific customer or ii) performing a re-imbursement to the specific customer. As was the case for the processing of a payment associated with a new order, the processing of a payment or re-imbursement is performed with a remote financial services entity using a payment account associated with the common marketplace. Once that is completed, the common marketplace payment account should be credited/debited the appropriate amount based on the required modification or modifications. It is to be noted that since payment of the individual merchants is deferred until after delivery of the ordered products, and since the modification are made to unfulfilled orders (namely orders for which none of the products have yet been shipped), it is not required to reconcile the merchant accounts since the payments related to the order being modified would not yet have been reflected in such merchant accounts. Following this, the process terminates or proceeds to optional step 1008.

At step 1008, which is shown as an optional step, an electronic notification message is sent to the one or more specific member merchants affected by the modification. The contents of the electronic notification message may vary from one implementation to the other. For example the information conveyed by the electronic notification message may be limited to convey that a previously placed order has been modified or that an additional order has been received. Alternately, the electronic notification message may provide specific details regarding the modification or modifications to the order including (for example) a description of the products ordered, a change in quantity of products ordered, a level of urgency with the order and the like. The electronic notification message may be transmitted using any suitable communication mechanism including for example an e-mail message sent to an address associated with the specific member merchant, a SMS message, a facsimile and a voice-messaging service.

FIGURES 12, 13, 14A, 14B, 15A, 15B, 16, 17A and 17B

With reference to Figures 12, 13, 14A, 14B, 15A, 15B, 16, 17A and 17B an example of a process for facilitating the creation of an e-commerce point of transaction for a new member merchant in the common marketplace implemented by the system 100 shown in Figure 1 will now be described. Part of the functionality described below may be implemented by merchant accounts module 208 (shown in Figure 2).

At step 1200, a new account creation interface is provided to a specific merchant desirous of creating a new member account in the common marketplace implemented by the system 100. The specific merchant accesses the common marketplace using a merchant computing device, for example merchant computing device 160a in Figure 1 , and performs an account creation operation through the new account creation interface in order create access an account associated with the specific merchant. During the account creation operation, the specific merchant specifies a plurality of information elements associated with the new member account. In a specific practical implementation, this may performed by using a web browser on merchant computing device 160a to access a merchant account creation website associated with the common marketplace and to provide information identifying the specific merchant. Alternatively, this could be accomplished through a dedicated software application. Figure 13 shows a non-limiting example of a new account creation interface 1300 including user interface tools, which include in this example user editable fields 1302, allowing the specific merchant to enter information such a merchant user name (in this example an e-mail address) and a merchant password to identify the specific merchant. Once the specific merchant has finished specifying a plurality of information elements associated with the specific merchant, the process proceeds to step 1202.

At step 1202, an account creation command is sent from the merchant computing device 160a to the marketplace server 150 including the merchant specific information provided through the new account creation interface. In connection with the new account creation interface 1300 displayed on the example merchant computing device 160a , this is made possible by providing a user operable control 1304, which in Figure 13 is a button labeled "CONNECT". Activation of the user operable control 1304 allows the specific merchant to issue to the marketplace server 150 a command to create an account for the specific merchant in the common marketplace implemented by system 100. The receipt of the account creation command causes the marketplace server 150 to create a new merchant account in the merchant account module 208 (shown in Figure 2) and to store the information provided through the new account creation interface 1300. Once the merchant account creation operation is complete the process proceeds to step 1204 shown in Figure 12. At step 1204, the new member merchant using the merchant computing device 160a accesses a store creation page in the common marketplace system 100 and a plurality of input options are displayed on the display of merchant computing device 160a to enable the new member merchant to specify parameters of a new store (or new e-commerce point of transaction). Figures 14A and 14B show a non-limiting example of a store creation interface 1400. In the specific example depicted, the specific merchant can specify different parameters, including for example a category for their store, a name for their store and a description. The store creation interface 1400 can also prompt the specific merchant, or guide him, in adding other information to describe the e-commerce point of transaction. In this regard, the store creation interface 1400 may include a plurality of input options, for example in the form of user editable fields 1408, for facilitating entry of information by the specific merchant. Drop-down menus, such as the one 1430 shown in Figure 14B, or other suitable mechanisms may be provided in the store creation interface 1400 for facilitating entry of information. It is to be appreciated that the store creation interface 1400 depicted in Figures 14A and 14B was shown for the purpose of illustration only and that alternate practical implementation may differ significantly from the example shown here and may include less or more functionality. For example, functionality for allowing the specific merchant to select and/or add text/graphic elements to his e-commerce point of transaction (such as a color scheme, a logo, a banner, a video, an image, a hyperlink and text for example) may also be provided through store creation interface 1400. The store creation interface 1400 may also provide input options for allowing the specific merchant to add additional web pages to the e-commerce point of transaction, such as for example an "About" page, a "Locations" page conveying the location of physical stores in which the specific merchants sells his products as well as conveying store hours. The store creation interface 1400 may also provide control options for allowing the specific merchant to have a previous of the web pages created through the store creation interface 1400. Such additional functionality is beyond the scope of this application an as such will not be described further here. Once the merchant has provided the parameters related to the new store, he can select the "SUBMIT" button 1404 (by "clicking" on it using a suitable input mechanism).

At step 1206, a store creation command is sent from the merchant computing device 160a to the marketplace server 150 including the parameters related to the new store provided through the store creation interface 1400. The receipt of the store creation command causes the marketplace server 150 to perform a store creation operation in connection with the new merchant account so that information in the merchant account module 208 (shown in Figure 2) reflects the parameters related to the new store provided through the store creation interface 1400. Once the store creation operation is complete the process proceeds to step 1208 shown in Figure 12.

At step 1208, the new member merchant using the merchant computing device 160a accesses a delivery/pick-up details interface in the common marketplace system 100 and a plurality of input options are displayed on the display of merchant computing device 160a to enable the new member merchant to specify order pick-up parameters for the new e-commerce point of transaction. The order pick-up parameters may include, without being limited to, pick-up locations associated with the new member merchant from which products may be picked-up, pick-hours and (optionally) the type of transporter entities that the new member merchants will support. Figures 15A and 15B show non-limiting examples of pages for the delivery/pick-up details interface 1500 and 1550. In the specific example depicted, the delivery/pick-up details interface 1500 shown in Figure 15A provides the new member merchant with user interface tools, in the form of input options, for adding one or more pick-up addresses 1506 where orders can be picked-up from the specific merchant by a transporter entity. In a specific example, the merchant can specify one or several different addresses from where products will be shipped. The pick-up addresses will be used, amongst other in combination with specific transporter entities, in calculating estimates of delivery costs based on a chosen transporter and (optionally) type of delivery service. The interface 1500 may also provides a user interface tool, which in Figure 15A is in the form of selection menu 1504, for providing the new member merchant with input options for specifying one or more transporter entities that it will support. The selection menu 1504 may allow the merchant to choose amongst a set of available transporter entities supported by the common marketplace implemented by system 100 as well amongst different services they wish to use that are offered by the respective transporter (for example normal delivery, express delivery and the like).

It is to be appreciated that while in the example depicted in Figure 15A, the merchant is provided with options for transporter entities, examples of implementation of the system may automatically select default transporter entities (and services) and may therefore not require that these be selected by the new member merchant, which would further simplify the creation of an e-commerce point of transaction. In a specific example of implementation, at least some of the one or more transporter entities that can be supported by the new member merchant will be supported through the common marketplace implemented by the system 100 shown in Figure 1. More specifically, for the transporter entities that will be supported, the system 100 provides respective common marketplace transporter accounts that will be used by the marketplace server 150 (and in particular by the delivery/transport coordinator module 202 shown in Figure 2) to arrange for pick-up and delivery services through different transporter entities. The common marketplace transporter accounts will be shared between different merchants having accounts in the system 100 as described elsewhere in the present document. As such, in accordance with this specific example, in order to enable shipping using for example UPS™ and Canada Post™, the new member merchant does not have the burden of obtaining a transporter account for each of these transporter entities but rather may benefit from already established common marketplace transporter accounts provided through system 100. Advantageously, this may provide significant time savings in terms of setting up a new e-commerce point of transaction. In the specific example depicted, the delivery/pick-up details interface 1550 shown in Figure 15B provides the new member merchant with input options 1554 1552 1556 for specifying timing information, such as for example days/hours during which the new member merchant will be available to allow transporters to pick-up shipments for delivery. It is noted that the timing information may be provided separately for each location from which the new member merchant will be shipping products. In a specific implementation, this information can be used in calculating an estimated delivery dates shown to the customers when an order is placed. Once the merchant has provided the order pick-up parameters, he can select the "SAVE PICK-UP PREFERENCES" button 1508 shown in Figure 15A (by "clicking" on it using a suitable input mechanism). The process then proceeds to step 1210.

At step 1210, a delivery details set-up command is sent from the merchant computing device 160a to the marketplace server 150 including order pick-up parameters provided through the delivery/pick-up details pages 1500 and 1550. The receipt of the delivery details set-up command causes the marketplace server 150 to perform a delivery set-up operation in connection with the new merchant account so that information in the merchant account module 208 (shown in Figure 2) reflects the order pick-up parameters provided through the delivery/pick-up details pages 1500 and 1550. Once the delivery details set-up operation is complete the process proceeds to step 1212 shown in Figure 12. At step 1212, the new member merchant using the merchant computing device 160a accesses a payment details interface in the common marketplace system 100 and a plurality of input options are displayed on the display of merchant computing device 160a to enable the new member merchant to specify payment parameters for the new e-commerce point of transaction. The payment parameters may include, without being limited to, a billing address associated with the new member merchant, banking information associated with the new member merchant and credit card information (to allow for monetary transfers including credits/debits) and (optionally) the type of payment that the new member merchants will support. Figure 16 shows a non-limiting example of a page for the payments details interface 1600. In the specific example depicted, the payment details interface 1600 provides the new member merchant with user interface tools including input options including user editable fields for specifying banking information 1608. The interface 1600 also provides a user interface tool in the form of a selection menu 1604 providing the new member merchant with input options for specifying one or more payment types amongst a set of available financial services entities supported by the common marketplace implemented by system 100.

It is to be appreciated that while in the example depicted in Figure 16, the merchant is provided with options for payment types, examples of implementation of the system may automatically select default payment types and may therefore not require that these be selected by the new member merchant, which would further simplify the creation of an e-commerce point of transaction.

Optionally, at least some of the one or more payment types that can be supported by the new member merchant will be supported through the common marketplace implemented by the system 100 shown in Figure 1. More specifically, for the payment types that will be supported, the system 100 provides respective common marketplace payment accounts that will be used by the marketplace server 150 (and in particular by the finance module 204 shown in Figure2) to arrange for payment (or re-imbursement) processing through different financial services entities. The common marketplace payment accounts are associated with respective financial services entities supported by the common marketplace and are shared between different merchants having accounts in the system 100 as described elsewhere in the present document. As such, in accordance with this specific example, in order to enable payment of orders using for example credit cards (Visa™, Mastercard™, American Express™), PayPal™ and Interac™ the new member merchant does not have the burden of obtaining a merchant payment account for different financial services entities but rather may benefit from already established common marketplace payment accounts provided through system 100. Advantageously, this may provide significant time savings in terms of setting up a new e-commerce point of transaction. Once the merchant has provided the payment parameters, he can select the "SUBMIT" button 1602 shown in Figure 16 (by "clicking" on it using a suitable input mechanism). The process then proceeds to step 1214.

At step 1214, a payment details set-up command is sent from the merchant computing device 160a to the marketplace server 150 including payment parameters provided through the payment details interface 1600. The receipt of the payment details set-up command causes the marketplace server 150 to perform a payment set-up operation in connection with the new merchant account so that information in the merchant account module 208 (shown in Figure 2) reflects the payment parameters provided through the payment details interface 1600. Once the payment set-up operation is complete the process proceeds to step 1216 shown in Figure 12.

It will be appreciated that once steps 1208 to 1214 have been completed, the new merchant account (and the associated e-commerce point of transaction) will be associated with one or more common marketplace transporter accounts associated with respective transporter entities, the common marketplace transporter account(s) being shared between different merchants having accounts in the common marketplace implemented by system 100. The new merchant account (and the associated e-commerce point of transaction) will also be associated with one or more common marketplace payment accounts associated with respective financial services entities, the common marketplace payment account(s) being shared between different merchants having accounts in the common marketplace implemented by system 100. In use, and as described elsewhere in the present document, at least some orders to purchase products placed through the e-commerce point of transaction for the new member merchant will be processed using a common marketplace transporter account to arrange for pickup of the products from the specific merchant and using a common marketplace payment account to arrange for payment of the products.

At step 1216, the new member merchant using the merchant computing device 160a accesses inventory details interface in the common marketplace system 100 providing user interface tools providing a plurality of input options is displayed on the display of merchant computing device 160a to enable the new member merchant. The inventory details interface allows the merchant to specify inventory information, including information related to products to be offered for sale by the specific merchant through the e-commerce point of transaction. The inventory information may include (without being limited to): product name, product description, product category, available quantity, pricing information (including retail pricing and volume pricing), product dimensions/volume and weight (which may be taken into account for calculating shipping costs), a product picture, a product video, product options (colors, type etc ..) and applicable rebate information. Figures 17A and 17B show non-limiting examples of pages for the inventory details interfaces 1700 and 1750. In the specific example depicted, the inventory details interface 1700 shown in Figure 17A provides the new member merchant with user interface tools, in the form of input options 1706, for adding information related to a new product. The inventory details interface 1700 also provide a user interface tool in the form of a control 1704 (labeled "PREVIEW") for allowing the merchant to view information related to the newly created product in a format that will be displayed to a customer. The inventory details interface 1700 also provide a user interface tool in the form of a control 1702 (labeled "CREATE") for allowing the merchant to cause a new entry to be created for the new product in the merchant account associated with the merchant. In the specific example, activate of control 1702 causes inventory details interface 1750 shown in Figure 17B to be displayed merchant computing device 160a. In the specific example depicted, the inventory details interface 1750 shown in Figure 17B provides the new member merchant with additional user interface tools, in the form of input options 1752 and 1760, for providing additional information related to the new product specified through interface 1700 (shown in Figure 17A). The inventory details interface 1750 also provides a user interface tool, in Figure 17A shown in the form of a control 1758 (labeled "CANCEL") for allowing the merchant to cancel the newly created product. The inventory details interface 1750 also provide a user interface tool, in Figure 17B shown in the form of a control button 1756 (labeled "SUBMIT"). Once the merchant has provided the details related to the new product, he can select the "SUBMIT" button 1756 (by "clicking" on it using a suitable input mechanism). The process then proceeds to step 1218.

At step 1218, an inventory update command is sent from the merchant computing device 160a to the marketplace server 150 including inventory information provided through the inventory details pages 1700 and 1750. The receipt of the inventory update command causes the marketplace server 150 to perform an inventory update operation in connection with the new merchant account so that information in the merchant account module 208 (shown in Figure 2) reflects the inventory information provided through the inventory details pages 1700 and 1750. Once the delivery update operation is complete additional products may be added to the merchant account by returning to step 1216 or, if the merchant is done adding products, the creation of the e-commerce point of transaction is complete and may be activated.

Optionally, an e-commerce activation interface (not shown in the Figures) may be displayed on the merchant computing device 160a including a user operable control, which may be in the form of a button, for enabling the new member merchant to activate the new e-commerce point of transaction, for example by "clicking" the button. Alternatively, the e-commerce point of transaction may be automatically activated. Once activated, the e-commerce point of transaction is operational and the member merchant is ready to receive orders (processing transactions) through the common marketplace implemented by system 100.

It is to be appreciated that while the process described with reference to Figure 12 has been described with reference to the creation of an e-commerce point of transaction for a new member merchant in the common marketplace implemented by the system 100 shown in Figure 1, a similar process can be used in connection with modifying an existing account associated with a member merchant. In order to modify an existing account, rather than accessing a new account creation interface at 1200 and sending an account creation command at step 1202, the member merchant would uses his identification information at step 1200 to access his existing account by sending an login command to the common marketplace server 150 and would then be in a position to access any one of the interfaces described with reference to Figure 12, 14A, 14B, 15A, 15B, 16, 17A and 17B to make the desired modifications.

Shared promotional/marketing/searching functionality

Optionally, the common marketplace implemented by the system 100 shown in Figure 1 may provide shared promotional/ marketing/ searching related functionality to the members/subscribers of the common marketplace. In a specific example, the common marketplace server 150 includes a computer program product, which when executed by a programmable system including at least one processor implements a website having a web-page with hyper-links to the websites of independent merchants that are members/subscribers of the common marketplace. The website may also provides searching functionality enabling a potential customer access the website to search for specific independent merchants by entering search parameters in an editable field presented to the potential customer on the website. The search parameters may allow a potential customer, using a customer computing module (such as customer computing module 170 shown in Figure 1 ) to search the members/subscribers of the common marketplace based on, for example, the types of goods/services they offer, the merchant category (flower shop, electronics store), a specific product (using the product name or identifier) and/or the name of the merchant to name by a few. The website may also present the potential customer with logical groupings/categories of members/subscribers of the common marketplace. In a non-limiting example, the website may present the potential customer with a set of categories: a) electronics b) flowers c) women's apparel d) men's apparel e) children's clothing and f) outdoor equipment. Selection of a category by the potential customer (using a pointing device, touch screen voice command or other suitable input means) causes a listing of members/subscribers of the common marketplace associated with that category to be presented to the potential customer. The listing may include all the members/subscribers in that category or a subset of the members/subscribers in that category. For example the subset of members/subscribers may include only members/subscribers that have subscribe to an advertising service provided by the common marketplace. The members/subscribers presented in the listing may be associated with respective hyperlinks so that when a specific member/subscriber is selected by the potential customer (using a pointing device, touch screen voice command or other suitable input means), a website associated with the selected member/subscriber is caused to be displayed to the potential customer on a customer computing module 170.

Specific Practical Implementation

Certain portions of the system 100 depicted in Figure 1 implementing a common marketplace, such as for example marketplace server 150, may be implemented on one or more general purpose digital computers. Figure 18 of the drawings shows a simplified representation of a general purpose digital computer 1800 on which the marketplace server 150 may be implemented and which includes at least one processing unit 1802 and a memory 1804 connected by a communications bus. The memory 1804 stores data 1808 and program instructions 1806. The processing unit 1802 is adapted to process the data 1808 and the program instructions 1806 in order to implement the functions described in the specification and depicted in the drawings. The digital computer 1800 may also comprise one or more I/O interfaces 1810 for receiving or sending data elements to external devices, such as the for sending/receiving information to/from the merchant computing devices 160a-c, the customer computer modules 170, the financial services server 190 and the transporter entity server 180 (all shown in Figure 1). The program instructions 1806 also includes the necessary networking functionality to allow the general purpose digital computer 1800 to communicate with other devices (merchant computing devices 160a-c, the customer computer module 170, the financial services server 190 and the transporter entity server 180 (all shown in Figure 1)) over a computer network (for example a public network such as the Internet). The communication links between the different components shown in Figure 1 can be metallic conductors, optical fibers or wireless and is not critical to the invention. It will be noted that the system 100 depicted in Figure 1 many be of a distributed nature where the marketplace server 150, the merchant computing devices 160a-c, the customer computer modules 170, the financial services server 190 and the transporter entity server 180 (all shown in Figure 1) may be located is different geographical locations. In fact, the different elements shown in Figure 1 need not be located in a same country.

Although specific embodiments have been described in order to illustrate features of the invention, it is to be appreciated that variations are possible and that various modifications will become apparent to those skilled in the art in view of the present description.

Claims

1. A method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, the method implemented by a system including at least one programmable processor and comprising:

a . receiving over the computer network a new order from a computing device associated with a customer, the new order specifying a product originating from a specific member merchant amongst the member merchants in the common marketplace;

b . processing the order to cause at least part of the new order to be fulfilled, the processing of the new order including:

i. communicating with the specific member merchant in the common marketplace to convey receipt of an order involving the specific member merchant;

ii. following receipt of a communication from the specific member merchant conveying that the product specified by the new order is ready for pick-up, communicating with a transporter entity for arranging pickup of the product originating from the specific member merchant specified by the new order from a pick-up location associated with the specific member merchant.

2. A method as defined in claim 1 , wherein arranging pickup of the product includes using a transporter account with the transporter entity, the transporter account being associated with the common marketplace.

3. A method as defined in claim 1 , wherein communicating with the specific member merchant to convey the receipt of the order involving the specific member merchant includes transmitting an electronic notification message to the specific member merchant.

4. A method as defined in claim 3, wherein the electronic notification message transmitted includes information conveying the product originating from the specific member merchant specified by the new order.

5. A method as defined in either one of claims 3 and 4, wherein the electronic notification message is transmitted using at least one of an e-mail message sent to an address associated with the specific member merchant, a short message service (SMS) message, a facsimile and a voice-messaging service.

6. A method as defined in any one of claims 1 to 5, wherein the transporter entity with which pickup of the product is arranged is the specific member merchant thereby allowing the specific merchant to directly arrange for transportation of the product to the customer.

7. A method as defined in any one of claims 1 to 5, wherein the transporter entity with which pickup of the product or arranged is associated with an on-site pickup operation thereby allowing the customer to pick-up the product at the pick-up location associated with the specific member merchant.

8. A method as defined in claim 1 , wherein the method further comprises causing a merchant interface to be displayed on a display device associated with the specific merchant, the merchant interface conveying a listing of outstanding deliveries involving the specific merchant, the listing of outstanding deliveries including a plurality of entries at least one of which is associated with the new order.

9. A method as defined in claim 8, wherein the method further comprises displaying control options through the merchant interface for enabling the specific merchant to:

a . select an outstanding delivery from the listing of outstanding deliveries; and b . provide information conveying that at least one product specified by the selected outstanding delivery is ready for pick-up.

10. A method as defined in claim 8, wherein the method further comprises displaying control options through the merchant interface for enabling the specific merchant to: a . select the at least one entry associated with the new order from the listing of outstanding deliveries;

b . provide information conveying that the product specified by the new order is ready for pick-up; and

c . print a shipping label for use in shipping the product specified by the new order.

1 1. A method as defined in any one of claims 8 to 10, wherein causing the merchant interface to be displayed on the display device associated with the specific merchant is performed following receipt of identification information associated with specific merchant.

12. A method as defined in any one of claims 1 to 1 1, wherein processing the new order further includes:

a . communicating with a payment server module to arrange for payment of the new order by the customer;

b . reconciling an account associated with the specific member merchant to reflect the payment by the customer of the product originating from the specific member merchant specified in the new order.

13. A method as defined in claim 1, wherein the product originating from the specific member merchant specified by the new order is a first product originating from a first specific member merchant, said new order further specifying a second product originating from a second specific member merchant amongst the member merchants in the common marketplace, the second specific member merchant being distinct from the first specific member merchant.

14. A method as defined in claim 13, wherein the processing of the new order includes communicating with the second specific member merchant in the common marketplace to convey receipt of an order involving the second specific member merchant.

15. A method as defined in claim 14, said method comprising, following receipt of a communication from the second specific member merchant conveying that the second product specified by the new order is ready for pick-up, communicating with the transporter entity for arranging pickup of the second product from a pick-up location associated with the second specific member merchant.

16. A method as defined in claim 15, wherein arranging pickup by the transporter entity of the first product from the pick-up location associated with the first specific member merchant and arranging pickup by the transporter entity of the second product from the pick-up location associated with the second specific member merchant both include using a same transporter account with the transporter entity, the transporter account being associated with the common marketplace.

17. A method as defined in claim 14, wherein the transporter entity with which the system communicates for arranging pickup of the first product originating from the first specific member merchant is a first transporter entity, said method comprising, following receipt of a communication from the second specific member merchant conveying that the second product specified by the new order is ready for pick-up, communicating with a second transporter entity for arranging pickup of the second product originating from the second specific member merchant specified by the new order from a pick-up location associated with the second specific member merchant, wherein the second transporter entity is distinct from the first transporter entity.

18. A method as defined in any one of claims 13 to 17, wherein processing the new order further includes:

a . communicating with a payment server module to arrange for payment of the new order by the customer, the communication with the payment server module being performed using a payment account associated with the common marketplace; b . performing an account reconciliation process, the account reconciliation process including:

i. reconciling a first account associated with the first specific member merchant to reflect payment of the first product by the customer;

ii. reconciling a second account associated with the second specific member merchant to reflect payment of the second product by the customer.

19. A method as defined in any one of claims 1 to 18, said method comprising transmitting an order confirmation message to the customer.

20. A method as defined in claim 1, said method further comprising:

a . maintaining records of unfulfilled orders previously placed by customers in the common marketplace;

b . providing an order modification interface accessible over the computer network, the order modification interface being configured for:

i. enabling the customer to view unfulfilled prior orders placed by the customer;

ii. providing a user operable control for enabling the customer to issued a command to effect a modification to an unfulfilled prior order.

21. A method as defined in claim 20, wherein the order modification interface provides input options for allowing the customer to perform at least one of:

ii. adding a new product to an unfulfilled prior order;

iv. changing a billing address associated with an unfulfilled prior order.

22. A method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, the method implemented by a system including at least one programmable processor and comprising:

a . receiving over the computer network orders from computing devices associated with customers, the orders specifying products originating from member merchants amongst the member merchants in the common marketplace;

b . processing the orders to cause at least part of the orders to be fulfilled, the processing of the orders including: i. communicating with a remote transporter entity to arrange for pick-up and delivery of ordered products originating from member merchants in the common marketplace, wherein a same common marketplace transporter account is used when arranging for pick-up and delivery through the remote transporter entity of products originating from at least two member merchants in the common marketplace;

ii. communicating with a remote financial services entity to arrange for payment of ordered products originating from merchants member in the common marketplace, wherein a same common marketplace payment account is used when arranging for payment of products originating from at least two member merchants in the common marketplace; iii. performing a reconciliation process between the common marketplace payment account and accounts associated with the member merchants in the common marketplace to reflect the payments of ordered products.

23. A method for facilitating commercial transactions in a common marketplace, the method implemented by a programmable system including at least one programmable processor and comprising:

a . providing a common marketplace transporter account associated with a transporter entity;

b . providing a common marketplace payment account associated with a financial services entity;

c . processing orders specifying one or more products originating from a specific merchant in the common marketplace to cause at least part of the orders to be fulfilled, the processing of the orders including:

24. A computer program product, tangibly stored on one or more tangible computer readable storage media, for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, the program product comprising instructions that, when executed, cause a programmable system including at least one programmable processor to perform the method defined in any one of claims 1 to 23.

25. A computing system for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, said computing system comprising:

a . a memory unit for storing information related to one or more member merchants in the common marketplace;

b . at least one processor programmed with software, which when executed, configures the at least one processor for implementing the method defined in any one of claims 1 to 23.

26. A method for facilitating creating e-commerce points of transaction in a common marketplace, the method implemented by a programmable system including at least one programmable processor and comprising:

a . presenting a merchant interface on a display device associated with a specific merchant, the merchant interface providing the specific merchant with a plurality of user interface tools for specifying a plurality of information elements associated with the specific merchant;

b . providing a user operable control at the display device associated with the specific merchant, the user operable control allowing the specific merchant to issue to the programmable system a command to create an account for the specific merchant in the common marketplace at least in part based on information provided by the specific merchant through the user interface tools provided by the merchant interface;

c . processing the command issued by the specific merchant to create the account for the specific merchant in the common marketplace to create an e-commerce point of transaction for the specific merchant, the e-commerce point of transaction for the specific merchant being associated with:

i. a common marketplace transporter account associated with a transporter entity, the common marketplace transporter account being shared between different merchants having accounts in the common marketplace;

ii. a common marketplace payment account associated with a financial services entity, the common marketplace payment account being shared between different merchants having accounts in the common marketplace; d . in use, at least some orders to purchase products placed through the e-commerce point of transaction for the specific merchant being processed at least in part using the common marketplace transporter account to arrange for pickup of the products from the specific merchant and using the common marketplace payment account to arrange for payment of the products.

27. A method as defined in claim 26, wherein the user interface tools comprise an inventory details interface tool providing user editable controls for allowing the specific merchant to provide information related to products to be offered for sale by the specific merchant through the e-commerce point of transaction.

28. A method as defined in any one of claims 26 and 27, wherein the user interface tools comprise a new account creation user interface tool enabling entry of information for identifying the specific merchant.

29. A method as defined in claim 28, wherein the information for identifying the specific merchant conveys at least a merchant user name and a merchant password.

30. A method as defined in any one of claims 26 to 29, wherein the user interface tools comprise a delivery details user interface tool enabling entry of information conveying a location where orders can be picked-up from the specific merchant by a transporter entity.

31. A method as defined in claim 30, wherein the delivery details user interface tool enables entry of:

a . the information conveying the location where orders can be picked-up from the specific merchant by the transporter entity; and

b . timing information conveying when orders can be picked up from the specific merchant by the transporter entity.

32. A method as defined in any one of claims 30 to 31, wherein the delivery details user interface tool enables selection by the specific merchant of the transporter entity amongst a set of available transporter entities supported by the common marketplace.

33. A method as defined in claim 32, wherein common marketplace transporter accounts are associated with respective transporter entities in said set of available transporter entities supported by the common marketplace.

34. A method as defined in any one of claims 30 to 31, wherein the common marketplace transporter account associated with the transporter entity is a first marketplace transporter account associated with a first transporter entity, and wherein the delivery details user interface tool enable selection by the specific merchant of the first transporter entity and of a second transporter entity amongst a set of available transporter entities supported by the common marketplace.

35. A method as defined in claim 34, wherein the e-commerce point of transaction for the specific merchant created by the processing of the command issued by the merchant is associated with:

a . the first common marketplace transporter account associated with the first transporter entity, the first common marketplace transporter account being shared between different merchants having accounts in the common marketplace;

. the second common marketplace transporter account associated with the second transporter entity, the second common marketplace transporter account being shared between different merchants having accounts in the common marketplace.

36. A method as defined in claim 35, wherein in use:

a . at least some orders to purchase products placed through the e-commerce point of transaction for the specific merchant being processed at least in part using the first common marketplace transporter accounts to arrange for pickup of products from the specific merchant; and

b . at least some other orders to purchase products placed through the e-commerce point of transaction for the specific merchant being processed at least in part using the second common marketplace transporter accounts to arrange for pickup of products from the specific merchant.

37. A method as defined in any one of claims 26 to 29, wherein the user interface tools comprise a payment details interface tool enabling selection by the specific merchant of the financial services entity amongst a set of available financial services entities supported by the common marketplace.

38. A method as defined in claim 37, wherein common marketplace payment accounts are associated with respective financial services entities in said set of available financial services entities supported by the common marketplace.

39. A method as defined in any one of claims 37 to 38, wherein the common marketplace payment account associated with the financial services entity is a first marketplace payment account associated with a first financial services entity, and wherein the payment details interface tool enables selection by the specific merchant of the first financial services entity and of a second financial services entity amongst a set of available financial services entities supported by the common marketplace, the second financial services entity being distinct from the first financial services entity.

40. A method as defined in claim 39, wherein the e-commerce point of transaction for the specific merchant created by the processing of the command issued by the merchant is associated with:

a . the first common marketplace payment account associated with the first financial services entity, the first common marketplace payment account being shared between different merchants having accounts in the common marketplace; b . the second common marketplace payment account associated with the second financial services entity, the second common marketplace payment account being shared between different merchants having accounts in the common marketplace.

41. A method as defined in claim 40, wherein in use:

a . at least some orders to purchase products placed through the e-commerce point of transaction for the specific merchant being processed at least in part using the first common marketplace payment account to arrange for payment of products in the at least some orders; and

b . at least some other orders to purchase products placed through the e-commerce point of transaction for the specific merchant being processed at least in part using the second common marketplace payment accounts to arrange for payment of products in the at least other orders.

42. A computer program product, tangibly stored on one or more tangible computer readable storage media, for facilitating creating e-commerce points of transaction in a common marketplace, the program product comprising instructions that, when executed, cause a programmable system including at least one programmable processor to perform the method defined in any one of claims 26 to 41.

43. A computing system for facilitating creating e-commerce points of transaction in common marketplace, said computing system comprising:

a . a memory unit for storing information related to one or more member merchants the common marketplace; b . at least one processor programmed with software, which when executed, configures the at least one processor for implementing the method defined in any one of claims 26 to 41.

44. A method for facilitating commercial transactions involving purchase of products over a computer network in a common marketplace, the method implemented by a system including at least one programmable processor, the method comprising:

a . maintaining orders previously placed by customers in a common marketplace, at least some orders including products originating from two or more merchants in the common marketplace;

b . providing a merchant interface accessible over a computer network, the merchant interface being configured for:

i. enabling a specific merchant to view a listing of outstanding deliveries including a plurality of entries associated with ordered products originating from the specific merchant;

c . enabling the specific merchant to provide information to the system implementing the common marketplace conveying that a product associated with an entry in the listing of outstanding deliveries is ready for pick-up;following receipt of information from the specific merchant conveying that a specific product associated with a specific entry in the listing of outstanding deliveries is ready for pick-up, communicating with a transporter entity to arrange for pick-up of the specific product from a pick-up location associated with the specific merchant.

45. A method as defined in claim 44, wherein the specific product conveyed by the information received from the specific merchant is associated with specific transportation parameters, and wherein communicating with the transporter entity to arrange for pick-up of the specific product is performed at least in part based on the specific transportation parameters associated with the specific product.

46. A method as defined in either one of claims 44 and 45, wherein arranging pickup of the specific product includes using a transporter account with the transporter entity, the transporter account being associated with the common marketplace.

47. A method as defined in claim 44, said method further comprising, following receipt of a message confirming delivery of the specific product, performing an account reconciliation process to reconcile an account associated with the specific merchant to reflect a payment associated with the specific product.

48. A method as defined in claim 47, wherein the message confirming delivery of the specific product originates from the transporter entity.

49. A method as defined in claim 44, wherein the transporter entity is a delivery service provided by the specific merchant.

50. A method as defined in claim 44, wherein:

a . a first entry in the listing of outstanding deliveries is associated with transportation parameters conveying a first transporter entity;

b . a second entry in the listing of outstanding deliveries is associated with transportation parameters conveying a second transporter entity;

c . wherein:

i. following receipt of information from the specific merchant conveying that a product associated with the first entry is ready for pick-up, communicating with the first transporter entity to arrange for pick-up of the product associated with the entry from the pick-up location associated with the specific merchant;

ii. following receipt of information from the specific merchant conveying that a product associated with the second entry is ready for pick-up, communicating with the second transporter entity to arrange for pick-up of the product associated with in the second entry from a pick-up location associated with the specific merchant.

51. A method as defined in claim 50, wherein the merchant interface includes user operable controls for enabling the specific merchant:

a . to print a first shipping label for shipping the product associated with the first entry, the first shipping label being derived at least in part based on the transportation parameters conveying the first transporter entity;

b . to print a second shipping label for shipping the product associated with the second entry, the second shipping label being derived at least in part based on the transportation parameters conveying the second transporter entity.

52. A computer program product, tangibly stored on one or more tangible computer readable storage media, for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, the program product comprising instructions that, when executed, cause a programmable system including at least one programmable processor to perform the method defined in any one of claims 45 to 52.

53. A computing system for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, said computing system comprising:

b . at least one processor programmed with software, which when executed, configures the at least one processor for implementing the method defined in any one of claims 45 to 52.

54. A method for facilitating commercial transactions, the commercial transactions involving purchase of products over a computer network from member merchants in a common marketplace, the method implemented by a system including at least one programmable processor and comprising:

a . maintaining orders previously placed by customers in a common marketplace; b . providing an order modification interface accessible over a computer network, the order modification interface being configured for: i. enabling a specific customer to view unfulfilled prior orders placed by the specific customer;

ii. providing a user operable control for enabling the specific customer to issue a command to effect a modification to a unfulfilled prior order placed in the common marketplace;

c . following receipt of information from the specific customer conveying a command to effect a specific modification to a specific unfulfilled prior order, wherein the specific unfulfilled prior order specifies a specific product originating from a specific member merchant amongst the member merchants in the common marketplace and wherein the specific modification affects the specific product, communicating with the specific member merchant to convey that an order modification has been made.

55. A method as defined in claim 54, wherein the order modification interface providing input options allowing the customer to perform at least one of:

ii. adding a new product to an unfulfilled prior order;

iv. changing a billing address associated with an unfulfilled prior order.