WO2002052378A2 - System for the provision of goods and services over a distributed communication network - Google Patents

System for the provision of goods and services over a distributed communication network

Info

Publication number
WO2002052378A2
WO2002052378A2 PCT/US2001/049774 US0149774W WO02052378A2 WO 2002052378 A2 WO2002052378 A2 WO 2002052378A2 US 0149774 W US0149774 W US 0149774W WO 02052378 A2 WO02052378 A2 WO 02052378A2
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
order
process handler
orders
stock
Prior art date
Application number
PCT/US2001/049774
Other languages
French (fr)
Other versions
WO2002052378A3 (en
Inventor
Gary Novitzkas
Darren Koenig
Water Virgina
Jeff Tyson
Jan Sleigh
Igor Staniosavljev
Brady Hoak
Vlada Askkovic
Original Assignee
Pushloop Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pushloop Technologies, Inc. filed Critical Pushloop Technologies, Inc.
Priority to AU2002231205A priority Critical patent/AU2002231205A1/en
Priority to US10/451,767 priority patent/US20040111286A1/en
Publication of WO2002052378A2 publication Critical patent/WO2002052378A2/en
Publication of WO2002052378A3 publication Critical patent/WO2002052378A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/024Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]

Definitions

  • the present invention generally relates to interactive computer systems, such as interactive Web sites on the Internet and to the provision of goods or services over a distributed communication network, such as the Internet.
  • the invention relates to a process and a system for providing real-time logistics and fulfillment services for orders placed online.
  • Computer networks such as the Internet, intranets, and virtual private networks (“VPN's"), have become increasingly popular for conducting all types of transactions remotely, such as the purchase of products and services or the tracking and coordination of inventory and logistical information.
  • the Internet is a particularly popular medium for these transactions due to the convenience that the purchaser is able to access an unlimited amount of information and can purchase all types of products and services from a single location over an easily accessible public network.
  • the present invention is directed to a real-time complete logistics and fulfillment system for orders placed on-line that incorporates a real-time closed-loop communication engine to each merchant, having an auto-archive and resubmission capabilities, which provides guaranteed message delivery and response over the Internet and/or other communication media (such as WAP, 1-Mode, etc.).
  • the preferred embodiment of the communication engine of the present invention utilizes two modules, a merchant communication module for communicating with a merchant's network servers, and processing communication module for communicating with the merchant communication module and a process handling system.
  • the merchant communication module is preferably an object that is installed on a merchant's server, which is programmed to send requests to a front-end communication module, and to await a real-time response before allowing further processing of the request.
  • the front- end communication module is preferably installed on an independent, centralized server from the merchant server and the vendor server, although not limited thereto.
  • the front-end communication module is preferably programmed to await requests from the merchant communication module, process them internally, and then send the appropriate response.
  • Real-time logistics and fulfillment may be accomplished in the present invention among many different merchant and vendor systems by utilizing a platform built on open technology, such as extensible Markup Language (“XML”), which incorporates pre-configured, integrated components for major commerce servers, easy integration with existing solution vendors, such as customer resource management (“CRM”) and payment service providers, and secure access to reporting tools.
  • XML extensible Markup Language
  • CRM customer resource management
  • the present invention may also incorporate a managed service provision network that draws warehousing, delivery and fulfillment services from multiple vendor suppliers and offers them as a single, integrated supplier.
  • a suite of business modeling and analysis tools streamlines operations and improves customer service. This preferably includes real time landed cost analysis, real time inventory checks, stock level triggers and global stock level balancing; and allows for the complete tracking of orders from submission to the merchant through delivery to the customer.
  • Figure 1 is a diagram of a preferred embodiment of the programmed components of the system of the present invention.
  • FIG. 2 is a diagram overview of the features of the present invention.
  • Figure 3 is a flow chart of the process steps of the system of the present invention.
  • a computer such as a laptop, palm PC, desktop or workstation, a network server, a mainframe, an electronic wired or wireless device, such as for example, a telephone, an interactive television, such as for example, a television adapted to be connected to the Internet or an electronic device adapted for use with a television, a cellular telephone, a personal digital assistant, an electronic pager, and a digital watch.
  • a computer, computer system, or system of the hvention may operate in communication with other systems over a communication network, such as, for example, the Internet, an intranet, or an extranet.
  • the information to be transmitted in the present invention may be in the form of e-mail, Web pages, text files, or any other conventional electronic format capable of conveying information over a communication network.
  • the operation of these media in transmitting information are well known to those of ordinary skill in the art, and will not be further elaborated upon here.
  • Figure 1 is a diagram of the general components of the preferred embodiment of the present invention configured to provide a real-time logistics and fulfillment solution among a customer, a merchant, and a supply vendor.
  • a vendor supplier and a merchant may be one in the same.
  • the preferred embodiment of the present invention as described below incorporates the use of a separate merchant, vendor, and central server, any number of servers or a single server may be used to operate any and all aspects of the claimed invention.
  • these components include Merchant Installation Module 1, Communication Engine 2, Front-End 3, Merchant Tools 4, End-User Tools 5, Business Logic 6, Database 7, Knowledge Management 8, Backend 9, Operational Audits 10, and XML Translation Solution 1 1.
  • Merchant Installation Module 1 Communication Engine 2
  • Front-End 3 Merchant Tools 4
  • End-User Tools 5 Business Logic 6
  • Database 7 Knowledge Management 8
  • Backend 9 Operational Audits 10
  • XML Translation Solution 1 XML Translation Solution 1
  • MIM 1 is preferably a software package that is installed onto a merchant's server (which is typically a Web server in embodiments of the invention operated over the Internet). IM 1 is programmed in a conventional manner to enable merchants to automate the real-time submission of data to Communication Engine (CE) 2 with a built-in response system.
  • CE Communication Engine
  • the programming of MIM 1, and all of the components of the system of the present invention, may be accomplished using any one of a number of conventional programming languages/systems, such as Visual Basic, JAVA, ASP, PERL, and the like, operating on any one of a number of conventional platforms, such as UNIX or Windows NT.
  • MIM 1 is also programmed to secure real-time access to database 7 (described in more detail below). If a third party supply vendor is used, MIM 1 is also programmed to enable merchants to submit sales orders to the vendor for the fulfillment and real-time receipt of tracking information, such as a tracking number through the centralized server. This is also discussed in more detail below.
  • the software of MIM 1 is installed onto a merchant's server platform, the software is programmed to integrate and configure with the merchant's storefront application (e.g. a Web store application for Internet-based implementatipns) in a conventional manner.
  • the merchant's storefront application e.g. a Web store application for Internet-based implementatipns
  • function calls may be installed and invoked within the aforementioned scripting language of the merchant's site.
  • the merchant Web store application will then map data to the parameters used within these function calls in a conventional manner through the use of MIM 1.
  • Those values contain the transaction information (such as product SKU's, shipping address, quantities ordered, desired shipping options, and the like, which are well known to those of skill in the art) that is accessible to the merchant, such as by being stored in database 7, a separate merchant database, or elsewhere.
  • Failure recovery components may also be included in MIM I , to ensure that transmissions and valuable transaction information are not lost. These may include, for example, merchant side logging of sales order submissions and merchant side queuing and re-submission of failed sales order. These may be accomplished in any number of conventional ways. For example, each inventory check, cost calculation request, and sales order submission may be logged within the merchant component by being written to a log file, such as a text file, database table, etc. This information may also be used for auditing and during problem resolution. Moreover, if MIM 1 cannot communicate with CE 2, then all submission requests may be placed within a queue folder that resides on the merchant's server, in a conventional manner. The orders may thereafter be re-submitted when the connection is reestablished.
  • the software of MIM 1 preferably submits the received order to database 7, through CE 2, and a tracking number is generated for the order. This preferably accomplished using an XML formatted message, the operation of which is well known to those of ordinary skill in the art.
  • the tracking number is then preferably passed to the merchant Web store application through MIM 1 by CE 2.
  • CE 2 accomplishes a quick, platform-independent, seamless, and scaleable integration of each merchant through a centralized operation. This is preferably achieved through processes that use a combination of established Internet standards and protocols (such as HTTP, XML, and SOAP) along with other customized components. These standards and protocols and custom-made distributed software objects that may be installed on both a centralized server (not shown) and on each of the merchant servers (such as by MIM 1).
  • the system of the present invention preferably uses CE 2 to provide several important functions to each merchant web-store. For example, before placing an order for a particular product, the system of the present invention can use CE 2 to tell each merchant (and therefore the merchant's customer) whether the item is currently in stock.
  • the high level logic for this function is preferably as follows: Receive Input parameters from Inventory Check function call; Map input parameters to Inventory Check XML layout; Log Request; Invoke Communication Engine 2; Receive response from Communication Engine 2; Log Response; Interpret Response; and Complete Output parameters for Inventory Check function call.
  • Landed cost analysis lets the merchant (and therefore customer) know how much shipping and handling costs will be for a particular order.
  • the high level logic for this function is preferably as follows: Receive Input parameters from Cost Calculation function call; Map input parameters to Cost Calculation XML layout; Log Request; Invoke Communication Engine 2; Receive response from Communication Engine 2; Log Response; Interpret Response; and Complete Output parameters for Cost Calculation function call.
  • Communication Engine 2 Receive response from Communication Engine 2; Log Response; Interpret Response; and Complete Output parameters for Cost Calculation function call.
  • CE 2 preferably comprises two modules: Merchant Communication Module (MCM) 12 and Front End Communication Module (FECM) 13.
  • MCM 12 is preferably an object that is installed on each merchant's server and is programmed to send requests (such as the aforementioned XML formatted messages) to MIM 1 or elsewhere, and to await a real-time response there from before allowing further processing of information back to the customer (e.g. through a web page).
  • FECM 13 is preferably installed on the aforementioned centralized server and is designed to await requests, process them internally, and send responses, as described in more detail below.
  • MCM 12 and FECM 13 preferably function independently and according to well- established communication protocols.
  • FECM 13 may operate as a one-fit-for-all interface for each merchant.
  • the main carrier for this communication is preferably Simple Object Access Protocol
  • SOAP SOAP
  • the envelope preferably contains XML, which is sent from MIM 1 to CE 2 (and from MCM 12 to FECM 13).
  • the merchant address on the envelope is read first since it contains the information about the process-handling object.
  • the envelope is then opened, contents retrieved and processed by an addressee handler, and finally the response is packaged back into the envelope.
  • the envelope is then returned to the original sender.
  • This innovative protocol may be used in variety of ways in the present invention. Since the address is built into the protocol and is used to name the component on the other (receiving) side of CE 2, the same engine may thus be used for all interactions between each merchant and the central system, providing an array of merchant services. Components that use SOAP are preferably installed on both ends of CE 2. On the merchant end, there are numerous possible scenarios regarding the use of available platforms. This has the significant advantage of enabling almost 100% coverage of the merchant market. Once MIM 1 converts merchant data into an XML format, CE 2 is invoked, which results in a secure and seamless submission and receipt of data using SOAP.
  • the latency in receiving a response in the system of the present invention is minor, generally shorter than a download of a standard web banner.
  • an error mechanism is in place, enabling the merchant component to handle down times (in case of sales order submission time-out, the system of the present invention queues the orders and submits them when the connection is established).
  • Figure 2 shows features available to the merchant as a result of the implementation of the system of the present invention.
  • Figure 3 is a flowchart that details the preferred flow of information and processes performed in CE 2.
  • Front-end 3 enables communication from the components of the system of the present invention residing on the centralized server to the components residing on the merchant's server.
  • the system of the present invention is able to receive information submissions and provide real time responses to and from the merchant, depending upon the type of the request.
  • Front-end 3 is preferably programmed to process merchant requests and produce XML based responses and may include, for example, the transmission of information through a Web server. This programming may be accomplished in any number of conventional ways, as with MIM 1 and CE 2.
  • the processes available to the merchant through front-end 3 preferably include a sales order submission interface, a shipping and handling cost calculat ⁇ , and an inventory checker.
  • the processes programmed into front-end 3 are not limited thereto, and may include the processing of any information about the items offered by the merchant
  • the sales order interface of front-end 3 receives an XML sales order submission request from MIM 1 through CE 2, assigns a tracking number to the order, passes the request to the business logic 6, and sends a response back to the merchant.
  • the response also contains information about success of the submission.
  • this interface preferably has the capability to validate data submitted by a merchant and produce a response based on the validation process. This has the significant advantage over the prior art that it enables a merchant to produce a real-time response to the customer with either a tracking number or an error message.
  • the shipping and handling cost calculator of front-end 3 enables a merchant to display real-time shipping and handling cost information on the merchant's web site during the shopping process.
  • the cost information is not an estimate, but the actual shipping and handling cost associated with shipping the selected products in the shopping basket to the selected address.
  • the shipping cost interface of front-end 3 receives the request from MIM 1 through the FECM 13 of CE 2 and processes it as if the order was complete.
  • the cost calculation is preferably done by business logic 6 based on the complex algorithm provided by the shipping vendor, and the price is returned to the merchant for display on the site.
  • the process is seamless and instantaneous to the customer, who only sees a display of the actual cost of shipment for the purchase.
  • the inventory checking interface of front-end 3 is similar to the cost calculator in design, but the processed information is different.
  • a merchant submits a request for available inventory in a given geography, and the inventory checking interface accesses database 7 through business logic 6 to obtain the necessary information on the item in a conventional manner.
  • the inventory checking interface then returns the number of available items. Having this information readily available in database 7 enables the merchant to present this number to the customer in real time.
  • Merchant Tools 4 is preferably a programmed component of the system of the present invention that is implemented through a conventional Web server operating on the centralized server and enables merchants to accomplish several updating and auditing functions on the items that they are offering for sale by using their browser. Theses function include, for example: Add / update product information; Initiate product stocking/re-stocking; View real-time and historical business reports; and Add / Update Product Information
  • the present invention requires only that a certain minimal amount of product information exist within database 7.
  • This product information includes SKU, Product Name, Description, Weight, and other characteristics. Some of this information is necessary to perform the aforementioned landed cost analysis. Therefore, a simple way to add and update product information is included within Merchant Tools 4.
  • a set of triggers and reminders are in place within Merchant Tools 4 for merchants to use.
  • a merchant can go into merchant tools 4 to set levels of inventory at which it will receive an automated reminder (such as through e-mail) to re-stock a particular product.
  • minimal level the first reminder is sent. If a product ever reaches the critical level (if it hasn't been restocked), a more urgent message is sent.
  • Merchant tools 4 also allows for these inventory notification levels to be set by the merchant.
  • any time that a merchant wishes to restock inventory he/she must first log onto the merchant tools web site in order to initiate a stock order notification. This is done through a re-stock web based wizard that guides the users through several steps. First the merchant must log in through multiple levels of security (e.g. database verification, IIS,
  • the merchant selects a vendor supplier warehouse from a global list; and selects products and the re-stock quantities. These are preferably displayed in a table format, to be selected for re-stocking, with each product requiring a field to specify a quantity for the re-stock. The merchant must then confirm the stock order.
  • the system After inserting the order into database 7 and submitting it to the warehouse vendor, the system will provide the merchant with a printable shipping label.
  • an automated stock order notification must be entered into the system at least 48 hours prior to receipt of the actual shipment at a warehouse location.
  • the merchant After submitting the stock order notification, the merchant needs to physically ship the products in question (or request such a shipment from a distributor or a factory).
  • This database driven web wizard provides merchants with a practical tool for complex inventory management tasks. It is intuitive, precise, and requires only a basic knowledge of Internet usage.
  • a merchant may also wish to view information (inventory levels, recent sales orders, past stock orders, etc.) pertaining to a particular product that is warehoused and shipped through the system of the present invention.
  • a list of canned reports is preferably made available to view information at a product level.
  • These product level reports preferably include: Completed Sales Orders for Individual Product; Current Inventory Position for Individual Product; In-Process Sales Orders for Individual Product; In-Process Stock Orders for Individual Product; Completed Stock Orders for Individual Product; Re-Stocked Returns for Individual Product; and Completed Sales Orders Per Customer Location for Individual Product.
  • These reports are prepared by merchant tools 4 in a conventional manner, such as through the use of the aforementioned scripting languages, Web server API's, and the like, which retrieve the necessary information from database 7, format it, and provide it to the merchant via the Web interface.
  • the following reports are also preferably available when a merchant wants to view summary or merchant level information (across all merchant products): Products for Merchant; Completed Sales Orders for Merchant; Current Inventory Position for Merchant; In- Process Sales Orders for Merchant; In-Process Stock Orders for Merchant; Completed Stock Orders for Merchant; Re-Stocked Returns for Merchant; Completed Sales Orders Per Customer Location for Merchant; Completed Sales Orders Per Shipment Method for Merchant; NS Average Shipment Time Per Sales Order for Merchant.
  • the system of the present invention preferably includes end- user tools 5, also preferably implemented via a Web site.
  • End-user tools 5 are provided to allow a merchant's customers to enter tracking numbers and otherwise track their orders. Users receive tracking numbers and are preferably directed to this Web site through order status e-mails sent by the merchant with or without the use of the system of the present invention.
  • the tools provided to the customers using end-user tools 5 may include, for example: Status Tracking and Returns Processing.
  • a utility is preferably programmed into end-user tools 5 that allows for a customer to enter his/her tracking number and receive current status ofa particular order across multiple markets. Customers may be directed to this Web site, for example, through order status ⁇ mails generated by the system of the present invention or by the merchant independently. Tracking numbers are preferably communicated to the end-user through status e-mails as well as through the merchant's Web site (e.g. tracking numbers are returned to the merchant in real-time once a sales order has been submitted to the system of the present invention).
  • a customer accesses the Web site for end-user tools 5. This will provide the customer with instructions for processing a return and a printable, pre-filled waybill, which should preferably be included with the return. This provides information to the warehousing vendor necessary for restocking of undamaged items.
  • the URL needed to access the Returns Processing utility is preferably provided on the packing list included with the original outbound shipment
  • Business logic 6 is a programmed component of the system of the present invention that ensures that each piece of data that enters the system is routed through the correct processing or logic, resulting in the completion of the desired function.
  • Some of the major processes that the system of the present invention supports are: Inventory Check; Shipping and Handling Cost Calculation; Sales Order Fulfillment Processing; Stock Order Fulfillment Processing; and Inventory Reconciliation.
  • the inventory check function is initiated within MIM 1 and is preferably invoked by a merchant (through CE 2) prior to submission ofa sales order.
  • the next step is to perform the logic necessary to obtain current inventory levels.
  • Business logic 6 uses the defined criteria, such as the product SKU and warehouse location, to retrieve this information from database 7. This information is then sent back to the merchant in a real-time fashion through CE 2, as previously discussed.
  • the shipping and handling cost calculation is also initiated within MIM 1 and preferably invoked by a merchant prior to submission ofa sales order.
  • the next step is to perform the logic necessary to perform a landed cost analysis.
  • Business logic 6 uses the defined criteria, including number of products, weight of products, and destination to access reference tables and perform the necessary cost calculations. The result is then sent back to the merchant in a real-time fashion through CE 2, as previously discussed.
  • Sales order fulfillment processing is triggered when a sales order file is transmitted from the merchant to the system of the present invention.
  • the sales order component of business logic 6 is preferably used to archive, validate, check inventory levels, perform cost calculations, and store data within database 7.
  • Business logic 6 may also read sales order information from database 7 and format it into an outbound transmission file that the fulfillment vendor
  • Sales order fulfillment processing is also triggered when return files are received from logistics and / or fulfillment providers. These return files contain information on sales orders that are currently in process.
  • Stock order fulfillment processing is triggered when a merchant uses merchant tools 4 to submit a stock order.
  • the stock order information is preferably written to database 7 by a stock order ASP Web page or the like, but is certainly not limited thereto.
  • Business logic 6 preferably reads database 7 looking for all newly created stock orders and format into an outbound transmission file that the fulfillment vendor (warehousing or shipping) will recognize.
  • Stock order fulfillment processing is also triggered when return files are received from logistics and / or fulfillment providers. These return files contain information on stock orders that are currently in process.
  • Inventory reconciliation processing is triggered by the receipt of an inventory file from each warehouse location.
  • the inventory file contains the current inventory position for each product contained within the warehouse.
  • Business logic 6 preferably checks to make sure that the inventory position in the warehouse inventory file matches the inventory position maintained in database 7. Any discrepancies (within a reasonable threshold) are preferably reported on a daily reconciliation report.
  • the Backorder processing function creates alternate shipping and delivery scenarios depending on a set of variables controlled by both the merchant and the levels of inventory for a given product. Initially, a merchant determines which major backorder rule to put in place choosing from one of the following: No backorders, immediate fulfillment and assign shipment. In the "no backorder" scenario, all orders placed will be rejected when inventory levels are not sufficient enough to complete the order. In the immediate fulfillment scenario, items in stock at the time the order is placed will be fulfilled immediately. All other items will be phced in a backorder status and will be completed on a "rolling fulfillment" basis as inventory becomes available to fill the order.
  • the "assign shipment” scenario can help save a merchant reduce shipping costs by assigning all (or some) items in a shipment to a particular shipment. All items in this shipment will be held in the warehouse until inventory is available to ship all items placed in the original sales order corresponding to that shipment.
  • Database 7 typically comprises any one of a number of conventional database applications, such as Oracle, Sybase, or SQL Server.
  • the database typically contains inventory levels, shipping, and handling cost information, and other information related to the items offer for sale by the merchant. The details of such information are well known to those of ordinary skill in the art and will not be elaborated upon here.
  • Database 7 is preferably, but not necessarily, subdivided based upon the following types of data: Processing (Sales Order, Stock Order);
  • Inventory Inventory; Reporting; History / Archive; and Backup. It will be appreciated by those of skill in the art that this can be accomplished using a variety of well-known database schema and optimization techniques and will also not be further elaborated upon here.
  • Backend 9 assists with outbound and inbound communication between the system of the present invention and the warehouse and/or shipping vendors.
  • Backend 9 controls fie handling and transmitting of files between the system of the present invention and warehouse and/or shipping vendors. As previously described, this is preferably accomplished using XML formatted messages.
  • business logic 6 For outgoing files, business logic 6 assembles item level database records from database 7 for transmission to the vendor. These database records are converted to XML and combined in a single XML 'batch' file by the File Assembler Component. Of course, the File Assembler Component may also assemble the XML file based on tracking number.
  • the batch file is archived and then saved into the specific outgoing repository folder for that file type, and the File Transmitting Component preferably sends the batch file to the vendor via FTP.
  • the Logging Component writes the archive and transfer events for auditing.
  • the File Transmitting Component monitors the remote FTP folders on the vendor's system for new batch files to retrieve. When found, it transfers it via FTP to the PushLoop incoming repository folder for that specific file type. It then calls the Logging Component, which archives the file into an archive folder. The File Assembler Component then breaks the file into each item record and passes the records to the corresponding business logic process for that record's type (e.g. Stock Receipt, Inventory, Sales Order Status, etc.).
  • the Logging Component which archives the file into an archive folder.
  • the File Assembler Component then breaks the file into each item record and passes the records to the corresponding business logic process for that record's type (e.g. Stock Receipt, Inventory, Sales Order Status, etc.).
  • Operational audit 10 is a programmed component of the system of the present invention that may be used to make sure that all the other product components function accurately and efficiently.
  • An event log preferably tracks the steps or events that occur while processing a sale, stock, or other order. The event logs may be audited on a periodic basis to ensure completeness and accuracy of processing. Log files are created for each component of the system, including the MIM 1 and CE 2.
  • Event logging is preferably performed at the following system processing steps: Transfer of Sales Orders from Merchant to Front-End 3; Transfer of Sales Orders from Front-End 3 to Database 7; Transfer of Sales Orders from Database 7 and Backend 9 to Warehouse and Shipping Vendor; Sales Order Status Progression; Stock Order Status Progression; Backorder Status Progression; Inventory Reconciliation; and Vendor Error File Resolution.
  • the following daily audit reports may preferably be generated and checked using a combination automated/manual process similar to those described above: Merchant to Front-End 3 Failed Audit Report; Front-End 3 to Database 7 Failed Audit Report; Database 7 and Backend 9 to Warehouse Failed Audit Report; Aging Sales Orders Report (e.g. greater than 3 days old); Warehouse Sales Order Error Report; Warehouse Stock Order Error Report; Aging Backorder Report; and Overdue Stock Receipts (e.g. greater than 4 days overdue).
  • an archive is preferably taken to ensure that re-start recovery can be initiated.
  • XML Translation Solution 1 1 is a programmed component of the system of the present invention that allows for the integration of the system of the present invention with a variety of proprietary computing architectures using XML. Since XML is a relatively new technology, it has been discovered that many merchant and vendor systems do not have the tools in place and knowledge in house to process XML files. The resources and knowledge that are required to make such systems conform to XML standards can be difficult, lengthy, and expensive to develop in the systems of the prior art.
  • XML Translation Solution 1 1 of the present invention allows it to easily snap into the existing legacy systems of merchants and vendors, and enables it to communicate using XML. This is accomplished in the present invention by using a series of translator programs that translate the various legacy data formats of vendors and merchants into an XML format understandable by the system of the present invention (and vice versa). Translations programs are well known to those of ordinary skill in the art and will not be further elaborated upon here.

Abstract

The present invention is directed to a real-time logistics and fulfillment system for orders placed on-line that incorporates a real-time closed-loop communication engine (2) to each of a plurality of merchants (1), having an auto-archive and resubmission capabilities (7), which provides guaranteed message delivery and response over a communication network. The present invention incorporates a process handler (9) programmed to receive logistical and fulfillment information (8) on an item offered by a merchant (3) from a vendor in real-time upon submission of an order for the item by a customer, and to return the logistical and fulfillment information to the merchant in real-time.

Description

SYSTEM FOR THE PROVISION OF GOODS AND SERVICES OVER A DISTRIBUTED COMMUNICATION NETWORK
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention generally relates to interactive computer systems, such as interactive Web sites on the Internet and to the provision of goods or services over a distributed communication network, such as the Internet. In particular, the invention relates to a process and a system for providing real-time logistics and fulfillment services for orders placed online.
Brief Description of the Prior Art
Computer networks, such as the Internet, intranets, and virtual private networks ("VPN's"), have become increasingly popular for conducting all types of transactions remotely, such as the purchase of products and services or the tracking and coordination of inventory and logistical information. The Internet is a particularly popular medium for these transactions due to the convenience that the purchaser is able to access an unlimited amount of information and can purchase all types of products and services from a single location over an easily accessible public network.
Due to the tremendous growth in these merchant services, on-line merchants are looking for an efficient solution for outsourcing management of back-end logistics and fulfillment processes and functions. These include physical services such as warehousing, pick 'n pack, distribution, end-user order tracking and returns as well as real-time information services such as process flow optimization, inventory analysis, landed cost analysis, lowest cost routing and multiple supply partner management and integration. Consequently, merchants can significantly benefit from an improved internetworked solution for outsourcing the management of back-end logistics and fulfillment processes and functions.
SUMMARY OF THE INVENTION
The present invention is directed to a real-time complete logistics and fulfillment system for orders placed on-line that incorporates a real-time closed-loop communication engine to each merchant, having an auto-archive and resubmission capabilities, which provides guaranteed message delivery and response over the Internet and/or other communication media (such as WAP, 1-Mode, etc.). The preferred embodiment of the communication engine of the present invention utilizes two modules, a merchant communication module for communicating with a merchant's network servers, and processing communication module for communicating with the merchant communication module and a process handling system.
The merchant communication module is preferably an object that is installed on a merchant's server, which is programmed to send requests to a front-end communication module, and to await a real-time response before allowing further processing of the request. The front- end communication module is preferably installed on an independent, centralized server from the merchant server and the vendor server, although not limited thereto. The front-end communication module is preferably programmed to await requests from the merchant communication module, process them internally, and then send the appropriate response.
Real-time logistics and fulfillment may be accomplished in the present invention among many different merchant and vendor systems by utilizing a platform built on open technology, such as extensible Markup Language ("XML"), which incorporates pre-configured, integrated components for major commerce servers, easy integration with existing solution vendors, such as customer resource management ("CRM") and payment service providers, and secure access to reporting tools. The present invention may also incorporate a managed service provision network that draws warehousing, delivery and fulfillment services from multiple vendor suppliers and offers them as a single, integrated supplier. A suite of business modeling and analysis tools streamlines operations and improves customer service. This preferably includes real time landed cost analysis, real time inventory checks, stock level triggers and global stock level balancing; and allows for the complete tracking of orders from submission to the merchant through delivery to the customer.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a diagram of a preferred embodiment of the programmed components of the system of the present invention.
Figure 2 is a diagram overview of the features of the present invention.
Figure 3 is a flow chart of the process steps of the system of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of preferred embodiments of the invention; which, however, should not be taken to limit the invention to a specific embodiment but are for explanation and understanding only. The terms "computer", "computer system", or "server" as used herein should be broadly construed to include any device capable of receiving, transmitting and/or using information including, without limitation, a processor, microprocessor or similar device, a personal computer, such as a laptop, palm PC, desktop or workstation, a network server, a mainframe, an electronic wired or wireless device, such as for example, a telephone, an interactive television, such as for example, a television adapted to be connected to the Internet or an electronic device adapted for use with a television, a cellular telephone, a personal digital assistant, an electronic pager, and a digital watch. Further, a computer, computer system, or system of the hvention may operate in communication with other systems over a communication network, such as, for example, the Internet, an intranet, or an extranet, or may operate as a stand-alone system.
The information to be transmitted in the present invention, as described below, may be in the form of e-mail, Web pages, text files, or any other conventional electronic format capable of conveying information over a communication network. The operation of these media in transmitting information are well known to those of ordinary skill in the art, and will not be further elaborated upon here.
Figure 1 is a diagram of the general components of the preferred embodiment of the present invention configured to provide a real-time logistics and fulfillment solution among a customer, a merchant, and a supply vendor. Of course, it will be appreciated that, alternatively, a vendor supplier and a merchant may be one in the same. In addition, while the preferred embodiment of the present invention as described below incorporates the use of a separate merchant, vendor, and central server, any number of servers or a single server may be used to operate any and all aspects of the claimed invention.
As shown in Figure 1 , these components include Merchant Installation Module 1, Communication Engine 2, Front-End 3, Merchant Tools 4, End-User Tools 5, Business Logic 6, Database 7, Knowledge Management 8, Backend 9, Operational Audits 10, and XML Translation Solution 1 1. The operation and interoperation of each of these preferred components in achieving the functionality of the present invention are described in more detail below.
Merchant installation module (MIM) 1 is preferably a software package that is installed onto a merchant's server (which is typically a Web server in embodiments of the invention operated over the Internet). IM 1 is programmed in a conventional manner to enable merchants to automate the real-time submission of data to Communication Engine (CE) 2 with a built-in response system. The programming of MIM 1, and all of the components of the system of the present invention, may be accomplished using any one of a number of conventional programming languages/systems, such as Visual Basic, JAVA, ASP, PERL, and the like, operating on any one of a number of conventional platforms, such as UNIX or Windows NT. MIM 1 is also programmed to secure real-time access to database 7 (described in more detail below). If a third party supply vendor is used, MIM 1 is also programmed to enable merchants to submit sales orders to the vendor for the fulfillment and real-time receipt of tracking information, such as a tracking number through the centralized server. This is also discussed in more detail below.
Once the software of MIM 1 is installed onto a merchant's server platform, the software is programmed to integrate and configure with the merchant's storefront application (e.g. a Web store application for Internet-based implementatipns) in a conventional manner. For example, to perform an inventory check, cost calculation, or sales order submission, function calls may be installed and invoked within the aforementioned scripting language of the merchant's site.
The merchant Web store application will then map data to the parameters used within these function calls in a conventional manner through the use of MIM 1. Those values contain the transaction information (such as product SKU's, shipping address, quantities ordered, desired shipping options, and the like, which are well known to those of skill in the art) that is accessible to the merchant, such as by being stored in database 7, a separate merchant database, or elsewhere.
Failure recovery components may also be included in MIM I , to ensure that transmissions and valuable transaction information are not lost. These may include, for example, merchant side logging of sales order submissions and merchant side queuing and re-submission of failed sales order. These may be accomplished in any number of conventional ways. For example, each inventory check, cost calculation request, and sales order submission may be logged within the merchant component by being written to a log file, such as a text file, database table, etc. This information may also be used for auditing and during problem resolution. Moreover, if MIM 1 cannot communicate with CE 2, then all submission requests may be placed within a queue folder that resides on the merchant's server, in a conventional manner. The orders may thereafter be re-submitted when the connection is reestablished.
The software of MIM 1 preferably submits the received order to database 7, through CE 2, and a tracking number is generated for the order. This preferably accomplished using an XML formatted message, the operation of which is well known to those of ordinary skill in the art. The tracking number is then preferably passed to the merchant Web store application through MIM 1 by CE 2.
In the preferred embodiment of the present invention CE 2 accomplishes a quick, platform-independent, seamless, and scaleable integration of each merchant through a centralized operation. This is preferably achieved through processes that use a combination of established Internet standards and protocols (such as HTTP, XML, and SOAP) along with other customized components. These standards and protocols and custom-made distributed software objects that may be installed on both a centralized server (not shown) and on each of the merchant servers (such as by MIM 1).
The system of the present invention preferably uses CE 2 to provide several important functions to each merchant web-store. For example, before placing an order for a particular product, the system of the present invention can use CE 2 to tell each merchant (and therefore the merchant's customer) whether the item is currently in stock. The high level logic for this function is preferably as follows: Receive Input parameters from Inventory Check function call; Map input parameters to Inventory Check XML layout; Log Request; Invoke Communication Engine 2; Receive response from Communication Engine 2; Log Response; Interpret Response; and Complete Output parameters for Inventory Check function call.
Another function is cost analysis. Landed cost analysis lets the merchant (and therefore customer) know how much shipping and handling costs will be for a particular order. The high level logic for this function is preferably as follows: Receive Input parameters from Cost Calculation function call; Map input parameters to Cost Calculation XML layout; Log Request; Invoke Communication Engine 2; Receive response from Communication Engine 2; Log Response; Interpret Response; and Complete Output parameters for Cost Calculation function call.
Yet another important function involves sales order submissions. Once all order information has been gathered and submitted in a conventional manner (e.g. through "Buy Button" on an order processing Web page on the merchant's Web site), it is then submitted by the system to a logistics and fulfillment vendor. A tracking number is assigned to the order and returned to the merchant (and therefore to the customer) in real-time fashion. The high level logic for this function is preferably: Receive Input parameters from Cost Calculation function call; Map input parameters to Cost Calculation XML layout; Log Request; Invoke
Communication Engine 2; Receive response from Communication Engine 2; Log Response; Interpret Response; and Complete Output parameters for Cost Calculation function call.
In the operation of these functions in the preferred embodiment of the invention, CE 2 preferably comprises two modules: Merchant Communication Module (MCM) 12 and Front End Communication Module (FECM) 13. MCM 12 is preferably an object that is installed on each merchant's server and is programmed to send requests (such as the aforementioned XML formatted messages) to MIM 1 or elsewhere, and to await a real-time response there from before allowing further processing of information back to the customer (e.g. through a web page). FECM 13 is preferably installed on the aforementioned centralized server and is designed to await requests, process them internally, and send responses, as described in more detail below. MCM 12 and FECM 13 preferably function independently and according to well- established communication protocols. This provides the significant advantage over the system of the prior art that there is no need for any systems integration or merchant design dependencies within CE 2. Thus, FECM 13 may operate as a one-fit-for-all interface for each merchant. The main carrier for this communication is preferably Simple Object Access Protocol
(SOAP). As is well known to those of ordinary skill in the art, SOAP allows for the transfer of closed "envelopes", regardless of the objects stored in those envelopes. In this case, the envelope preferably contains XML, which is sent from MIM 1 to CE 2 (and from MCM 12 to FECM 13). Within CE 2, the merchant address on the envelope is read first since it contains the information about the process-handling object. The envelope is then opened, contents retrieved and processed by an addressee handler, and finally the response is packaged back into the envelope. The envelope is then returned to the original sender.
This innovative protocol may be used in variety of ways in the present invention. Since the address is built into the protocol and is used to name the component on the other (receiving) side of CE 2, the same engine may thus be used for all interactions between each merchant and the central system, providing an array of merchant services. Components that use SOAP are preferably installed on both ends of CE 2. On the merchant end, there are numerous possible scenarios regarding the use of available platforms. This has the significant advantage of enabling almost 100% coverage of the merchant market. Once MIM 1 converts merchant data into an XML format, CE 2 is invoked, which results in a secure and seamless submission and receipt of data using SOAP. As a result of transmitting information in this manner, the latency in receiving a response in the system of the present invention is minor, generally shorter than a download of a standard web banner. Moreover, as with MIM 1 , in case of network problems, an error mechanism is in place, enabling the merchant component to handle down times (in case of sales order submission time-out, the system of the present invention queues the orders and submits them when the connection is established).
The operation of the features of the system of the present invention is illustrated in Figure 2, which shows features available to the merchant as a result of the implementation of the system of the present invention. Figure 3 is a flowchart that details the preferred flow of information and processes performed in CE 2.
Front-end 3 enables communication from the components of the system of the present invention residing on the centralized server to the components residing on the merchant's server. Using front-end 3, the system of the present invention is able to receive information submissions and provide real time responses to and from the merchant, depending upon the type of the request. Front-end 3 is preferably programmed to process merchant requests and produce XML based responses and may include, for example, the transmission of information through a Web server. This programming may be accomplished in any number of conventional ways, as with MIM 1 and CE 2. The processes available to the merchant through front-end 3 preferably include a sales order submission interface, a shipping and handling cost calculatσ, and an inventory checker. Of course, it will be appreciated to those of ordinary skill in the art that the processes programmed into front-end 3 are not limited thereto, and may include the processing of any information about the items offered by the merchant
In the preferred embodiment, the sales order interface of front-end 3 receives an XML sales order submission request from MIM 1 through CE 2, assigns a tracking number to the order, passes the request to the business logic 6, and sends a response back to the merchant. The response also contains information about success of the submission. While processing a request for a sales order submission, this interface preferably has the capability to validate data submitted by a merchant and produce a response based on the validation process. This has the significant advantage over the prior art that it enables a merchant to produce a real-time response to the customer with either a tracking number or an error message.
The shipping and handling cost calculator of front-end 3 enables a merchant to display real-time shipping and handling cost information on the merchant's web site during the shopping process. The cost information is not an estimate, but the actual shipping and handling cost associated with shipping the selected products in the shopping basket to the selected address. The shipping cost interface of front-end 3 receives the request from MIM 1 through the FECM 13 of CE 2 and processes it as if the order was complete. The cost calculation is preferably done by business logic 6 based on the complex algorithm provided by the shipping vendor, and the price is returned to the merchant for display on the site. The process is seamless and instantaneous to the customer, who only sees a display of the actual cost of shipment for the purchase.
The inventory checking interface of front-end 3 is similar to the cost calculator in design, but the processed information is different. In this case, a merchant submits a request for available inventory in a given geography, and the inventory checking interface accesses database 7 through business logic 6 to obtain the necessary information on the item in a conventional manner. The inventory checking interface then returns the number of available items. Having this information readily available in database 7 enables the merchant to present this number to the customer in real time.
Merchant Tools 4 is preferably a programmed component of the system of the present invention that is implemented through a conventional Web server operating on the centralized server and enables merchants to accomplish several updating and auditing functions on the items that they are offering for sale by using their browser. Theses function include, for example: Add / update product information; Initiate product stocking/re-stocking; View real-time and historical business reports; and Add / Update Product Information
In order to process sales orders, the present invention requires only that a certain minimal amount of product information exist within database 7. This product information includes SKU, Product Name, Description, Weight, and other characteristics. Some of this information is necessary to perform the aforementioned landed cost analysis. Therefore, a simple way to add and update product information is included within Merchant Tools 4.
In order to manage inventories globally, a set of triggers and reminders are in place within Merchant Tools 4 for merchants to use. For example, a merchant can go into merchant tools 4 to set levels of inventory at which it will receive an automated reminder (such as through e-mail) to re-stock a particular product. There are preferably two inventory levels that trigger reminders for restocking of a product: minimal level and critical level. When a product inventory reaches a minimal level, the first reminder is sent. If a product ever reaches the critical level (if it hasn't been restocked), a more urgent message is sent. Merchant tools 4 also allows for these inventory notification levels to be set by the merchant.
Preferably, any time that a merchant wishes to restock inventory, he/she must first log onto the merchant tools web site in order to initiate a stock order notification. This is done through a re-stock web based wizard that guides the users through several steps. First the merchant must log in through multiple levels of security (e.g. database verification, IIS,
Windows NT, NTFS, and network IP pool requester validation). Next the merchant selects a vendor supplier warehouse from a global list; and selects products and the re-stock quantities. These are preferably displayed in a table format, to be selected for re-stocking, with each product requiring a field to specify a quantity for the re-stock. The merchant must then confirm the stock order.
After inserting the order into database 7 and submitting it to the warehouse vendor, the system will provide the merchant with a printable shipping label. Preferably an automated stock order notification must be entered into the system at least 48 hours prior to receipt of the actual shipment at a warehouse location. After submitting the stock order notification, the merchant needs to physically ship the products in question (or request such a shipment from a distributor or a factory). This database driven web wizard provides merchants with a practical tool for complex inventory management tasks. It is intuitive, precise, and requires only a basic knowledge of Internet usage.
A merchant may also wish to view information (inventory levels, recent sales orders, past stock orders, etc.) pertaining to a particular product that is warehoused and shipped through the system of the present invention. To accommodate this need, a list of canned reports is preferably made available to view information at a product level. These product level reports preferably include: Completed Sales Orders for Individual Product; Current Inventory Position for Individual Product; In-Process Sales Orders for Individual Product; In-Process Stock Orders for Individual Product; Completed Stock Orders for Individual Product; Re-Stocked Returns for Individual Product; and Completed Sales Orders Per Customer Location for Individual Product. These reports are prepared by merchant tools 4 in a conventional manner, such as through the use of the aforementioned scripting languages, Web server API's, and the like, which retrieve the necessary information from database 7, format it, and provide it to the merchant via the Web interface.
In addition, the following reports are also preferably available when a merchant wants to view summary or merchant level information (across all merchant products): Products for Merchant; Completed Sales Orders for Merchant; Current Inventory Position for Merchant; In- Process Sales Orders for Merchant; In-Process Stock Orders for Merchant; Completed Stock Orders for Merchant; Re-Stocked Returns for Merchant; Completed Sales Orders Per Customer Location for Merchant; Completed Sales Orders Per Shipment Method for Merchant; NS Average Shipment Time Per Sales Order for Merchant.
Similarly to merchant tools 4, the system of the present invention preferably includes end- user tools 5, also preferably implemented via a Web site. End-user tools 5 are provided to allow a merchant's customers to enter tracking numbers and otherwise track their orders. Users receive tracking numbers and are preferably directed to this Web site through order status e-mails sent by the merchant with or without the use of the system of the present invention. The tools provided to the customers using end-user tools 5 may include, for example: Status Tracking and Returns Processing. A utility is preferably programmed into end-user tools 5 that allows for a customer to enter his/her tracking number and receive current status ofa particular order across multiple markets. Customers may be directed to this Web site, for example, through order status ©mails generated by the system of the present invention or by the merchant independently. Tracking numbers are preferably communicated to the end-user through status e-mails as well as through the merchant's Web site (e.g. tracking numbers are returned to the merchant in real-time once a sales order has been submitted to the system of the present invention).
In order to process a return, a customer accesses the Web site for end-user tools 5. This will provide the customer with instructions for processing a return and a printable, pre-filled waybill, which should preferably be included with the return. This provides information to the warehousing vendor necessary for restocking of undamaged items. The URL needed to access the Returns Processing utility is preferably provided on the packing list included with the original outbound shipment
Business logic 6 is a programmed component of the system of the present invention that ensures that each piece of data that enters the system is routed through the correct processing or logic, resulting in the completion of the desired function. Some of the major processes that the system of the present invention supports are: Inventory Check; Shipping and Handling Cost Calculation; Sales Order Fulfillment Processing; Stock Order Fulfillment Processing; and Inventory Reconciliation.
The inventory check function is initiated within MIM 1 and is preferably invoked by a merchant (through CE 2) prior to submission ofa sales order. Once passed through CE 2 to front-end 3, the next step is to perform the logic necessary to obtain current inventory levels. Business logic 6 uses the defined criteria, such as the product SKU and warehouse location, to retrieve this information from database 7. This information is then sent back to the merchant in a real-time fashion through CE 2, as previously discussed. The shipping and handling cost calculation is also initiated within MIM 1 and preferably invoked by a merchant prior to submission ofa sales order. Once passed through CE 2 to front end 3, the next step is to perform the logic necessary to perform a landed cost analysis. Business logic 6 uses the defined criteria, including number of products, weight of products, and destination to access reference tables and perform the necessary cost calculations. The result is then sent back to the merchant in a real-time fashion through CE 2, as previously discussed.
Sales order fulfillment processing is triggered when a sales order file is transmitted from the merchant to the system of the present invention. The sales order component of business logic 6 is preferably used to archive, validate, check inventory levels, perform cost calculations, and store data within database 7. Business logic 6 may also read sales order information from database 7 and format it into an outbound transmission file that the fulfillment vendor
(warehousing or shipping) will recognize. Sales order fulfillment processing is also triggered when return files are received from logistics and / or fulfillment providers. These return files contain information on sales orders that are currently in process.
Stock order fulfillment processing is triggered when a merchant uses merchant tools 4 to submit a stock order. The stock order information is preferably written to database 7 by a stock order ASP Web page or the like, but is certainly not limited thereto. Business logic 6 preferably reads database 7 looking for all newly created stock orders and format into an outbound transmission file that the fulfillment vendor (warehousing or shipping) will recognize. Stock order fulfillment processing is also triggered when return files are received from logistics and / or fulfillment providers. These return files contain information on stock orders that are currently in process.
Inventory reconciliation processing is triggered by the receipt of an inventory file from each warehouse location. The inventory file contains the current inventory position for each product contained within the warehouse. Business logic 6 preferably checks to make sure that the inventory position in the warehouse inventory file matches the inventory position maintained in database 7. Any discrepancies (within a reasonable threshold) are preferably reported on a daily reconciliation report.
The Backorder processing function creates alternate shipping and delivery scenarios depending on a set of variables controlled by both the merchant and the levels of inventory for a given product. Initially, a merchant determines which major backorder rule to put in place choosing from one of the following: No backorders, immediate fulfillment and assign shipment. In the "no backorder" scenario, all orders placed will be rejected when inventory levels are not sufficient enough to complete the order. In the immediate fulfillment scenario, items in stock at the time the order is placed will be fulfilled immediately. All other items will be phced in a backorder status and will be completed on a "rolling fulfillment" basis as inventory becomes available to fill the order. Finally, the "assign shipment" scenario can help save a merchant reduce shipping costs by assigning all (or some) items in a shipment to a particular shipment. All items in this shipment will be held in the warehouse until inventory is available to ship all items placed in the original sales order corresponding to that shipment.
Other business functions supported by business logic 6 may include Returns Processing and Real-Time Customer Notification. The processing of these functions is accomplished in essentially the same manner as the aforementioned functions, in which the necessary information is retrieved from database 7, the merchant, and the vendor supplier. Database 7 typically comprises any one ofa number of conventional database applications, such as Oracle, Sybase, or SQL Server. The database typically contains inventory levels, shipping, and handling cost information, and other information related to the items offer for sale by the merchant. The details of such information are well known to those of ordinary skill in the art and will not be elaborated upon here. Database 7 is preferably, but not necessarily, subdivided based upon the following types of data: Processing (Sales Order, Stock Order);
Inventory; Reporting; History / Archive; and Backup. It will be appreciated by those of skill in the art that this can be accomplished using a variety of well-known database schema and optimization techniques and will also not be further elaborated upon here.
Backend 9 assists with outbound and inbound communication between the system of the present invention and the warehouse and/or shipping vendors. Backend 9 controls fie handling and transmitting of files between the system of the present invention and warehouse and/or shipping vendors. As previously described, this is preferably accomplished using XML formatted messages. There are preferably three main areas programmed within the back-end module: XML File Assembler Component; XML File Logging Component; and XML File Transmitting Component.
For outgoing files, business logic 6 assembles item level database records from database 7 for transmission to the vendor. These database records are converted to XML and combined in a single XML 'batch' file by the File Assembler Component. Of course, the File Assembler Component may also assemble the XML file based on tracking number. The batch file is archived and then saved into the specific outgoing repository folder for that file type, and the File Transmitting Component preferably sends the batch file to the vendor via FTP. The Logging Component writes the archive and transfer events for auditing.
For incoming files, the above process occurs in reverse. The vendor may rely on the system of the present invention to perform all file transfers and deposits. Thus, the File Transmitting Component monitors the remote FTP folders on the vendor's system for new batch files to retrieve. When found, it transfers it via FTP to the PushLoop incoming repository folder for that specific file type. It then calls the Logging Component, which archives the file into an archive folder. The File Assembler Component then breaks the file into each item record and passes the records to the corresponding business logic process for that record's type (e.g. Stock Receipt, Inventory, Sales Order Status, etc.).
Operational audit 10 is a programmed component of the system of the present invention that may be used to make sure that all the other product components function accurately and efficiently. An event log preferably tracks the steps or events that occur while processing a sale, stock, or other order. The event logs may be audited on a periodic basis to ensure completeness and accuracy of processing. Log files are created for each component of the system, including the MIM 1 and CE 2.
Event logging is preferably performed at the following system processing steps: Transfer of Sales Orders from Merchant to Front-End 3; Transfer of Sales Orders from Front-End 3 to Database 7; Transfer of Sales Orders from Database 7 and Backend 9 to Warehouse and Shipping Vendor; Sales Order Status Progression; Stock Order Status Progression; Backorder Status Progression; Inventory Reconciliation; and Vendor Error File Resolution.
The following daily audit reports may preferably be generated and checked using a combination automated/manual process similar to those described above: Merchant to Front-End 3 Failed Audit Report; Front-End 3 to Database 7 Failed Audit Report; Database 7 and Backend 9 to Warehouse Failed Audit Report; Aging Sales Orders Report (e.g. greater than 3 days old); Warehouse Sales Order Error Report; Warehouse Stock Order Error Report; Aging Backorder Report; and Overdue Stock Receipts (e.g. greater than 4 days overdue). At each of these critical processing steps an archive is preferably taken to ensure that re-start recovery can be initiated. XML Translation Solution 1 1 is a programmed component of the system of the present invention that allows for the integration of the system of the present invention with a variety of proprietary computing architectures using XML. Since XML is a relatively new technology, it has been discovered that many merchant and vendor systems do not have the tools in place and knowledge in house to process XML files. The resources and knowledge that are required to make such systems conform to XML standards can be difficult, lengthy, and expensive to develop in the systems of the prior art.
Accordingly a solution has been developed in the present invention. Rather than require a merchant or vendor to change their system architecture to handle incoming and outgoing XML files, XML Translation Solution 1 1 of the present invention allows it to easily snap into the existing legacy systems of merchants and vendors, and enables it to communicate using XML. This is accomplished in the present invention by using a series of translator programs that translate the various legacy data formats of vendors and merchants into an XML format understandable by the system of the present invention (and vice versa). Translations programs are well known to those of ordinary skill in the art and will not be further elaborated upon here. Although this invention has been described with reference to particular embodiments, it will be appreciated that many variations may be resorted to without departing from the spirit and scope of this invention as set forth in the appended claims.

Claims

CLAIMSWe claim:
1. A communication system for providing real-time fulfillment information on an order placed by a customer over a communication network with at least one ofa plurality of merchants through a merchant server operated by said merchant for at leastone item supplied by at least a plurality of vendors, said communication system comprising: a process handler programmed to receive fulfillment information on said item from said vendor in at least one ofa plurality of data formats and to transmit at least a portion of said fulfillment information to said merchant in real-time.
2. The system of Claim 1, wherein said process handler is programmed to perform, in real-time, one or more functions selected from the group consisting of inventory checking of said item in said order, landed cost analysis of said order, order fulfillment, generating tracking information for said order; transmitting said tracking number to said customer; re-stocking fulfillment processing; inventory reconciliation; and backorder processing.
3. The system of Claim 1, further comprising at least one merchant communication module for each of said merchant servers, wherein each of said merchant communication modules is programmed to communicate with one of said merchant servers; and at least one processing communication module, said processing communication module being programmed to communicate with each of said merchant communication modules and said process handler.
4. The system of Claim 1, further comprising a merchant installation module programmed to operate on said at least one of said merchant servers, said merchant installation module being programmed to integrate with said merchant server one or more functions selected from the group consisting of real-time submission of said order to said vendor through said process handler, real-time receipt of tracking information for said order from said process handler, inventory checking through said process handler, landed cost analysis through said process handler, and failure recovery if communication with said process handler is lost.
5. The system of Claim 3, wherein said failure recovery comprises one or more functions selected from the group consisting of logging of said order on said merchant server, and queuing and resubmission of said order to said process handler.
6. The system of Claim 1, wherein said communication among said merchant, said vendor, and said process handler incorporates XML.
7. The system of Claim 1, wherein said communication among said merchant, said vendor, and said process handler incorporates SOAP.
8. The system of Claim 1, wherein said process handler further comprises a front- end interface, database, and back-end interface.
9. The system of Claim 8, wherein said back-end interface comprises an XML file assembler, an XML file logging component, and an XML file transmitting component.
10. The system of Claim 8, wherein said database is subdivided based upon one or more types of data selected from the group consisting of Processing of Sales Orders and Stock Orders; Inventory; Reporting; History and Archive; and Backup.
1 1. The system of Claim t, wherein said process handler is further programmed to provide one or more merchant tool functions selected from the group consisting of updating said item information, management of stock for said item, viewing real-time and historical reports.
12. The system of Claim 1 1 , wherein said merchant tool functions further include transmitting a reminder to said merchant when inventory stock for said item reactes a predetermined level.
13. The system of Claim 11, wherein said reports include one or more selected from the group consisting of Completed Sales Orders for Individual Product; Current Inventory
Position for Individual Product; In-Process Sales Orders for Individual Product; In-Process Stock Orders for Individual Product; Completed Stock Orders for Individual Product; Re-Stocked Returns for Individual Product; Completed Sales Orders Per Customer Location for Individual Product; Products for Merchant; Completed Sales Orders for Merchant; Current Inventory Position for Merchant; In-Process Sales Orders for Merchant; In^rocess Stock Orders for
Merchant; Completed Stock Orders for Merchant; Re-Stocked Returns for Merchant; Completed Sales Orders Per Customer Location for Merchant; Completed Sales Orders Per Shipment Method for Merchant; and Average Shipment Time Per Sales Order for Merchant
14. The system of Claim 1, wherein said process handler is further programmed to provide one or more customer tool functions selected from the group consisting of status tracking and returns processing.
15. The system of Claim 1, wherein said process handler further is further programmed to provide one or more operational audit functions selected from the group consisting of Transfer of Sales Orders from Merchant to Front-End; Transfer of Sales Orders from Front-End to Database; Transfer of Sales Orders from Database and Backend to Vendor; Sales Order Status Progression; Stock Order Status Progression; Backorder Status Progression; Inventory Reconciliation; Vendor Error File Resolution; Merchant to Front-End Failed Audit
Report; Front-End to Database Failed Audit Report; Database and Backend to Warehouse Failed Audit Report; Aging Sales Orders Report; Warehouse Sales Order Error Report; Warehouse Stock Order Error Report; Aging Backorder Report; and Overdue Stock Receipt
16. The system of Claim 1, further comprising a data translator programmed to receive information from said vendor and/or said merchant in plurality of data formats and to translate said data formats to XML.
17. A communication system for providing real-time fulfillment information on an order placed by a customer over a communication network with at least one ofa plurality of merchants through a merchant server operated by said merchant for at least one item supplied by at least one of a plurality of vendors, said communications system comprising; a process handler programmed to receive fulfillment information on said item from said vendor in at least one ofa plurality of data formats; at least one merchant communication module for each of said merchant servers, said merchant communication module being programmed to communicate with said merchant server; and at least one processing communication module, said processing communication module being programmed to receive said fulfillment information from said process handler and to transmit said fulfillment information to said merchant communication module in real-time.
18. The system of Claim 17, wherein said process handler is programmed to perform, in real-time, one or more functions selected from the group consisting of inventory checking of said item in said order, landed cost analysis of said order, order fulfillment, generating tracking information for said order; transmitting said tracking number to said customer; re-stocking fulfillment processing; inventory reconciliation; and backorder processing.
19. The system of Claim 17, further comprising a merchant installation module programmed to operate on said at least one of said merchant servers, said merchant installation module being programmed to integrate with said merchant server one or more functions selected from the group consisting of real-time submission of said order to said vendor through sad process handler, real-time receipt of tracking information for said order from said process handler, inventory checking through said process handler, landed cost analysis through said process handler, and failure recovery if communication with said process handler is lost.
20. The system of Claim 19, wherein said failure recovery comprises one or more functions selected from the group consisting of logging of said order on said merchant server, and queuing and resubmission of said order to said process handler.
21. The system of Claim 17, wherein said communication among said merchant, said vendor, and said process handler incorporates XML.
22. The system of Claim 17, wherein said communication among said merchant, said vendor, and said process handler incorporates SOAP.
23. The system of Claim 17, wherein said process handler further comprises a front- end interface, database, and back-end interface.
24. The system of Claim 23, wherein said back-end interface comprises an XML file assembler, an XML file logging component, and an XML file transmitting component.
25. The system of Claim 23, wherein said database is subdivided based upon one or more types of data selected from the group consisting of Processing of Sales Orders and Stock Orders; Inventory; Reporting; History and Archive; and Backup.
26. The system of Claim 17, wherein said process handler is further programmed to provide one or more merchant tool functions selected from the group consisting of updating said item information, management of stock for said item, viewing real-time and historical reports.
27. The system of Claim 26, wherein said merchant tool functions further include transmitting a reminder to said merchant when inventory stock for said item reaches a predetermined level.
28. The system of Claim 26, wherein said reports include one or more selected from the group consisting of Completed Sales Orders for Individual Product; Current Inventory Position for Individual Product; In-Process Sales Orders for Individual Product; In-Process Stock Orders for Individual Product; Completed Stock Orders for Individual Product; Re-Stocked Returns for Individual Product; Completed Sales Orders Per Customer Location for Individual Product; Products for Merchant; Completed Sales Orders for Merchant; Current Inventory Position for Merchant; In-Process Sales Orders for Merchant; In-Process Stock Orders for Merchant; Completed Stock Orders for Merchant; Re-Stocked Returns for Merchant; Completed Sales Orders Per Customer Location for Merchant; Completed Sales Orders Per Shipment Method for Merchant; and Average Shipment Time Per Sales Order for Merchant
29. The system of Claim 17, wherein said process handler is further programmed to provide one or more customer tool functions selected from the group consisting of status tracking and returns processing.
30. The system of Claim 17, wherein said process handler further is further programmed to provide one or more operational audit functions selected from the group consisting of Transfer of Sales Orders from Merchant to Front-End; Transfer of Sales Orders from Front-End to Database; Transfer of Sales Orders from Database and Backend to Vendor; Sales Order Status Progression; Stock Order Status Progression; Backorder Status Progression; Inventory Reconciliation; Vendor Error File Resolution; Merchant to Front-End Failed Audit
Report; Front-End to Database Failed Audit Report; Database and Backend to Warehouse Failed Audit Report; Aging Sales Orders Report; Warehouse Sales Order Error Report; Warehouse Stock Order Error Report; Aging Backorder Report; and Overdue Stock Receipt.
31. A method for providing real-time fulfillment information on an order placed by a customer over a communication network with at least one of a plurality of merchants through a merchant server operated by said merchant for at least one item supplied by at least one of a plurality of vendors, said method comprising the steps of: receiving said order from said merchant in real-time; receiving fulfillment information on said item from at least one said vendors in at least one ofa plurality of data formats; and transmitting at least a portion of said fulfillment information to said merchant in realtime.
32. The method of Claim 31, further comprising the step of performing, in real-time, one or more functions of the group consisting of inventory checking of said item in said order, landed cost analysis of said order, order fulfillment, generating tracking information for said order; transmitting said tracking number to said customer; re-stocking fulfillment processing; inventory reconciliation; and backorder processing.
33. The method of Claim 31, further comprising the step of performing one or more functions selected from the group consisting of real-time submission of said order to said vendor through said process handler, real-time receipt of tracking information for said order from said process handler, inventory checking through said process handler, landed cost analysis through said process handler, and failure recovery if communication is lost.
34. The method of Claim 33, wherein said failure recovery comprises one or more functions selected from the group consisting of logging of said order on said merchant server, and cueing and resubmission of said order.
35. The method of Claim 31, wherein said transmission of said fulfillment information to said merchant is encrypted.
36. The method of Claim 31 , wherein said transmission of said fulfillment information to said merchant is platform independent.
37. The method of Claim 31 , wherein said fulfillment information received from said vendor is translated to an XML data format.
38. The method of Claim 31 , wherein said transmission of said fulfillment information to said merchant is accomplished using XML.
39. The method of Claim 31, wherein said transmission of said information to said merchant is accomplished using SOAP.
PCT/US2001/049774 2000-12-26 2001-12-21 System for the provision of goods and services over a distributed communication network WO2002052378A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2002231205A AU2002231205A1 (en) 2000-12-26 2001-12-21 System for the provision of goods and services over a distributed communication network
US10/451,767 US20040111286A1 (en) 2001-12-21 2001-12-21 System for the provision of goods and services over a distributed communication network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US25809000P 2000-12-26 2000-12-26
US60/258,090 2000-12-26

Publications (2)

Publication Number Publication Date
WO2002052378A2 true WO2002052378A2 (en) 2002-07-04
WO2002052378A3 WO2002052378A3 (en) 2003-01-16

Family

ID=22979060

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/049774 WO2002052378A2 (en) 2000-12-26 2001-12-21 System for the provision of goods and services over a distributed communication network

Country Status (2)

Country Link
AU (1) AU2002231205A1 (en)
WO (1) WO2002052378A2 (en)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7184973B2 (en) 2000-07-11 2007-02-27 United Parcel Service Of America, Inc. Method and apparatus for communicating order entries in a network environment
US7266513B2 (en) 2001-03-14 2007-09-04 United Parcel Service Of America, Inc. System and method for initiating returns over a network
US7444290B2 (en) 2001-03-30 2008-10-28 United Parcel Service Of America, Inc. Electronic shipping system for package pickup and anywhere to anywhere delivery
US7444298B2 (en) 2001-08-28 2008-10-28 United Parcel Service Of America, Inc. Order and payment visibility process
US7574447B2 (en) 2003-04-08 2009-08-11 United Parcel Service Of America, Inc. Inbound package tracking systems and methods
US7657466B2 (en) 2005-06-21 2010-02-02 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US7698175B2 (en) 2001-10-05 2010-04-13 United Parcel Service Of America, Inc. Inbound and outbound shipment notification methods and systems
US7742928B2 (en) 2003-05-09 2010-06-22 United Parcel Service Of America, Inc. System for resolving distressed shipments
US7761348B2 (en) 2003-12-30 2010-07-20 United Parcel Service Of America, Inc. Systems and methods for consolidated global shipping
US7765131B2 (en) 2006-06-20 2010-07-27 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US9798999B2 (en) 2013-03-12 2017-10-24 United Parcel Service Of America, Inc. Systems and methods for ranking potential attended delivery/pickup locations
US9916557B1 (en) 2012-12-07 2018-03-13 United Parcel Service Of America, Inc. Systems and methods for item delivery and pick-up using social networks
US10002340B2 (en) 2013-11-20 2018-06-19 United Parcel Service Of America, Inc. Concepts for electronic door hangers
US10210474B2 (en) 2013-10-14 2019-02-19 United Parcel Service Of America, Inc. Systems and methods for confirming an identity of an individual, for example, at a locker bank
US10354216B2 (en) 2013-08-30 2019-07-16 United Parcel Service Of America, Inc. Systems, methods, and computer program products for providing customized communication content in conjunction with transport of a plurality of packages
US10387824B2 (en) 2012-12-21 2019-08-20 United Parcel Service Of America, Inc. Systems and methods for delivery of an item
US10410164B2 (en) 2014-11-14 2019-09-10 United Parcel Service Of America, Inc Systems and methods for facilitating shipping of parcels
US10410165B2 (en) 2014-11-14 2019-09-10 United Parcel Service Of America, Inc. Systems and methods for facilitating shipping of parcels for returning items
CN110275900A (en) * 2019-06-25 2019-09-24 浪潮软件股份有限公司 A method of order and early warning are monitored based on Redis caching technology
US10445682B2 (en) 2013-02-01 2019-10-15 United Parcel Service Of America, Inc. Systems and methods for parcel delivery to alternate delivery locations
US10600022B2 (en) 2016-08-31 2020-03-24 United Parcel Service Of America, Inc. Systems and methods for synchronizing delivery of related parcels via a computerized locker bank
CN111080381A (en) * 2018-10-18 2020-04-28 重庆浪舟科技开发有限公司 Wine industry e-commerce management system
US10664787B2 (en) 2013-10-09 2020-05-26 United Parcel Service Of America, Inc. Customer controlled management of shipments
CN111292135A (en) * 2020-02-25 2020-06-16 上海东普信息科技有限公司 Distribution method, device, equipment, system and storage medium
US10733563B2 (en) 2014-03-13 2020-08-04 United Parcel Service Of America, Inc. Determining alternative delivery destinations
US11144872B2 (en) 2012-12-21 2021-10-12 United Parcel Service Of America, Inc. Delivery to an unattended location
US11182730B2 (en) 2014-02-16 2021-11-23 United Parcel Service Of America, Inc. Determining a delivery location and time based on the schedule or location of a consignee

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5710887A (en) * 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
US20010016828A1 (en) * 1998-03-09 2001-08-23 Junglee Corporation Method and system for integrating transaction mechanisms over multiple internet sites
US6341270B1 (en) * 1998-11-10 2002-01-22 Aether Systems, Inc. Method for providing vendor notification marketing in an electronic commerce network environment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5710887A (en) * 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
US20010016828A1 (en) * 1998-03-09 2001-08-23 Junglee Corporation Method and system for integrating transaction mechanisms over multiple internet sites
US6341270B1 (en) * 1998-11-10 2002-01-22 Aether Systems, Inc. Method for providing vendor notification marketing in an electronic commerce network environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
'HighJump software and ironside team to broaden access to real-time fulfillment information for B2B order management' PR NEWSWIRE 23 January 2001, XP002953795 *
'HK systems, Inc. announces customer commitments to its e-Commerce fulfillment solution series' BUSINESS WIRE 31 August 1999, XP002953796 *

Cited By (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7184973B2 (en) 2000-07-11 2007-02-27 United Parcel Service Of America, Inc. Method and apparatus for communicating order entries in a network environment
US7266513B2 (en) 2001-03-14 2007-09-04 United Parcel Service Of America, Inc. System and method for initiating returns over a network
US7430527B2 (en) 2001-03-14 2008-09-30 United Parcel Service Of America, Inc. System and method for initiating returns over a network
US11580489B2 (en) 2001-03-14 2023-02-14 United Parcel Service Of America, Inc. Systems and methods for initiating returns over a network
US9824325B2 (en) 2001-03-14 2017-11-21 United Parcel Service Of America, Inc. Systems and methods for initiating returns over a network
US8417574B2 (en) 2001-03-14 2013-04-09 United Parcel Service Of America, Inc. System and method for initiating returns over a network
US7444290B2 (en) 2001-03-30 2008-10-28 United Parcel Service Of America, Inc. Electronic shipping system for package pickup and anywhere to anywhere delivery
US7937296B2 (en) 2001-08-28 2011-05-03 United Parcel Service Of America, Inc. Order and payment visibility process
US7444298B2 (en) 2001-08-28 2008-10-28 United Parcel Service Of America, Inc. Order and payment visibility process
US7698175B2 (en) 2001-10-05 2010-04-13 United Parcel Service Of America, Inc. Inbound and outbound shipment notification methods and systems
US7574447B2 (en) 2003-04-08 2009-08-11 United Parcel Service Of America, Inc. Inbound package tracking systems and methods
US7742928B2 (en) 2003-05-09 2010-06-22 United Parcel Service Of America, Inc. System for resolving distressed shipments
US8249998B2 (en) 2003-05-09 2012-08-21 United Parcel Service Of America, Inc. System for resolving distressed shipments
US8744977B2 (en) 2003-12-30 2014-06-03 United Parcel Service Of America, Inc. Systems and methods for virtual inventory management
US7853536B2 (en) 2003-12-30 2010-12-14 United Parcel Service Of America, Inc. Systems and methods for virtual inventory management
US7895092B2 (en) 2003-12-30 2011-02-22 United Parcel Service Of America, Inc. Systems and methods for integrated global shipping and visibility
US7761348B2 (en) 2003-12-30 2010-07-20 United Parcel Service Of America, Inc. Systems and methods for consolidated global shipping
US10134002B2 (en) 2005-06-21 2018-11-20 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US8108259B2 (en) 2005-06-21 2012-01-31 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US7657466B2 (en) 2005-06-21 2010-02-02 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US10817826B2 (en) 2005-06-21 2020-10-27 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US10089596B2 (en) 2005-06-21 2018-10-02 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US10078810B2 (en) 2005-06-21 2018-09-18 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US10074067B2 (en) 2005-06-21 2018-09-11 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US7765131B2 (en) 2006-06-20 2010-07-27 United Parcel Service Of America, Inc. Systems and methods for providing personalized delivery services
US9916557B1 (en) 2012-12-07 2018-03-13 United Parcel Service Of America, Inc. Systems and methods for item delivery and pick-up using social networks
US11144872B2 (en) 2012-12-21 2021-10-12 United Parcel Service Of America, Inc. Delivery to an unattended location
US10387824B2 (en) 2012-12-21 2019-08-20 United Parcel Service Of America, Inc. Systems and methods for delivery of an item
US11900310B2 (en) 2012-12-21 2024-02-13 United Parcel Service Of America, Inc. Delivery to an unattended location
US10614410B2 (en) 2012-12-21 2020-04-07 United Parcel Service Of America, Inc. Delivery of an item to a vehicle
US11748694B2 (en) 2012-12-21 2023-09-05 United Parcel Service Of America, Inc. Systems and methods for delivery of an item
US10445682B2 (en) 2013-02-01 2019-10-15 United Parcel Service Of America, Inc. Systems and methods for parcel delivery to alternate delivery locations
US10402775B2 (en) 2013-03-12 2019-09-03 United Parcel Services Of America, Inc. Systems and methods of re-routing parcels intended for delivery to attended delivery/pickup locations
US9798999B2 (en) 2013-03-12 2017-10-24 United Parcel Service Of America, Inc. Systems and methods for ranking potential attended delivery/pickup locations
US9811798B2 (en) 2013-03-12 2017-11-07 United Parcel Service Of America, Inc. Systems and methods of locating and selling items at attended delivery/pickup locations
US11620611B2 (en) 2013-03-12 2023-04-04 United Parcel Service Of America, Inc. Systems and methods of locating and selling items at attended delivery/pickup locations
US10929806B2 (en) 2013-03-12 2021-02-23 United Parcel Service Of America, Inc. Systems and methods of managing item pickup at attended delivery/pickup locations
US10521761B2 (en) 2013-03-12 2019-12-31 United Parcel Service Of America, Inc. Systems and methods of delivering parcels using attended delivery/pickup locations
US10558942B2 (en) 2013-03-12 2020-02-11 United Parcel Service Of America, Inc. Systems and methods for returning one or more items via an attended delivery/pickup location
US10002341B2 (en) 2013-03-12 2018-06-19 United Parcel Service Of America, Inc. Systems and methods for returning one or more items via an attended delivery/pickup location
US10909497B2 (en) 2013-03-12 2021-02-02 United Parcel Service Of America, Inc. Systems and methods of reserving space attended delivery/pickup locations
US10783488B2 (en) 2013-03-12 2020-09-22 United Parcel Service Of America, Inc. Systems and methods of locating and selling items at attended delivery/pickup locations
US11386385B2 (en) 2013-08-30 2022-07-12 United Parcel Service Of America, Inc. Systems, methods, and computer program products for providing customized communication content in conjunction with transport of a plurality of packages
US10354216B2 (en) 2013-08-30 2019-07-16 United Parcel Service Of America, Inc. Systems, methods, and computer program products for providing customized communication content in conjunction with transport of a plurality of packages
US10664787B2 (en) 2013-10-09 2020-05-26 United Parcel Service Of America, Inc. Customer controlled management of shipments
US10217079B2 (en) 2013-10-14 2019-02-26 United Parcel Service Of America, Inc. Systems and methods for confirming an identity of an individual, for example, at a locker bank
US11562318B2 (en) 2013-10-14 2023-01-24 United Parcel Service Of America, Inc. Systems and methods for conveying a parcel to a consignee, for example, after an unsuccessful delivery attempt
US11182733B2 (en) 2013-10-14 2021-11-23 United Parcel Service Of America, Inc. Systems and methods for confirming an identity of an individual, for example, at a locker bank
US10210474B2 (en) 2013-10-14 2019-02-19 United Parcel Service Of America, Inc. Systems and methods for confirming an identity of an individual, for example, at a locker bank
US11526830B2 (en) 2013-11-20 2022-12-13 United Parcel Service Of America, Inc. Concepts for electronic door hangers
US10192190B2 (en) 2013-11-20 2019-01-29 United Parcel Service Of America, Inc. Concepts for electronic door hangers
US10002340B2 (en) 2013-11-20 2018-06-19 United Parcel Service Of America, Inc. Concepts for electronic door hangers
US11182730B2 (en) 2014-02-16 2021-11-23 United Parcel Service Of America, Inc. Determining a delivery location and time based on the schedule or location of a consignee
US10733563B2 (en) 2014-03-13 2020-08-04 United Parcel Service Of America, Inc. Determining alternative delivery destinations
US11769108B2 (en) 2014-03-13 2023-09-26 United Parcel Service Of America, Inc. Determining alternative delivery destinations
US10410165B2 (en) 2014-11-14 2019-09-10 United Parcel Service Of America, Inc. Systems and methods for facilitating shipping of parcels for returning items
US10410164B2 (en) 2014-11-14 2019-09-10 United Parcel Service Of America, Inc Systems and methods for facilitating shipping of parcels
US10600022B2 (en) 2016-08-31 2020-03-24 United Parcel Service Of America, Inc. Systems and methods for synchronizing delivery of related parcels via a computerized locker bank
US11587020B2 (en) 2016-08-31 2023-02-21 United Parcel Service Of America, Inc. Systems and methods for synchronizing delivery of related parcels via computerized locker bank
CN111080381A (en) * 2018-10-18 2020-04-28 重庆浪舟科技开发有限公司 Wine industry e-commerce management system
CN110275900A (en) * 2019-06-25 2019-09-24 浪潮软件股份有限公司 A method of order and early warning are monitored based on Redis caching technology
CN110275900B (en) * 2019-06-25 2023-04-18 浪潮软件股份有限公司 Order monitoring and early warning method based on Redis cache technology
CN111292135B (en) * 2020-02-25 2023-08-04 上海韵达高新技术有限公司 Distribution method, distribution device, distribution equipment, distribution system and storage medium
CN111292135A (en) * 2020-02-25 2020-06-16 上海东普信息科技有限公司 Distribution method, device, equipment, system and storage medium

Also Published As

Publication number Publication date
WO2002052378A3 (en) 2003-01-16
AU2002231205A1 (en) 2002-07-08

Similar Documents

Publication Publication Date Title
US20040111286A1 (en) System for the provision of goods and services over a distributed communication network
WO2002052378A2 (en) System for the provision of goods and services over a distributed communication network
US10586271B2 (en) System and method for multi-source transaction processing
US6901380B1 (en) Merchandising system method, and program product utilizing an intermittent network connection
US6055516A (en) Electronic sourcing system
US20050125251A1 (en) System and method for enterprise resource management
JP4959817B2 (en) Method in client system for ordering item and method in server system for accepting item order
US8150736B2 (en) Global electronic commerce system
US7464092B2 (en) Method, system and program for customer service and support management
US6981222B2 (en) End-to-end transaction processing and statusing system and method
JP3968243B2 (en) Return method and return system for generating and sending electronic shipping return labels
US20060041329A1 (en) Inventory group purchasing systems and methods
US20030212602A1 (en) Order and inventory management system
US20020147732A1 (en) Method, system, and program for customer service and support management
US20030074279A1 (en) Document exchange framework for automated extensible markup language data in an e-procurement system and method
US20040220845A1 (en) System and method of automated package tracking
JP2004503027A (en) Method and apparatus for transmitting order in network environment
US20040128204A1 (en) Systems for procuring products in a distributed system
NZ528068A (en) Network based business to business portal for the retail convenience marketplace
CA2402350A1 (en) Inventory control system and methods
US7370007B2 (en) Catalog search agent
WO2001077936A2 (en) Electronic system and method for end to end operation and management of industry supply chain
EP1309924A2 (en) System and method for client-server communications and enterprise resource management
AU2002233050B2 (en) Network based business to business portal for the retail convenience marketplace
WO2003017163A1 (en) System for facilitating transactions between freight customers and service providers

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 10451767

Country of ref document: US

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A DATED 10.11.2003)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP