WO2001013261A1 - Logistics management system for internet orders - Google Patents

Abstract

A proprietor of a shipment delivery logistics hub (112) receives information from a provider of a product about an order for such product placed by a customer over a public electronic network such as the Internet. Based on the order information and certain predetermined start criteria, the hub system has a plurality of predetermined carriers that can be used in transporting the product from the provider to the customer. The hub handles the financial transactions among the customer, the hub and the carriers checks the feasibility of shipping a product given an estimated pickup date and delivery date and tracks the shipment. The hub shipping and delivery logistic system has particular application to LTL (less than truckload) shipments of goods and arranges for set up services when goods arrive at their destination.

Description

LOGISTICS MANAGEMENT SYSTEM FOR INTERNET ORDERS CROSS REFERENCE TO RELATED APPLICATIONS Applicants claim priority under 35 U.S.C. § 119(e)(1) to United States Provisional Patent Application Serial No. 60/149,501, filed August 17, 1999. The disclosure of that provisional patent application is fully incorporated herein by reference.

TECHNICAL FIELD OF THE INVENTION The present invention relates in general to electronic commerce, and more particularly to methods, systems and software for the ordering, payment processing, transportation and delivery of goods ordered over the Internet by customers from retailers.

BACKGROUND OF THE INVENTION Within the past decade, the Internet has become a significant way in which goods and services are purchased, licensed or leased by customers. Services such as the Amazon.com online bookstore and the E-bav auction web site enjoy great popularity. Typical existing e-commerce web systems will use a single, predetermined third-party shipper to ship all goods ordered with it, such as Federal Express or United Parcel Service (UPS). These conventional air courier and parcel shipping services all have an upper limit of 150 pounds and further tend to be economically uncompetitive when used to ship goods ordered over the Internet. According to one Internet e-commerce methodology, a buyer or consumer is sent to a special shipping site by which the buyer can arrange for shipment.

Presently used methods of fulfilling and shipping orders for Internet- ordered goods are particularly inappropriate for large or bulky items. Larger-than- parcel-sized shipments are conventionally shipped using less-than-truckload (LTL) shipping companies, which pack several such shipments onto a single semi-trailer for over-the-highway travel. To date, there has been no automated process to arrange for the LTL shipping of goods or orders originated over the Internet.

Another issue associated with Internet-ordered goods is the provision of setup services on the customer's premises; setup is often applicable to goods requiring on-site assembly or configuration, such as computers, swing sets, stereos and the like. It would be advantageous to contract for these endpoint services, as well as transportation and delivery services, in an automated manner. Relatively large on-line retailers tend to have well-developed logistic and delivery systems in place. But in small and mid-sized on-line retailers, these logistics systems are often limited in what they are able to perform. A need has therefore arisen for the provision, by a third party, of a logistics system for the use of e-commerce retailers, particularly those retailers which are unable or unwilling to bear the cost of establishing and maintaining an automated shipping logistics system.

SUMMARY OF THE INVENTION The present invention provides methods, apparatus, systems and software for fulfilling orders placed by a customer from the provider of a product over a public telecommunications network, such as the Internet. In a first aspect of the invention, a customer places an order for a product, with a provider of the product, over a public communications network such as the Internet. The provider, in turn, sends this order information to an e-commerce hub which arranges for the transportation and delivery of the product. The hub software automatically selects, based on the order information and predetermined stored criteria, which of a plurality of predetermined carriers should be used to transport the product from the provider to the customer. Once this automatic selection according to predetermined criteria is made, a request for shipping the product is sent from the hub to the carrier so selected. Later, assuming that this request for shipment has been accepted by the carrier, a notification of shipment is sent from the hub to at least one of the provider and the customer, and preferably to both. In preferred embodiment, the third party order information is first received by a "front end" software module that is collocated with the web site of the provider. The remaining functionality is provided at a hub node of the communications network, preferably associated with an Internet address such as a site on the World Wide Web. According to a second aspect of the invention, the hub determines whether the shipment from the provider to the customer will be taking place in a plurality of segments, with different carriers associated with each segment. If it is determined that the shipment will occur in multiple segments, then each of the carriers responsible for those segments receives information on pickup and delivery. The hub monitors and updates a shipment schedule automatically in view of actual pickup and delivery notifications received by the hub from the carriers.

In a third aspect of the invention, the order information sent by the provider to the hub includes an available pickup date and a delivery date requested by the customer. Once one or more carriers have been automatically selected according to predetermined selection criteria, a timeline feasibility study module of the hub determines whether the transportation of and delivery of the product to the customer from the provider is possible within the time period defined by the pickup date and the delivery date. If the transportation and delivery is found to be not feasible, the order for shipment is rejected by the hub. If the order is shown to be feasible, the shipment is arranged.

In a fourth aspect of the invention, in conjunction with receiving order information from the provider, the hub (or the hub^'s bank) receives funds for the shipment of the product, typically directly from the credit card bank of the customer.

Once the hub receives a notification that the product has been delivered by a carrier, an automatic electronic funds transfer (EFT) is authorized between the bank of the hub and the carrier as compensation for the delivery.

In overview of the illustrated embodiment, the system front end (FE), preferably collocated with a provider web site, processes orders, secures and directs funds for the transportation and other services requested, and then turns the transportation services request over to a "back end" hub node for the fulfillment of the requested services. The hub completes the transportation (and possibly setup) services requested while communicating with the consumer, shipper/retailer and, where indicated, service entities.

The present invention to a very large extent automates the arrangement of shipment and delivery of products from an e-commerce retailer to a business or a consumer. A logistics management system for a third party web retailer is provided such that web retailers do not have to devote their internal resources to developing and maintaining shipment, delivery and endpoint setup capabilities themselves.

BRIEF DESCRIPTION OF THE DRAWINGS Further aspects of the invention and their advantages will be discerned by reading the following detailed description, when taken in conjunction with the drawings, in which like characters identify like parts and in which: FIGURE 1 is a high level diagram of an e-commerce logistics management system according to the invention, showing the relationship of the different entities involved in the process and the organization of a logistics hub site; FIGURE 2 is a high-level operations diagram showing process flows of the order fulfillment system according to one embodiment of the invention; FIGURE 3 is an overall financial flow diagram of the invention;

FIGURE 4 is a detailed flow diagram of a component of FIGURE 3 ; FIGURE 5 is a high-level flow diagram of a payment notification process according to the invention;

FIGURE 6 is a high-level flow diagram showing an order-processing component of the invention;

FIGURE 7 is a flow diagram showing order receipt and acknowledgement;

FIGURE 8 is a logical flow diagram showing an order validation / payment information component of the order processing component according to the invention;

FIGURE 9 is a logical flow diagram showing a shipping / service request completion process component according to the invention; FIGURE 10 is a detail of FIGURE 9, showing a carrier /service partner selection component of the process according to the invention;

FIGURE 11 is a further detail of FIGURE 9, showing a shipment cost determination component of a process according to the invention; FIGURE 12 is a logical flow diagram showing a shipping / service request execution component of the process according to the invention;

FIGURE 13 is a logical flow diagram showing a service delivery / expected time frame confirmation component of the invention;

FIGURE 14 is a logical flow diagram of a service delivery / expected time frames confirmation process, particularly concerning an LTL to local delivery segment;

FIGURE 15 is a logical flow diagram illustrating a final fulfillment execution segment according to the invention;

FIGURE 16 is a data flow diagram of the process according to the invention;

FIGURE 17 is a data flow diagram of a dispatcher component of the invention;

FIGURE 18 is a polling thread flowchart of the dispatcher illustrated in FIGURE 17; FIGURE 19 is a processing thread flowchart of the dispatcher illustrated in FIGURE 17; and

FIGURE 20 is a logical flow diagram of a thread timeout process. DETAILED DESCRIPTION OF ILLUSTRATED EMBODIMENT

FIGURE 1 shows an environment in which the logistics management system according to the invention operates, and the principal components of the system. The system is indicated generally at 100. The e-commerce business methodology is, of course, largely based on the public communications network called the Internet 102. According to this well-established methodology, through third-party or wholly-owned Internet service providers, customers 104, who are associated with their own network nodes, place electronic orders for goods with retailer web stores 106 which are associated with further network nodes. The present invention concerns an improved process for automatically arranging the transportation and delivery of the goods ordered from the retailer 106 to the customer 104, largely from a logistics management or hub node of the network that may be distinct from the other nodes.

The retailer 106 will have a commercial relationship with a retailer bank 108 which has electronic funds transfer (EFT) capability and typically is connected to the Internet 102. The customer 104 will have a previous agreement with a credit card issuer bank 110, likewise having EFT capability.

Preferably, most, but not all, of the processing steps according to the invention will take place on a logistics management system associated with a single Internet node 112, sometimes hereinafter referred to as a "hub." The illustrated relationship among the different hardware components of node or hub 112 is exemplary only. The hub 112 has a first router 114 through which all Internet-related communications are made. The first router 114 is in turn connected to a firewall server 116. The firewall server 1 16 has several ports, one of which is connected to a web server 118, while another port thereof is connected to a second router 120. An order for the transportation of goods is initiated from the retailer 106 (and associated front end 140) by way of, e.g., an XML message to the web server 118. The manual posting, at node 112, of an order to the web server 118 is also a possibility.

As will be explained in more detail below, in one embodiment a program called GetData.ASP transfers the XML message to an MSMQ memory located on a commerce server 122. The system is so configured such that only the web server 1 18 can pass information inwardly to the rest of the internal network. The node 1 12 uses the firewall 1 16 to control what network devices are able to communicate with network devices that exist inside of its internal network.

The internal network further includes a database server 124 on which is mounted a database 126 that preferably is written in SQL Server. The internal network also includes a separate financial system 128. In the illustrated embodiment, each of the servers 118. 122 and 124 has the following software installed on it: Windows NT server 4.0, service packs 3 and 4, post service pack 4 Year 2000 Update. Service Pack 4 Hot Fix Rollup, Resource Kit Support Tools, ADSI 2.5 Release Candidate, Microsoft Management Console 1.1. and Microsoft Data Access Controls 2.01 Service Pack 2. The software on server 124 also includes Microsoft SQL Server 6.5 together with SQL Server 7.0 Upgrade, and

Microsoft Internet Explorer 4.0 Service Pack 2.

The commerce server 122 also is loaded with Microsoft Back Office 4.0; Exchange Server Service Pack 2; Site Server 3.0, Commerce Edition; Commerce Server 3.0; the Site Server Commerce Edition Service Pack 2; SQL Server 7.0 Upgrade; Commerce Interchange Pipeline Manager; and a pair of special applications which will be described in more detail below: PC Miler and Czar Lite.

The web server 118 is also preferably loaded with Microsoft Internet Explorer 4.01 Service Pack 2; Site Server 3.0 - Commerce Edition, together with its

Service Pack 2; and Commerce Interchange Pipeline Manager (described in more detail below).

The node or hub 1 12 is. in the illustrated embodiment, controlled by a single business entity having a relationship with a hub bank 130. Further business entities that participate in the process include a series of shipment partners or carriers, three of which (shipping partners 1, 2 and ή) are shown here at 132, 134 and 136. In some instances a parcel carrier 138 is employed in the transportation and delivery process. While this disclosure sometimes refers to entities 132, 138, 134, 136 and 204 as "partners" they usually are not partners in the legal sense but only separate business entities having contractual relationships with the proprietor of hub 112. All of these entities are preferably connected to the Internet through respective web sites. A special front end software application 140 of the invention is associated with each subscribing retailer's web site 106.

An overall operations diagram is shown in FIGURE 2. A customer, such as a consumer or business 104. accesses the retailer's web site 106 and enters an order along with its requested shipping services and payment information. The order information is passed from the retailer web site to the front end application 140. The front end prices the requested shipping services and, upon consumer approval of the cost of both the goods and their shipping and handling, processes the payment and the order.

When the payment is authorized, as by the credit card bank 1 10, the front end 140 sends a payment notification to the main hub 112 to alert it that a payment has been made to the hub bank account 130 (FIGURE 1).

Next, the hub 112 automatically acknowledges receipt of the payment notification by a message back to the front end 140. Once the order is complete, the front end 140 transmits the order information to the hub 1 12. While further processing is taking place, it is the front end 140's responsibility to hold the order information until an available pickup date is communicated from the retailer 200. The order data flows to the hub 112 only when the order has an available pickup date to the front end 140. The order information consists of an order header, which includes information common to the entire order, and an order detail, organized into shipment methods by price table, with the appropriate SKUs identifying each shipped item included in each shipment method. A representative template of such an order appears in Table 1, with the asterisks denoting required fields. "FE" is an abbreviation for the front end application 140.

The hub 1 12 will automatically transmit an acknowledgement of the order back to the front end 140. Then the hub 112 selects the carrier partners 138, 132, 202, and possibly service partner(s) 204, which will be associated with the some segment of the transportation, delivery or setup of the product. A service partner 204 is an entity which will perform a service (such as setup) for the customer 104.

The hub 1 12 will next determine the cost of the individual shipment segments/services in order to fulfil the order, and will send the appropriate shipping/service request documents to the partners 138, 132, 202 and/or 204. The shipping/service request documents contain the specific SKUs of the product order, pickup and delivery information. A representative format for a shipping request document is shown in Table 2.

Each of the carrier partners 132 or 202 (but not a parcel carrier 138) provides a confirmation of business acceptance. By way of default, the hub 1 12 will assume that the business is accepted. Carrier partners 132 or 202 will schedule a pickup date with the retailer/shipper and communicate the scheduled pickup date by to the hub 1 12; once again, this does not apply to a parcel carrier 138. When a carrier partner actually picks up a shipment, it must communicate the actual pickup date to the hub 1 12. With respect to parcel shipments, the hub 1 12 will trace any parcel shipment to confirm its actual pickup date. The hub 112 will then send a shipment status notification to any additional carrier partner in the delivery chain. Hub 112 further sends a notification to the customer 104, alerting him or her as to when his or her shipment will be available for delivery. If the last link in the delivery chain has been reached, such that a final delivery is being made by a delivery agent 202 to a private residence or home office, the delivery agent contacts the consumer 104 to schedule a delivery date, and communicates this date back to the hub 112. When a carrier partner 132 makes the final delivery of its shipment, it communicates the final delivery date to the hub 1 12. In the instance that a service partner 204 is involved, the service partner 204 will complete its final service fulfillment, and communicate the final service delivery date to the hub 1 12. While preferably all of these routines are automated, exceptional situations are treated as exception back routines and are handled manually in the illustrated embodiment.

FIGURE 3 shows an overall financial flow diagram associated with the transportation and delivery process of the invention. The consumer 104 will enter the payment information for his or her order on the retailer web site 106. The front end application 140 authorizes the payment information for the shipping portion of the order and initiates the transfer of funds from the credit card bank 110 to the hub bank account 130. This transfer is shown in further detail in FIGURE 4. The web store 106 will transact with the credit card bank 1 10 through a retailer credit card process 210. Similarly, the front end 140 will communicate to the credit card bank 1 10 through a front end credit card process 212.

Returning to FIGURE 3, when the payment information is authorized, the front end 140 sends a payment notification to the hub 112 to alert it that a payment has been made to its bank account. The hub 112 automatically transmits an acknowledgement of the receipt of the payment notification back to the front end 140. The hub bank 130 will send a daily transaction statement to the hub 112. The hub 112 uses this statement to reconcile payment notifications.

In the order processing process, when a carrier or service partner (illustrated generally at 206) notifies the hub 1 12 of a final delivery of a product or performance of a service, the hub 1 12 initiates an electronic funds transfer (EFT) request to the hub bank 130 to pay the partner 206 for its portion of the delivery/service. The hub bank 130 electronically transfers funds to the partner 206. In parallel to this, the hub 112 sends a remittance advice to the partner 206 to inform the partner 206 of the EFT payment. If any retailer handling charges are associated with an order, the hub 112 sends an EFT request to the hub bank 130 to remit these charges back to the retailer 200 through the retailer bank 108.

An overall logical flow diagram for the payment notification processing segment of hub 1 12 is shown in FIGURE 5. The first step is a payment receipt notification step 300. In this step, payment notification comes in prior to the order request from the hub front end 140. The notification is sent as a real time transaction and is based in XML format. The hub system 112 receives a payment notification which includes fields for the order tracking number, the credit card authorization number, the charge amount and the transaction date. The hub 1 12 will electronically record the payments notification data into the financial activity log database 312 and will record the payments notification status as "received".

Step 302 concerns the acknowledgement of receipt of the payment notification. The hub system 112 generates an acknowledgement of a received payment notification in real time upon receipt of the notification and sends this to the front end 140. It also updates the payment notification status to "acknowledged".

At step 304, the bank account is reconciled. At this step, the accounting process is updated with the transaction in question. The accounting process compares the daily financial activity log with the bank statement. If the accounts are reconciled, the record is marked as valid. If the accounts do not match in a scenario where the bank statement has a record that is not in the financial activity log 312, the missing record is entered into a financial problem log 306 for subsequent human intervention. If the accounts do not match in a scenario where the financial activity log 312 has a record that is not in the bank statement record or data, the system allows 72 hours for the records to be updated. The accounts are then reconciled again. If the accounts still do not match, the record is entered into the financial problem log 306. Upon completion, the payment notification status is updated to "reconciled". At step 308, the financial system 128 is updated. As the payment reconciliation process is completed, the hub 1 12 transfers reconciled payment records into the financial system 128 by order tracking number. A general ledger updating process is initiated for that transaction. The cash account is debited and the unrealized revenue account is credited. The order status is again updated at step 310 and a record is posted to the financial activity log 312.

An overall view of the order processing system according to the invention is shown in FIGURE 6. Order processing is divided into six different overall pieces: a receive/acknowledge order segment 400, an order information validation segment 402, a shipping/service request completion segment 404, a shipping/service request execution segment 406, a service delivery/expected time frames confirmation segment 408 and a final fulfillment execution segment 410. Each of these overall order processing segments will be subsequently described in detail in conjunction with the process flow diagram figures immediately following FIGURE 6.

The receive/acknowledge order segment is shown at 400 in FIGURE 7. It includes a receive order step 412. by which the front end 140 sends an order to the hub 1 12 after payment notification has been sent to the hub 112 and when pickup availability dates for all SKUs (i.e., all SKU-identified items) in the order are available for the retailer. The front end 140 preferably operates in a 7-day/24 hour mode. The order is preferably transmitted over the Internet in real time and in XML format. This step will also record the order information in the sales/orders database 413 and will record the retailer and consumer information in the marketing database

415. At a step 414, the receipt of order is acknowledged. The hub 1 12 generates an acknowledgement of received order in real time upon receipt of the order. The front end 140^"s responsibility is to reconcile the transmitted orders with the hub 112 received orders. If there is any failure of reconciliation, the transaction will be treated as an exception.

Once the order status is updated at step 416, the procedure proceeds to the order information validation module 402, described in detail in conjunction with FIGURE 8.

In this module, the first step is to reconcile the order and payment notification at step 418. The financial activity log 312 is read and verified against an order tracking number. If the order cannot be reconciled to a payment notification in log 312. the order status is changed to "reject." No further action will be taken on the rejected order. The front end 140 is notified of the order rejection by email. This order rejection will include the order tracking number and reason for the rejection.

Assuming successful reconciliation at step 418. this module next will validate the payment to the calculated charge at step 422. In this step, the total charge amount from the payment notification is verified against the component charges from the received order information. After or while step 422 is being executed, the order timeline feasibility is checked at step 424. An order timeline feasibility model is run which compares the consumer placed order date plus any extended number of days plus twenty five days, with the actual data that the order is available for pickup. The order status is changed to "reject" if the order timeline feasibility model indicates that the Consumer placed order date, plus the predetermined extended number of days, plus twenty-five days, exceeds the available date for pickup. No further action is taken on an order taken for this reason. Instead, the front end 140 is notified of the order rejection by email, including the order tracking number and the reason for rejection, which in this instance is a lack of feasibility of delivery timing. Other predetermined timing constraints can be used instead of the 25-day value given here, and the feasibility study may be conducted such that the maximum acceptable delivery period varies according to the shipment mode selected by the customer. The timeline feasibility module 424 is particularly useful in making sure that all maximum delivery periods established by governmental regulation are met. For example, laws or regulations may mandate that goods ordered by a credit card must be received by a consumer within 30 days of the date of order. For transactions which are not affected by delivery-period regulations, the timeline feasibility module 424 may be omitted.

If the reconciliation, validation and timeline feasibility processes 418, 422 and 424 produce successful results, then at step 426 the order status is changed to "active." The sales/orders table 413 is updated. Next, at step 428, a freight classification audit is conducted by comparing the retailer/shipper registered freight class to a calculated freight class. Preferably, this is performed as follows. The shipping weight of the SKU (that is, the ordered item), which is measured in pounds in the registration process, is divided by the cubic volume of the SKU shipping container, which is measured in cubic feet by multiplying its length, weight and height. This will give a pounds per cubic foot result. The result is expressed as a density factor for the SKU. This density factor is cross referenced on a freight class scale that equates freight classifications to densities to determine the calculated freight classification of the SKU. The calculated freight classification is compared to the registered freight classification. If a difference is found between the freight classification given by the retailer/shipper and the freight classification calculated by the hub 112, the cost model for LTL (less-than-truckload) and agent costing will always use the higher of the two freight classifications. Any discrepancy in the freight classification will also trigger an exceptional procedure to notify the retailer and the marketing department of the discrepancy by placing a record in the operations problem log 430. This discrepancy can be used later to refine the freight classification model used by the front end 140. The next module to be performed is shipping/service request completion module 404. which is illustrated in detail in FIGURE 9. In this process, the shipping route is divided into a series of segments Si, S₂, ...S_n, defined as segments of a delivery chain and joined end-to-end with each other in space and time. For each segment S_x in the delivery chain, a carrier selection model or process 440 will be run. Process 440 is shown in more detail in FIGURE 10. First, at step 442 the shipment method is determined from shipment rate tables (not shown). The shipment methods which can be selected include parcel, LTL (less-than-truckload, a process by which several loads are loaded on to a single semitrailer or into a single shipping container), agent, service partner or any combination of the four. A service partner would be selected, for example, where final set up was necessary for the delivered item.

At step 444, each of the shipment partners Si to S_n-ι is determined from the shipment rate tables, which are a portion of a partners database 446. If a parcel post delivery method is involved in any segment of the delivery chain, a retailer preferred parcel option is used. If LTL is involved in any segment of the delivery chain, the process determines if the shipment needs to be performed within one predetermined region. If the shipment is within one region, then the process will select a region-specific LTL carrier. If on the other hand, more than one region is involved, the number of miles between regions is calculated. In the illustrated embodiment, if the shipment distance is over 500 miles, a second LTL carrier is selected. If the shipment is interregional, a predetermined carrier is selected on this basis, which can be either one of the first carriers or a third carrier. A call is made to a commercially available program called PC Miler to calculate the distance between regions. Preferably, zip codes are used as geographical loci for the calculation of distance.

The selection of line-haul partners (Si through S_n-ι) can be affected to a greater or lesser degree by contractual arrangements with these partners: whatever contractual arrangements are in place (such as being appointed as an exclusive or preferred carrier in predetermined situations) is reflected in the predetermined, stored criteria by which the carrier selection step 444 operates.

At step 448. a final delivery agent S_n is determined. This agent is preferably selected by referring to a service agents lookup table. The agent selection is done first by using the exact zip code of the customer; if no match appears in the exact zip code, then an agent is selected on the basis of the first three digits of the zip code. The first three digits define a larger geographic zone in which many zip codes reside. In a preferred embodiment, there is no overlap in the territories of the agents, such that an agent is uniquely selected by this method.

Optionally, an agent may be involved in any other portion of the delivery chain, such as segments Si through S_n-ι. The owner of the hub 1 12 also may enroll a preferred parcel carrier to make it the default choice, giving the seller or retailer the opportunity to override the parcel requirement. The carrier selection model can also select carriers according to other stored, predetermined criteria, such as volume, special equipment, product type, past performance, rate, or a situation in which agent-only deliveries are made for a shorter-distance deliveries. At step 450, a service group number is assigned to a service group, which is composed of all of the partners selected for this shipment. This service group is recorded in a service group database or log 452.

The next module of the process is the determination of a shipment cost at step 454, shown in more detail in FIGURE 1 1. In general, if a difference is found between the freight classification given by the retailer/shipper and the freight classification calculated by hub 1 12. the cost model for LTL and agent costing will always use the higher of the two freight classifications. At step 456. the program determines whether a parcel carrier is involved in anyone of the segments. If so, then at step 458 the parcel rate table for the current shipment is determined. An undiscounted parcel rate table is used. To determine costs, criteria such as the zip codes of the origin, agent or final destination may be used. A zone is determined for the purpose of pricing. The weight per SKU shipping container is retrieved. If available, a retailer/shipper specific service-level discount percentage is used. Using the information in the rate tables 458. the parcel post cost is determined at step 460 on a per-SKU basis.

At step 462, whether an LTL carrier is involved is recognized. Assuming that such an LTL carrier is involved, then at step 464 the LTL discount percentage and minimum charge are determined. At step 466, the segment delivery cost of each SKU item is calculated. A rating program such as Czar Lite is used. The following parameters can be used in making the LTL cost calculation: origin zip code, agent or final destination zip code, weight of the shipment, freight classification (which will be selected as the higher of registered and calculated), negotiated pricing elements for the carrier, and any discount percentage and absolute minimum charge. These costs are done on a per-SKU basis and are summed to get the cost for the total segment.

At step 468. it is determined whether an agent carrier is involved in any segment of the delivery. If so, then at step 470 the agent rate is determined. This is determined according to a pricing table that is previously provided under an agreement between the hub owner and the agent and entered into the system database.

Agent cost is determined at step 472 by using an agent pricing table. There is a standard table that is based on class 100 and below. Unique home zip codes are assigned for agent carriers as the origin/base for the rate table calculations.

The table has destination zones that correspond to mileage. Destination three-digit zip code identifiers, based on the coverage area of the S_n (i.e., the last) carrier, are assigned to each distinct agent home zip code, such that no overlap occurs. Each three-digit zip code identifier, serviced by a unique agent carrier, is assigned a destination zone, which may be based on the mileage distance from the agent home zip code or on unique shipment/destination characteristics as applicable. The table has weight column breaks that relate directly to shipment size (in weight).

Shipments with SKUs above class 100 will have a weighted average calculation applied on the freight classes to determine the weighted average freight class. If this weighted average freight class is greater than 100. then that calculation, as divided by 100, will be the multiplier faction for the rate table. An inside deliver}' charge will be applied if required. The total cost is determined by adding the determined rates and services of all involved parties. If a service partner will be used for, e.g., set up, service partner costing is also included in the model.

Returning to FIGURE 9, at step 474 the profitability of the transaction is determined or estimated. The total price charged to the consumer is retrieved. This total price is calculated by adding the price of all segments of the delivery chain. The total price is compared to the total cost which had been calculated in step 454. If the target profitability margin is not met, a notification of this is sent to the marketing department 476.

At step 478, financial planning reports may be generated, as by use of a Microsoft Access database with estimated profitability data. Finance department personnel can then manually review the reports.

At step 482, a shipping/service request document is prepared. This document is sent to shipping carrier partners and has the fields indicated in Table 2.

Returning momentarily to FIGURE 6, at step 406 the shipping/service request is executed. This process is shown in detail in FIGURE 12. At step 484, an email or fax, based on the carrier-preferred communication method, is used to send the completed shipping/service request document to the shipping partners. Where possible the shipping partners are notified via a more advanced method such as EDI or via an extranet. The LTL contact may be an account manager who routes information through the organization. At step 486. the order status is again updated to indicate the communication with the shipping partners. The order has a shipping partner contact data field which is populated during this step. This step would not apply to a parcel carrier.

This process step assumes that the contacted partners will always accept the business. If the partner does not acknowledge the business, in this embodiment an exception is noted and the procedure is handled manually. The partner^'s initial response should be submitted within 24 hours of the communication of the shipping/service request. Once again referring momentarily to FIGURE 6, at step 408 the service delivery and expected time frames are confirmed. A flow diagram for a scenario in which an LTL carrier is involved is shown in detail in FIGURE 13. At a step 488, the shipping partners must respond with an acknowledgement and a PRO number within a predetermined period of time previously established by agreement, such as 24 hours. Each of the shipping partners will use email (via the Internet or an extranet), fax, or EDI, based on the carrier preferred method, to make this transmission. In an alternative embodiment, an update via web page or fax server can be made. The acceptance confirmation includes the order tracking number, the PRO number, the carrier name, the carrier contact, the carrier phone, the carrier fax and the carrier email. The service group log 452 is updated with the carrier PRO number and the date. The order status is updated at 494 when the last shipping partner acceptance confirmation is received.

At step 490, retailer/shipper bill of lading instructions are completed for the each partner in the first segment of the delivery chain. The bill of lading instructions preferably include the fields shown in the following table.

At step 492, the bill of lading instructions are communicated to the retailer/shipper 200 by means such as email, EDI or extranet.

At step 494, the stored order status is updated to indicate that the bill of lading instructions have been sent.

At step 496, the hub 112 receives a scheduled pick up notification from an LTL or agent carrier. This step would not occur for a parcel carrier. For nonparcel carriers, the scheduled pick up date is preferably contracted to be within a certain number of hours of the retailer-established pick up availability date, or as soon as possible, as required. One chosen period can be 48 hours. If the carrier is unable to perform the service as specified, the carrier sends an exception code. If the 48-hour criterion is not met, the feasibility of the order pick up timeline is again determined by running the order timeline feasibility model discussed elsewhere herein. This is done at step 498. The Si partners use email, extranet email, fax, EDI, based on the carrier- preferred method to do this transmission. Alternatively, the hub web page can be updated. Table 4 shows representative fields of a scheduled pickup date notification record sent by the Si partner to the hub.

The order timeline feasibility step 498 verifies that the scheduled pickup is within a certain number of days, such as twenty-eight days of the order being placed by the consumer. If the scheduled pickup is not within this predetermined period, an exception report is generated. The service group database 452 is updated with the scheduled pickup date.

Step 500 shows that the Si partners must also notify the hub 112 of the actual pickup date within twenty-four hours of the pickup being made. This notification can be made by email, EDI, extranet, fax or by web page update. The actual pickup date notification should include the fields tabulated in Table 5 set forth below.

For parcel carriers, the parcel carrier tracking system is accessed via the Internet. The order tracking number is used to locate the shipment. The following information, shown in Table 6, is recorded.

At step 504, as a shipment has been picked up, either the next partner in the delivery chain or the consumer (if this was the last delivery segment) is notified. If the delivery is a single segment delivery, a delivery notification having the fields shown in Table 7 is sent to the consumer or business 104:

This leads once again to step 494, in which the order status is again updated, this time with the actual pickup date and the estimated time of arrival when the last actual pickup date notification is received. The orders have an actual pickup date field which accepts this data.

At step 502, the financial system of the hub owner is updated. As the partner in the final segment pickup the merchandise for that segment, the hub 112 initiates the payment process for all partners. Data is sent to a separate financial system 128, which updates the general ledger and payables modules with the following transactions for each partner: debit unrealized revenue account; credit revenue account; debit cost of service account; and credit accounts payable account.

The service group database 452 is updated with a date that the consumer or business was notified, and the order status is updated by transmitting to it the "consumer notified" date. At step 506 (FIGURE 13) partners are required to schedule a delivery date with the consumer or business 104. This scheduled delivery date is sent via a standard notification to the hub 1 12 within a predetermined number of business days, such as five, of the pickup of the order or shipment. An exception code will be generated if the service is not capable of being performed. The Si partners may use email (via Internet or extranet), fax, EDI or may update a web page. A scheduled delivery date notification that is sent to the hub 1 12 will have the fields shown in Table 8.

FIGURE 14 illustrates a scenario showing the processing as applied to the last delivery segment, which is executed by the last carrier S_n. The S_π shipper is responsible for making the delivery to the consumer or business. As step 500, the last Si partner (actually partner S„-ι) notifies the hub 1 12 of the actual pickup date within 24 hours of pickup. If the last segment is to be performed by parcel, the hub 112 will retrieve the actual deliver ' date from the parcel company tracking system. In any event, an order snapshot is completed at step 508. A "snapshot" record will preferably have the fields shown in Table 9.

This snapshot is prepared when the first actual pickup date notification comes in at step 508. As additional actual pickup date notifications are receiyed, at step 510 the snapshot is updated.

At step 512, a delivery bill is completed. The bill of lading preferably should have the fields shown in Table 10. At step 514. this bill of lading is sent to the S_n partner, shown at 516. Order status is updated at 518 with the expected delivery date to the S_n partner.

In addition to the bill of lading, the order snapshot is also sent to the S_n partner at a step 520.

At step 522, after any partner informs the system of that partner's actual delivery date, the hub 112 will initiate the payment process for that partner. Data is sent to the financial system 128, which updates the general ledger and payables modules for the partner. These transactions include debit unrealized revenue account, credit revenue account, debit cost of service account and credit accounts payable account

When the S_n partner receives the last ETA update, at step 524, the S_n partner sends an acceptance confirmation within 24 hours of the last segment notified as moving, with the fields shown in Table 11

The order status is updated with acceptance confirmation. The financial system 522 is also updated at this time, as a further partner has completed its delivery segment

At step 526, the consumer is notified with a delivery notification. This delivery notification can be sent by email and preferably has the following fields as shown in Table 12.

The order status is again updated, this time to indicate that the consumer has been notified.

At step 528, when the S_π partner schedules an appointment with the consumer, the S_n partner will send a scheduled delivery notification, preferably within five business days of actual receipt date of order or segment, via email, EDI or fax. The scheduled notification record preferably has the fields shown in Table 13:

The order status is updated at this time with a scheduled final delivery date.

The last module or procedure in the in the overall process is to execute final fulfillment at step 410 (FIGURE 6), illustrated in more detail in FIGURE 15. At step 530. as any partner in any segment fulfills the deliver}' for their segment, the partner sends a final fulfillment confirmation to the hub 112. This final fulfillment confirmation preferably is sent within 24 hours of the actual delivery by email, fax or web page updating methods. The final fulfillment confirmation record preferably has the fields shown in Table 14.

Where the final delivery is by parcel, a parcel carrier tracking system (not shown) is accessed via the Internet, using the hub order tracking number to locate the shipment. Information similar to that shown in Table 14 is retrieved and recorded.

At step 532, the order status is once again updated. The service group file 452 is updated as individual notifications come in. The order status is updated when the final partner notification is received.

After all the partners in all segments have fulfilled the business for their segments and the order has been finally delivered to the consumer, the actual total cost is confirmed at step 534.

The comments fields on the final fulfillment confirmation documents are inspected for additional payment requests from partners. If any exist, these are entered into the problem log 536.

At step 538. actual profitability is confirmed. This is performed by collecting all of the cost revisions to determine the actual total cost. This actual total cost of the order is compared with the actual total price paid to partners. The marketing department 415 is notified as the actual profitability of the order is determined. Preferably, the marketing department 415 has established procedures to track profitability problems in all segments across the delivery chain for that order as well as the pricing model. The marketing department 415 approves payment to the partners via path 540.

At step 542, for each transaction approved by the marketing department 415, the hub 112 initiates the cash disbursement process to the partner of each segment of the delivery. The hub 1 12 sends notice to the financial system 128 to initiate electronic funds transfer (EFT) payment to the hub partner 206. The hub owners accounts payable account is debited and the cash account is credited. As part of a scheduled batch process, the financial system 128 sends EFT requests to the hub bank 130, which hands the payment to the partners 206.

As step 554, remittance advices are prepared and sent to all partners receiving payment to notify them of the payment. Finally, the order status is again updated to indicate that the partners have been paid. The order status in this instance is "closed".

The data flow of the system is illustrated in FIGURE 16. The hub 112, from an architectural standpoint, is composed of two processing areas that, in one embodiment, reside on three different server machines. These two processing areas consist of a receiving area 600 and a data processing area 602. It is preferred that the data processing mechanism be distinctly separated from the data receiving mechanism in order to minimize the potential load on the receiving commerce server and assure timely data receiving. The receiving side 600 of the system deals strictly with the process of getting the data, while the processing area 602 incorporates the logic of the business rules described in conjunction with FIGURES 6-15. The business rules logic for the processing is handled by a different commerce interchange pipeline (CIP2) which is invoked by the dispatching mechanism only after the processing pipeline (CIP1) 604 successfully posts the information into SQL database tables. In the illustrated embodiment, the system 112 includes a Microsoft Message Queue (MSMQ) 606, the Commerce Interchange Pipeline (CIP) Phase 1.0 603 as above mentioned, the Commerce Interchange Pipeline (CIP) Phase 2.0 604, with certain integrated COM objects 608 and 610, a dispatching service mechanism 612, and SQL Server 614 and access data reporting tools 616.

The Microsoft message queue (MSMQ) mechanism 606, 618 is used to store the order/payment data in the queue so as to be accessible by both the receiving and processing sides of the system 1 12. The MSMQ mechanism 606, 618 is used as a communication engine between two sides of the system to assure timely data receiving and processing. In the illustrated architecture, there are two queues, a first queue 606 and a second queue 618. The first queue is used to receive new messages arriving from the receiving side of the system, while the second queue 618 is used as a temporary storage while the message is being processed in the message processing side 602 of the system. This mechanism prevents loss of data in case of potential crashes and failures.

CIP Phase 1 603 is used to validate and store information in the SQL Server database. The processing pipeline 603 unwraps the XML header, translates the XML to a format accessible by the remaining pipeline components, writes the order data into the SQL database tables using VBScript programs, and sends a receipt email to the originate of the order. CIP 2 604 is used for business process steps 402-408 (FIGURE 2). This pipeline 604 does not contain an XML unwrapping component, since the data is read from the SQL Server database table 614 in the form of distinct fields. The CIP pipeline 604 contains calls to COM objects 608 and 610 to implement the process of service assignment and shipping cost calculation.

A dispatching service mechanism 612 is used to invoke the pipeline 603 upon arrival of a new message in the MSMQ 618. The dispatcher will inyoke the pipelines 604 upon successful completion of pipeline 603. Preferably, an error trapping mechanism is implemented in the dispatcher 612 to avoid potential crashes and failures. In one embodiment, the dispatcher runs as a Windows NT service.

The Microsoft SQL Server 614 is used to store information pertinent to the order and payment.

The dispatcher 612 is a multi-threaded application. Dispatcher 612 performs multiple attempts for successful CIP execution before a message is recorded as a failure. This minimizes failures due to temporary problems such as data locks in the database. Retries are handled using a second queue with the number of retries specified as a configurable parameter in a dispatcher configuration file.

The main dispatcher application continually pulls messages from the message queue 602. When a new message arrives, if a retry count is greater than a maximum, as specified in the configuration file, an error in the database is logged and the message is discarded. Otherwise, the message is removed from queue 606. a counter is incremented by one and a message is added to the second queue 618. The dispatcher starts a new thread to handle the message. Further, the dispatcher monitors runaway threads and determines whether any of the threads have been executing for more than a predetermined timeout. If any such threads persist, they will be killed by the dispatcher 612. The dispatcher 612 will perform a "peak" on the message in the queue 618, will add appropriate components to the dictionary and then start processing the pipeline 603. Since pipeline processing is synchronous, the thread will wait for the CIP 603 to return. The CIP is responsible for removing the message from the queue if the CIP processes the message successfully. When the thread resumes control, it checks to see if the message is still within the queue 618. If it is, the thread will remove the message from queue 618 and return it to queue 606. Before exiting, the parent process is informed. Crashes in the pipeline are trapped by using try/catch blocks in C++.

Certain of the business rules or steps in pipeline 604 call functions within the component object model (COM) objects. These objects are written as standalone applications and are invoked in the pipeline 604. Each object has its own entry in the system registry. COM object 608 as illustrated in FIGURE 16 is actually a group of COM objects including an agent assignment COM object, used to assign agents; a parcel assignment COM object, used to assign parcels; and an LTL assignment COM object, used to assign LTLs. There is also a shipping services costing COM object group 610. which includes an agent shipment COM object that is used to provide shipment calculation for agents, a parcel shipment cost COM object used to provide shipment calculations for parcels, and an LTL shipment cost COM object that is used to provide shipment cost calculation for the LTLs. At least two other COM objects are used by pipeline 604: a PC miler, object 621 and a Czar Lite object 622. These COM objects are commercially available from ALK Associates and Southern Motor Carriers, respectively. The LTL assignment object contained within COM object group 608 invokes the PC Miler COM object 621, to calculate the mileage between two locations. The LTL shipment calculation COM object contained within the COM object group 610 invokes the Czar Lite program COM object 622 to determine LTL shipment rates. This last steps corresponds to step 466 (determine LTL costs using rating program) in FIGURE 1 1. Other COM objects can be used to perform other components of the process. The data flow of dispatcher 612 is more particularly illustrated in

FIGURE 17. The dispatcher retrieves an XML message from the hub queue 606. It increments the retry counter; if the counter is greater than a predetermined maximum, the message is logged as an error and discarded. For other messages, the dispatcher writes the message to the backup queue 618 and starts a thread to handle the message. The thread creates an NT port and associates it with the queue 606. The port will be notified whenever there is a message in the hub queue 606.

A polling thread flowchart is shown in FIGURE 18. The polling thread 630 will wait at 700 for any new messages in the queue. The polling thread 630 removes the message from the queue 606 at stop 702. If at step 704 the retry counter is greater than the predetermined maximum, at step 706 the message is logged as an error. Otherwise, at step 708 the thread 630 will increment the counter by one. It will then (at step 710) send the message back to the backup queue 618. It will also start a message processing thread at step 712. Preferably, only one polling thread is run.

FIGURE 19 illustrates a processing thread flowchart. At step 662, a monitoring thread 664 is notified (see FIGURE 20). The processing thread executes the pipeline 603 or 604 at step 666. A branch at step 668 will occur according to whether an error in the thread occurred. If no error occurred, then the message will be located in a backup queue at 670, removed at step 672, the monitoring thread 664 will be monitored at step 674 and the thread will stop at 676. If an error has occurred, at step 678 the thread will locate the message in the backup queue, remove the message and transfer to the hub queue at step 680. notify the monitoring thread at 682, and stop at 684.

A flowchart for the monitoring thread is shown in FIGURE 20. At regular intervals, the pipeline will write to an update log. The monitoring thread will check this log for the last update by the thread. If there has not been any activity by a thread for a timeout period at step 690, the processing thread will be terminated at step 692 by the monitoring thread.

While preferred embodiments of the present invention have been described in the foregoing detailed description, the present invention is not limited thereto but only by the scope and spirit of the appended claims.

Claims

WE CLAIM:

L A method enabling a third party to arrange for the shipment of an order from a provider to a customer, wherein the order was placed by a customer from a provider of a product over a communications network, the method comprising the steps of: receiving by the third party order information from the provider about an order which has been placed by the customer: automatically selecting, based on the order information and predetermined stored criteria, which of a plurality of predetermined carriers different from the third party should be used in transporting the product from the provider to the customer; responsive to said step of selecting, transmitting a request for shipping to the one or more selected carriers; and sending a notification of shipment to at least one of the provider and the customer.

2. The method of Claim 1, wherein said step of receiving is performed by front end software collocated with the web site of the provider.

3. The method of Claim 1, wherein said step of selecting includes the step of selecting one or more carriers based on predetermined, stored criteria including distance of shipment.

4. The method of Claim 1, wherein said step of selecting includes the step of selecting one or more carriers based on predetermined, stored criteria, the criteria selected from the group consisting of carrier identity, type of shipment, type of product, historical rate of success and mode of shipment requested by the customer.

5. A method for fulfilling an order placed by a customer from a provider of a product over a communications network, comprising the steps of: receiving order information from the provider about an order for the product which has been placed by the customer; determining that a shipment from the provider to the customer will take place in a plurality of shipping segments; automatically selecting, based on the order information and predetermined, stored criteria, which of a plurality of predetermined carriers should transport the product over each shipping segment; receiving, from each of the carriers, information on when each of the carriers pick up the product and when each of the carriers deliver the product; and responsive to said step of receiving, monitoring and updating a shipment schedule to effect a delivery to the customer.

6. A method for use by a third party in arranging for the delivery of an order placed by a customer from a provider, different from the third party, of a product over the Internet, comprising the steps of: receiving order information from the provider about an order for the product which has been placed by the customer, the order information including a requested pickup date from the provider and a requested delivery date to the customer; determining which of a plurality of carriers different from the third party should transport the product from the provider to the customer; automatically performing a timeline feasibility study to determine whether transportation of and delivery of the product to the customer from the provider by any of the carriers is possible within the time period defined by the pickup date and the delivery date; and if said transportation and delivery is not possible, rejecting the order by the third party.

7. A method for use by a third party in arranging for the delivery of an order placed by a customer from a provider, different from the third party, of a product over a communications network, comprising the steps of: receiving order information from the provider about an order for the product which has been placed by the customer; receiving, for the account of the third party, funds for the shipment of the product; selecting, according to the order information and stored predetermined criteria, one or more carriers from a plurality of predetermined carriers different from the third party for a task of transporting the product from the provider to the customer; receiving, by the third party, a notification that the product has been delivered by a carrier; and responsive to said last step of receiving, making an automatic electronic funds transfer from the third party to the carrier as compensation for the delivery.

8. A method for arranging shipment and delivery, by a hub associated with a first node of a global communications network, to a customer of a third-party provider of products, the third-party provider associated with a second node of the network, the method comprising the steps of: receiving order information from a provider concerning at least one product to be shipped to a customer; assessing a shipment charge to be charged to the customer, and communicating the shipment charge to the customer; processing a payment made by or on the behalf of the customer for the shipment charge; receiving an available pickup date at which the product will be available to be picked up from the provider; selecting, based on the order information and on stored, predetermined criteria, at least one carrier to transport and deliver the product to the customer from the provider; responsive to said steps of receiving order information and selecting at least one carrier, sending bill of lading data from the hub to the provider so that the provider can prepare a bill of lading using the bill of lading data; receiving an actual pickup date from a selected carrier by the hub after the carrier has actually picked up the product; advising the customer, by the hub, of the actual pickup date; receiving, from a selected carrier, an actual delivery date to the customer; and responsive to the last said step of receiving, automatically making a remittance to the carrier.

9. A system for arranging the transportation and delivery of an order for at least one product from a provider having an associated provider node on a public communications network to a customer of the provider, comprising: a hub node on the public communications network distinct from the provider node; order receipt and acknowledgement means associated with the hub node for receiving and acknowledging an order from a provider node: carrier selection means associated with the hub node for automatically selecting, based on information in the order and on predetermined, stored criteria, one or more carriers for transporting and delivering the product to the customer; shipping request generation means associated with the hub node for generating a shipping request to said one or more carriers; and shipment notification means associated with the hub node for notifying at least one of the provider and the customer that shipment and delivery of the product has been arranged.

10. The system of Claim 9, and further comprising: shipping request acceptance means associated with the hub node for receiving, from said one or more carriers, an acceptance of the shipping request, said shipment notification means notifying at least one of the provider and the customer responsive to acceptance of the shipping request.

11. The system of Claim 9. wherein said predetermined, stored criteria include distance of shipment.

12. The system of Claim 9. wherein at least one of said predetermined, stored criteria are selected from the group consisting of carrier identity, type of shipment, type of product, historical rate of success and mode of shipment requested by the customer.

13. The system of Claim 9. wherein the public communications network includes a customer node associated with the customer, the shipment notification means notifying both the customer and the provider.

14. The system of Claim 9. wherein the public communications network is the Internet.

15. A system for the transportation and delivery of an order for at least one product from a provider having an associated provider node on a communications network to a customer of the provider, comprising: a logistics management node on the communications network distinct from the provider node; order receipt and acknowledgement means associated with the logistics management node for receiving and acknowledging an order from the provider node; shipping segment determination means associated with the logistics management node for determining that a shipment from the provider to the customer will take place in a plurality of segments; carrier selection means associated with the logistics management node for selecting, based on order information and predetermined criteria stored in a memory coupled to the carrier selection means, which of a plurality of predetermined carriers should transport the product over each shipping segment; pickup and delivery information receiving means associated with the logistics management node for receiving, from each of the selected carriers, information on when each of the carriers pick up said at least one product and when each of the selected carriers deliver said at least one product; and monitoring and updating means associated with the logistics management node for monitoring and updating a stored shipment schedule to effect delivery to the customer.

16. A system for the transportation and delivery of an order for at least one product from a provider having an associated provider node on a communications network to a customer of the provider, comprising: a logistics management node on the communications network distinct from the provider node; order receipt means associated with the logistics management node for receiving an order from the provider node, the receipt means receiving a requested pickup date from the provider and a requested delivery date to the customer; carrier selection means associated with the logistics management node for selecting which of a plurality of predetermined carriers should transport said at least one product from the provider to the customer; a timeline feasibility determination means associated with the logistics management node for determining whether transportation of and delivery of said at least one product to the customer from the provider by the selected carriers is possible within the time period defined by the pickup date and the delivery date; and order rejection means coupled to the timeline feasibility means for rejecting a request for transporting said at least one product if the timeline feasibility means determines that said transportation and delivery are not possible within the given time period.

17. A medium on which has been pre-recorded a machine-readable computer program which, when executed by processor means, is capable of performing the following steps: receiving product order information from the provider of a product, the product order having been placed over a communications network by a customer of the provider; automatically selecting, based on the product order information and predetermined stored criteria, which of a plurality of predetermined carriers should be used in transporting the product from the provider to the customer; responsive to said step of selecting, transmitting a request for shipping to the one or more selected carriers; and sending a notification of shipment to at least one of the provider and the customer.

18. The medium of Claim 17, wherein the product order contains orders for a plurality of products, said step of automatically selecting taking into account the type of each product in determining which carrier should be selected.

19. The medium of Claim 17, wherein a portion of said machine-readable computer program is adapted to be executed by processor means in the control of the provider, said portion performing said step of receiving product order information.

20. The medium of Claim 17, wherein said step of selecting includes the step of selecting one or more carriers based on predetermined, stored criteria including distance of shipment.

21. The medium of Claim 17, wherein said step of selecting includes the step of selecting one or more partners based on predetermined, stored criteria, the criteria selecting from the group consisting of carrier density, type of shipment, type of product, historical rate of success and mode of shipment requested by the customer.

22. A medium on which has been pre-recorded a machine-readable computer program which, when executed by processor means, is capable of performing the following steps: receiving product order information from a provider of at least one product, about an order for said at least one product which has been transmitted by a customer to the provider over a communications network; determining that a shipment from the provider to the customer will take place in a plurality of segments; automatically selecting, based on the product order information and predetermined, stored criteria, which of a plurality of predetermined carriers should transport said at least one product over each shipping segment; receiving, from each of the carriers, information on when each of the carriers pick up the product and when each of the carriers deliver said at least one product; and responsive to said step of receiving, monitoring and updating a shipment schedule to effect a delivery to the customer.

23. A medium on which has been pre-recorded a machine-readable computer program which, when executed by processor means, is capable of performing the following steps: receiving product order information from a provider of at least one product, about an order for said at least one product which has been transmitted by a customer to the provider over a communications network, the product order information including a requested pickup date from the provider and a requested delivery date to the customer; determining which of a plurality of carriers should transport the product from the provider to the customer; automatically performing a timeline feasibility study to determine whether transportation of and delivery of said at least one product to the customer from the provider by any of the carriers is possible within the time period defined by the pickup date and the delivery date; and if said transportation and delivery is not possible within the time period, rejecting a request from the provider to ship said at least one product.

24. A medium on which has been pre-recorded a machine-readable computer program which, when executed by processor means, is capable of performing the following steps: receiving product order information from a provider of at least one product, about an order for said at least one product which has been transmitted by a customer to the provider over a communications network; receiving an indicium that funds have been transferred from the provider to a logistics manager; selecting, according the product order information and stored predetermined criteria, one or more carriers from a plurality of predetermined carriers different from the logistics manager for a task of transporting said at least one product from the provider to the customer; receiving, by the logistics manager, a notification that said at least one product has been delivered by a carrier; and responsive to said last step of receiving, making an automatic electronic funds transfer from the third party to the carrier as compensation for the delivery.

25. A medium on which has been pre-recorded a machine-readable computer program which, when executed by processor means, is capable of performing the following steps: receiving, at a first node of a communications network, product order information from a provider located at a second node of the communications network, the product order information concerning at least one product to be shipped to a customer located at a third node of the communications network; assessing a shipment charge to be charged to the customer, and communicating the shipment charge to the customer: processing a payment made by or on the behalf of the customer for the shipment charge; receiving an available pickup date at which said at least one product will be available to be picked up from the provider; selecting, based on the order information and on stored, predetermined criteria, at least one carrier to transport and deliver said at least one product to the customer from the provider; responsive to said steps of receiving order information and selecting at least one carrier, sending bill of lading data from the first node to the provider so that the provider can prepare a bill of lading using the bill of lading data; receiving, at the first node, an actual pickup date from a selected carrier after the carrier has actually picked up the product; advising the customer, from the first node, of the actual pickup date; receiving, from a selected carrier, an actual delivery date to the customer; and responsive to the last said step of receiving, automatically making a remittance to the last said carrier.