WO2001055931A1 - System and method for providing comprehensive logistics services - Google Patents

System and method for providing comprehensive logistics services Download PDF

Info

Publication number
WO2001055931A1
WO2001055931A1 PCT/US2001/002479 US0102479W WO0155931A1 WO 2001055931 A1 WO2001055931 A1 WO 2001055931A1 US 0102479 W US0102479 W US 0102479W WO 0155931 A1 WO0155931 A1 WO 0155931A1
Authority
WO
WIPO (PCT)
Prior art keywords
shipment
data
tracking
server
providing
Prior art date
Application number
PCT/US2001/002479
Other languages
French (fr)
Inventor
Robert G. Van Zandt
Marshall F. Trotter
Thomas E. Catlin
Haili Wang Kowalski
Desh D. Srivastva
Mark A. Cummuta
Julie M. Mullen
David S. Stukel
Douglas H. Malick
Original Assignee
Trafficop, 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 Trafficop, Inc. filed Critical Trafficop, Inc.
Priority to AU2001231144A priority Critical patent/AU2001231144A1/en
Publication of WO2001055931A1 publication Critical patent/WO2001055931A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management

Definitions

  • the electronic quote request packet is sent to and received by a security application resident on the comprehensive logistics service provider's server 60, which verifies the data and sender, and forwards authorized data to appropriate applications.
  • the quoting engine 62 parses out the data contained in the electronic quote request data stream and saves it into memory for use in shipment cost calculations. While any electronic data transmission technology can be used, these examples use XML packets and parsers that transmit and parse out data to the quoting engine 62.
  • the quoting engine 62 determines the first component of the landed cost quote, pre-shipment costs.
  • Packing costs are relatively common pre- shipment costs and will be discussed for illustrative purposes for this example. Packing costs are calculated if the buyer 42 requests packing services, and/or the seller, insuring agent, shipping provider, and/or government regulations require packaging. A shipment packing cost depends on a number of variables including, among others, the volume and weight of the item to be shipped, the sensitivity of the item being shipped and any special handling requirements for such items (e.g., toxic waste). Note that if packaging is required and/or requested, all shipment calculations requiring the shipment's dimensions - size, volume, weight - always include the additional dimensions of the packaging.
  • the quoting engine 62 can use actual data values for each of these key elements to determine which vendors to use, or the quoting engine 62 can use codified tables for each of these elements. The process demonstrated here describes how codified tables could be used.
  • the quoting engine 62 calculates the actual weight of the shipment at step 124.
  • the quoting engine 62 next calculates a shipment volume-weight factor based on dividing the volume of a shipment item by a standard conversion factor (166 cubic inches/lb for international shipments, and 192 cubic inches/lb for domestic-only shipments within the United States).
  • the quoting engine 62 compares the actual weight of the shipment to the calculated volume-weight factor of the shipment to determine the shipment's chargeable weight. The greater of the shipment's actual weight versus the shipment's volume-weight factor is the shipment's chargeable weight. In the example request illustrated in Fig. 3, the calculated volume- weight factor is the chargeable weight because the volume- weight factor 1301 lbs. ((60in x 60in x 60in)/166 in 3 /lb) is greater than the shipment's actual weight of 20 lbs.
  • the origin region codes are stored in a pre-set look up table and are linked to possible shipment origin countries and postal codes.
  • the quoting engine 62 searches the pre-set look up table to find an origin code that corresponds to the shipment origin country and postal code sent by the electronic data request.
  • the quoting engine 62 uses the shipment destination and postal code sent by the electronic data request to find a destination region code stored in a pre-set destination region code look up table.
  • These electronic data requests can be made via any electronic data transmission technology, although XML is the sample technology described herein. Referring to Fig.6, the origin region code and the destination region code for the illustrated example are "1" and "24" respectively.
  • the chart illustrates that in some cases the same vendor may be able to handle the entire shipment, such as vendor set 100, or that in other cases, a number of different vendors work together to complete a shipment, such as vendor sets 105 and 108.
  • the vendor set table 264, and the vendor set numbers and codes contained therein, are created by the comprehensive logistics service provider 20.
  • the quoting engine 62 next determines the shipment rates for each selected vendor set at step 142.
  • the quoting engine 62 first determines if the rates for each vendor of the selected vendor sets are on file locally in a master vendor rate data table 80 (Fig. 1) and that they are current. If they are on file locally and current, the quoting engine 62 retrieves this rate information and, as indicated in step 148 and described below, performs calculations using this vendor rate information to determine each vendor set's rate for the shipment requested.
  • XML schemas go further by defining how to describe the structure of XML documents (Structures"), and providing improved management of dates, numbers, and other special data (“Datatypes").
  • the data streams sent back to the server 60 are parsed, and the parsed out data is saved to the appropriate fields in the master vendor rate data tables 80.
  • the quoting engine 62 performs the rate calculations for each vendor set to determine the shipment rate for each vendor set for the requested shipment. Referring again to Fig. 8, the quoting engine 62 has to determine the rates and costs for three main legs of the shipment.
  • the shipper/origin of the shipment is located in zone A for vendor set 100.
  • the rate to transport a shipment from zone A to the ORD gateway for vendor set 100 is fifty dollars ($50), as chart 310 on Fig. 8 indicates.
  • the next step 152 is to determine the rate for the second leg of the shipment for the selected vendor set.
  • the second leg of the shipment is from the origin gateway 302 to the destination gateway 306. Since this portion of the shipment is not dependent on the origin or destination location, this rate is pulled directly from the vendor set's rates on file in the - 3 master vendor rate data tables 80.
  • the gateway-to-gateway, rate is indicated on chart 312 of Fig. 8 as one thousand dollars ($1000).
  • the next step 154 is to determine the rate for the third leg 308 of the shipment (from the AKL to destination). This rate determination is similar to the rate determination for the first leg 300 of the shipment.
  • the zone for the destination location is determined (e.g., zone C) and the rate for that zone is retrieved.
  • the shipment destination is in zone C in relation to Auckland Airport (AKL).
  • the rate for vendor set 100 for transporting a shipment from AKL to zone C is one hundred dollars ($100) as indicated in chart 310 of Fig. 8. With all the rates for the legs of the shipment determined, the quoting engine 62, at step 156 (Fig.
  • the quoting engine 62 adds all of these rates together along with any additional costs, such as pickup/delivery costs, agent handling fees, special service fees (e.g., 2-3 day service), to determine the door-to-door freight charge for that particular vendor set.
  • the quoting engine 62 then calculates the door-to-door freight charge for each vendor set that the quoting engine 62 selected. Once all of the door-to-door freight charges are calculated for each vendor set, the quoting engine 62, at step 158 (Fig. 2E), selects the vendor set with the lowest cost. Similar processing can have the vendor sets evaluated for fastest delivery time, guaranteed delivery date and other factors against all vendor sets or against a subset of preferred vendors/vendor sets.
  • API calls to communicate to another system, but any data request and retrieval technology can be used with the invention described herein.
  • the API call opens up a communication line with each insurance provider's database 90 and retrieves the necessary information.
  • the retrieved information similar to the information retrieved from the vendors' rate databases, is sent back to the comprehensive logistics service provider's server 60, in this example via an XML data stream format, and is parsed with the current insurance information stored to the appropriate fields on the master insurance rate data table 86.
  • the quoting engine 62 uses various shipment information, such as its origin and destination, the HTS code, the product size and weight, the product's value, to search each insurance vendor's look up table information stored on the master insurance rate data tables 86 to determine the lowest cost insurance premium for the requested shipment quote.
  • the quoting engine 62 determines all the duties and taxes that may be due on the shipment.
  • the quoting engine 62 uses various shipment information, such as its origin and destination, the product size and weight, the product's value, the HTS code, the product size and weight and the product's value to search the duty and tax look up tables resident on the master duty and tax rate data tables 92 to determine the duties and taxes for the ⁇ requested shipment.
  • the quoting engine 62 adds all of the determined and calculated components of the quote together to come up with a final quote to return to the requesting buyer 42. Specifically, the quoting engine 62 adds together the pre-shipment charges (e.g., packing costs), if any; the calculated door-to-door freight charge; the determined insurance premium and the calculated, duties and taxes.
  • the quoting engine 62 sends the final determined quote in an electronic data stream to the site host server 30 that requested the quote. A status message is also sent which states that a shipment quote was successfully generated.
  • the buyer 42 Once the buyer 42 has received the product price quote, which includes the shipment quote, he can either do nothing or accept the quote by purchasing the product. If the buyer 42 purchases the product, this activates the process to book the shipment of the product as indicated in step 400 (Fig. 9A).
  • the web site 34 activates a booking interface 93 from the site host server 30.
  • the booking interface 93 retrieves as much of the information it needs to book the shipment from the local data tables stored on the host site 22.
  • the booking interface 93 generates a web page 36 for the buyer's review with the retrieved information inserted in the appropriate fields.
  • the buyer 42 verifies the retrieved information, correcting it where necessary, and approves it. Figs.
  • the booking web page is very similar to a quote request web page, except that the booking web page requests more detailed information on the seller and the buyer.
  • the additional information is needed because when a shipment is booked, the booking engine 64 also registers the seller and the buyer (e.g. , to verify that they are not on a domestic and/or international denied parties lists), as discussed in detail below.
  • the customer ID 500 is usually a required field and is used as an identifier between the web site merchant and the comprehensive logistics service provider 20.
  • the next thirteen fields 502-524 contain detailed information about the seller.
  • the next field 550 contains a description of the item being shipped.
  • the next field 554 is for the HTS code. When booking a shipment, this field must be completed. The buyer 42 can enter the HTS code directly if he remembers it or, as with the quote request web page, he can use the HTS Classifier by clicking on the HTS classifier icon 556. Once in the HTS classifier, the process of using it to determine the HTS code is the same as described above for a quote request.
  • the next field is the piece type field 557. In the piece type field 557, the configuration of the item to be shipped is designated (e.g., package, pallet, container, loose). The piece type field 557 preferably uses a pull down menu.
  • the next field is the service type field 559.
  • the delivery manner is specified (e.g., air-parcel standard; ocean-parcel standard; 2-3 day service, via air; ocean container).
  • the service type field 559 preferably uses a pull down menu as well.
  • the next seven fields 558-569 contain information specific to the item being shipped and are the same entries required when requesting a quote.
  • the booking engine 64 Before booking the shipment, the booking engine 64, at step 412, runs a registration subroutine.
  • the registration subroutine functions exactly like the registration engine 68.
  • the registration subroutine and the registration engine 68 perform the necessary function of checking whether the parties to the transaction are on the U.S. State Department's denied party list, as indicated at step 414. Parties listed on the denied party list are not allowed to ship items in or out of the U.S.
  • the registration subroutine and the registration engine 68 use the detailed information submitted about the parties to the shipment (the seller and the buyer information) to determine if a party to a shipment is a denied party by comparing the submitted seller and buyer information to data stored on a denied party data table 95 maintained and updated by the comprehensive logistics service provider 20.
  • the comprehensive logistics service provider 20 monitors and tracks all the shipments that are booked in its system.
  • the vendors 26 responsible for the shipment provide cunent and updated shipment status information to the master shipment data tables 94 on a periodic basis.
  • the vendor 26 can provide the status information to the comprehensive logistics service provider 20 in any manner feasible.
  • the vendor 26 can provide it manually or preferably via an information network, for example through a web page via a browser or by sending an electronic data sfream such as EDI or XML directly from the vendor's shipment data tables 99 to the server 60 for parsing and storage on the master shipment data tables 94.
  • the container tracking system 710 of the embodiment through a central tracking station 712, has the flexibility and capability to automatically track containers and their shipments worldwide, regardless of country, industry, carrier, owner or mode of transportation. It is flexible enough to allow for manual data collection using the same technology if any automated means become unavailable for reasons such as, but not limited to, maintenance, damage, or interference.
  • the system of the present invention can automatically track containers and their shipments inter- and/or intra-modally, inter- and/or infra-industry and inter- and/or infra-carrier.
  • the central tracking station 712 includes a container tracking server 714 which serves as the information hub and data storage device for all of the containers 722 in the system.
  • the container tracking server 714 can be a single unit, or set or sets of coordinated servers and/or mainframe computers (not depicted).
  • a communications link 742 is established between the container tracking server 714 and numerous station servers 716.
  • the communications link 742 between the container fracking server 714 and the station servers 716 may be established in any manner suitable for that purpose, including the Internet, direct land lines, satellite, telecommunications or any other securable transmission and receiving method.
  • the Internet because of its interconnectivity and established worldwide infrastructure of multi-hosted, multi-located web servers is the preferred communications method.
  • each station server 716 is located at a container tracking site 718.
  • the container tracking sites 718 may be any site or sites where the operator of the container fracking system 710 wants to collect data on a system container 722. These sites usually include, at a minimum, any place where a container changes possession among carriers, vendors, industries, or modes at areas such as airports, shipping ports, rail yards, truck docking areas and staging areas.
  • Each station server 716 communicates with a single or numerous automated and/or manual tracking device readers 720.
  • the tracking device readers 720 collect the information encoded on each container fracking device 740 when the tracking device 740 is read.
  • the information collected on each container 722 by the readers 720 is communicated to each respective station server 716 which communicate all of the collected information to the main container tracking server 714 via the communication links 742.
  • the client's server and the container tracking server 714 receive information simultaneously from the station servers except that the container tracking server 714 only receives information the operator of the container tracking system has designated as critical for its fracking purposes.
  • the information collected and stored on the central container tracking server 714 is made available to each client of the system.
  • Each client can access the information on the container tracking server 714 at any time to find the location and status of one of their tracked containers.
  • An interested client may access the container fracking server 714 by an extranet 730 set up with the tracking system operator.
  • the extranet 730 is a direct link between a server 726 at the client's site 728 and a web server 732 located at the central tracking station 712.
  • clients may access the client servers in addition to accessing the container fracking server 714 to retrieve information.
  • the client servers are the client's primary information retrieval resource when the container 722 is within the client's tracking and monitoring network because the client servers collect and maintain more detailed, client specific information than the more general information stored on the container tracking server 714.
  • the client can still track and monitor these same containers 722 through the global information available on the container tracking server 714.
  • the container tracking system 710 is depicted.
  • the containers 722 are tracked using satellite-based, global positioning system (GPS).
  • GPS global positioning system
  • the container tracking devices 740 attached to each container communicate directly with the container tracking server 714 through the satellites 738 of the GPS.
  • the container tracking system 710 of the present invention has the capability to pinpoint the exact location of every container 722 anywhere in the world at any time.
  • each client can access the information on the container tracking server 714 or on a client server at any time to find out the location and status of one of its containers.
  • container fracking devices container monitoring devices
  • container tracking server client accessible information
  • the fracking device 740 may be a passive or active GPS tracking chip, a passive or active radio frequency identification (RFID) tag, a combination of both RFID and GPS or, it is foreseen, any form of remote tracking tag technology developed. If combined chips are used, means of programming and reading the chips may be slightly different based on the technologies used, but the data tracked and collected will be the same. Additionally, in any combined-chip embodiment, additional means for turning each chip on and off are included in these designs.
  • RFID radio frequency identification
  • a code is AKE3123FX where "FX" identifies the owner of the container, "AKE” specifies the type of container based on standard industry designators and "3123" is a unique alphanumeric value assigned to that specific container by the operator of the container tracking system.
  • the permanent code programmed into the tracking device 740 is also stored on the container tracking server 714 at the central fracking station 712. Once a container 722 is tagged and coded, the system of the present invention can track it.
  • a powered GPS fracking chip is used to allow for uninterrupted, real-time, global fracking of each container. Each powered GPS tracking chip sends the information for the container it is affixed to through the satellite system to the container tracking server 714.
  • a passive GPS tracking chip is used.
  • the passive GPS tracking chip receives a signal from the satellite system and, based on this signal, constantly stores and updates the location of the container 722 it is affixed to on the chip. This is known as passive positioning.
  • This internally stored container location information is then retrieved in several ways by a GPS chip reader which sends this retrieved information to the container tracking server 714.
  • the passive GPS chip information may be retrieved by periodic timed bursts, at preset way points, at preset destination points or via any other programmed data transmission trigger.
  • the fracking device 740 may be an RFID tag.
  • the RFID tag may be supplied by any number of commercial suppliers. One such supplier is Intermec Technologies Corporation which supplies an RFID tag identified by the trade-mark Ihtellitag. Intermec, as well as other suppliers, supply both passive and active RFID tags. Active RFID tags transmit a signal for retrieval by a data collection device. Passive RFID tags reflect or backscatter an RF transmission sent from the data collector back to the data collection device.
  • the RFID tracking devices 740 may be read, may be written to, may be rewritten to or may have individual bytes programmed and permanently locked.
  • automated tracking devices 740 such as GPS and RFID
  • the embodiment eliminates the need for manual container tracking, and no personnel are required to intercept, interpret or optically scan containers 722 within the system of the invention.
  • the system 710 of the present invention is flexible enough and has the capability to adjust for real world situations where the automated systems of the present invention might go down.
  • the system containers are tracked when they pass by RFID readers. These readers are preferably fixed, either geographically or permanently affixed to container fransports (e.g., ships, trucks, conveyors, cranes, tractors, etc.), but may be portable (hand-held).
  • the GPS system embodiment the capability exists to track the system at any time, at any location in the world. The only present limitations on using a GPS system, as opposed to an RF system, are mostly non-technical restraints such as government regulations (U.S. or foreign) on the use of GPS in certain situations (e.g., the FAA presently does not allow the use of external GPS while in flight).
  • U.S. or foreign government regulations
  • FIG. 14 an example container tracking area 750 is depicted.
  • the depicted container fracking area 750 is an airport, but it should be clear from the description of the present invention that the container fracking area could be any area where the operator of the container tracking system 710 desires to track container 722 movement, such as a port, a truck staging area, a warehouse, etc. An airport is only described by way of a single example.
  • the container tracking area 750 of Fig. 14 has container monitoring sites 752 at several locations throughout the container tracking area 750. There is a container monitoring site 752 at the point where containers 722 are passed into the terminal baggage area 754. There is a container monitoring site 752 where the baggage is loaded onto the plane 756, and there is a container monitoring site 752 at the cargo staging area 758.
  • the hardware to collect information at each container monitoring site 752 is essentially the same. As such, the container information collection process at the cargo staging area 758 is described herein as exemplary of the container information collection process at all the container monitoring sites 752.
  • the cargo staging area 758 is set up to track containers 722 anywhere within the boundaries of the cargo staging area 758.
  • the cargo staging area 758 has fixed data collectors 760 at each access point to the cargo staging area 758.
  • These fixed data collectors 760 in this example are RFID tracking device readers. These RFID data collectors 760 operate by constantly sending out an RF signal and when an RFID tracking device 740 passes within this fransmitted signal, the RFID tracking device 740 reflects or backscatters this RF signal back to the RFID data collector 760. From this reflected signal, the RFID data collector 760 collects all of the container's programmed information.
  • RFID data collectors including intermec Technologies Corporation which sells several types of data collectors, both portable and fixed.
  • the RFID data collectors 760 read the tracking devices 740 of the containers 722 on the truck.
  • the RFID data collectors 760 relay this information to a monitoring site RF antenna 762.
  • the monitoring site RF antenna 762 downloads this information to a station server 716 which in turn transmits this information to the master data files on the container tracking server 714 at the central tracking station 712.
  • the fixed RFID data collectors 760 may also be programmed to collect additional and more specific information.
  • the fixed RFID data collectors 760 on one side of the access gate can be programmed to detect inbound traffic and the RFID data collectors 760 on the other side of the gate can be programmed to detect outbound fraffic.
  • the monitoring site 752 may also use portable RFID data collectors 764 carried by site monitoring personnel, if the fixed RFID readers become temporarily unavailable. These portable RFID readers could also be used to spotcheck a container or update its status by the site monitoring personnel reading the RFID tracking device 740 of the container 722 of interest with the portable RFID data collectors 764.
  • the portable RFID data collectors 764 work in the same way as the fixed RFJD data collectors 760.
  • the data collected from the containers 722 by the portable RFID data collectors 764 is sent to the station server 716 via the antenna 762 in the same manner as the fixed data collectors 760 transmit data to the station server 716. Since the monitoring site antennas 762 only have a set range, the portable RFID data collectors 764 are equipped to batch or store the read container information temporarily if they are outside the range of the antenna 762, and once the portable RFID data collector 764 comes back into range of the antenna 762, the portable data collector 764 uploads all of the batched container information to the station server 716 in the same manner as described above.
  • the portable RFID data collectors 764 may also be used to write information to the memory of the fracking device 740.
  • the types of information that may be written to the fracking device memory and ultimately collected is limitless. Nevertheless, some of the additional container information besides the name of the container owner and the container specifications that the tracking system operator may want includes information on the container's itinerary, information on the name of the organization that is currently in possession of the container, notification as to whether the container has ever carried any dangerous or hazardous goods, among other things.
  • the container fracking server 714 maintains a number of datatables.
  • the datatables depicted here are merely exemplary of some tables that a tracking system operator might desire to maintain.
  • the actual datatables maintained on the container tracking server 714 depends on the information that the system operator wants to maintain.
  • the datatables on the container tracking server 714 may include a container information datatable 800, a client company datatable 802, a data collection device datatable 804, a monitoring site datatable 806, a optional monitoring personnel datatable 808 and a shipment specific datatable 810.
  • the container information datatable 800 may include specific information about the container including the container's fracking device code, and the container's specifications, among other data items.
  • the client company datatable 802 contains information on clients that are participants in the container tracking system 710.
  • the data collection device datatable 804 includes information on all of the data collection devices that are part of the container tracking system 710.
  • the monitoring site datatable 806 contains specific information on the worldwide monitoring sites, such as specific airport or dock configuration information.
  • the monitoring personnel datatable 808 contains information on all the personnel that can monitor, collect, and/or update data from the system's containers.
  • the shipment specific datatables 810 may actually be a number of datatables. These datatables contain information on specific shipments using a system container.
  • the client can access the container tracking server 714 by either the Internet or client specific extranet. Refe ing to Figs. 16-20, sample client user screens are depicted for an assumed client airport.
  • FIGs. 16A and 16B sample screens are depicted showing container summary information.
  • Fig. 16A shows the container status, where containers are refened to as LED's (Unit Load Devices), of all the containers at a particular client site, in this case an airport.
  • Fig. 16B shows the status of all the containers for a particular client. Thirteen are inbound, sixteen are cargo containers, ten are mail containers and ten are baggage containers.
  • Fig. 17A shows how a user can change locations to check the status of containers at other sites.
  • Fig. 17B provides a listing of all the inbound flights for a particular client and a listing of all the containers, broken down by content, on those inbound flights.
  • Fig. 18 shows a screen displaying dynamic staging data so that the client can track a container through all facets of their staging and loading operation.
  • Fig. 19 illustrates a screen where the client has performed a historical search on a particular container. To do this, the client enters the container number into the search area and executes the search.
  • the container tracking server 714 returns a historical container activity list for the searched container.
  • Fig. 20 depicts a screen where the client is monitoring a specific load plan.
  • the client enters a specific transport identifier number, such as a flight number.
  • the search will query the container tracking server 714 for this transport identifier and return the load plan for this transport identification number.
  • the above described screens are merely a representative sample of all the screens that can be generated for use with this system. Any information that is stored on the container tracking server 714 or any combination of such information can be manipulated to make any screen that is considered worthwhile. For example, it is possible with the right data feeds from the Federal Aviation Administration (FAA) that the exact real-time location of every flight, not just projected arrival times, can be displayed on these screens for the client's information as well. It is also possible to use the container positioning information and geographical mapping software to graphically depict where a client's container is actually located.
  • FAA Federal Aviation Administration
  • the tracking system of the embodiment can also help clients in managing demmrage. It can help clients determine how much a company bonowing a client's container owes the client for bonowing such container. With this system, the client can know exactly how long and for what purposes the company bonowed the container. It also helps the client to track down what in the past would have been lost containers. With this system, it is conceivable that a container would never be lost again.
  • the tracking system of the embodiment also provides advanced warning of any shipment problems or delays. If while monitoring the shipment, the comprehensive logistics service provider 20 notices a problem or delay, the comprehensive service provider 20 can attempt to remedy the problem immediately and can provide the buyer 42, or any system user 28, pre-notification of the problem so they can re-act accordingly before the problem or delay becomes unconectable.
  • a system user 28 can track the status of its shipment at any time.
  • the user 28 accesses the web page 36 of the merchant that sold the item or that handled the auction, or the web page of the comprehensive service provider 20 and enters the shipment tracking number at the appropriate place on the web page 36.
  • the web page 36 may also allow the user 28 to search for the tracking number if the user 28 does not have it.
  • the web site 34 activates the tracking interface 97 which formulates an electronic tracking request data stream containing the tracking number.
  • the tracking request is sent to the tracking engine 66 resident on the comprehensive logistics services provider's server 60.
  • the tracking engine parses out the tracking number from the data stream.
  • the tracking engine 66 determines whether the tracking information on file in the master shipment data tables 94 for the requested tracking number is cunent. If it is not, at step 610, the tracking engine 66 requests a data update from the databases of the vendors 26 or the integrators/specialized service providers 24 handling the shipment. In the example described herein, this request is performed via an API call, but any data retrieval and transmission technology can be used.
  • the shipment status information retrieved from the vendors' databases 99 is sent back to the comprehensive logistics service provider's server 60, for example, in an XML data stream format. When received, the status data from the data streams are . parsed out and stored to the master shipment data tables 94.
  • the tracking engine 66 takes the updated status data and sends to the site host 22 as a data stream where the site host 22 re-formulates the data and presents the data on the web page 36. Refening to Fig. 12, a sample tracking status web page 36 is illustrated. The status web page shows that delivery of the shipment is complete and shows the date and time certain key shipping events happened.
  • tracking system as described herein may be implemented as a separate system, apart from other aspects of the embodiment described herein.

Abstract

A method and system that provides comprehensive logistics services (20) by having the ability and flexibility to integrate logistics vendors (26), via an interconnected network, across any industry, at any time, no matter what vendor carrier ('vendor neutral') or mode of transportation is to be used and no matter what country the shipment is being handled in or delivered to. In addition to other services, the system and method of the present invention provide landed cost quoting (62), shipment booking (64) and shipment tracking (66). A separate tracking system and method are also provided.

Description

TITLE; SYSTEM AND METHOD FOR PROVIDING
COMPREHENSIVE LOGISTICS SERVICES
BACKGROUND OF THE INVENTION
As the importance of global shipping and logistics increases, there is an unresolved need for a comprehensive logistics support service that can manage a global shipment from door-to-door, using any number of differing vendors and that can provide the buyer of the product with a guaranteed, upfront landed cost quote, that takes all shipping-related costs, international duties and taxes into account, for the shipment.
Present systems are incapable of performing these tasks. Present electronic commercial exchange sites are capable of bringing buyer and seller together to initiate and close a purchase, but after that the parties to the transaction have to go off-line and conduct the shipment transaction via more established methods (e.g., telephone,' fax or in person) due to the myriad of international trade duties and taxes. Tariffs Impede Trade via Web on Global Scale, The Wall Street Journal, April 17, 2000, Bl and B4. Recent studies show that companies on-line are having trouble managing the logistics involved in actually getting the products purchased from their web sites to the purchasing customer. As a result, innumerable companies are ignoring or even intentionally avoiding the opportunity to sell their products to the over 5.5 billion customers located outside of the United States.
Present logistics systems are too limited and too inflexible to manage global shipments across a multitude of vendors and across all transportation modes. Presently, worldwide single carrier networks, such as Federal Express and United Parcel Service, do exist that have the capability to ship products globally. Such single carrier networks, however, have numerous inherent weaknesses, and by selecting a single carrier network as a logistics provider, a company unwittingly integrates the weaknesses of the selected carrier into its own business operations. The first drawback of single carrier networks are that they are vertically integrated. That means that once a customer gives its shipment to a single carrier network, all of the services provided in transporting the shipped product are provided by that one single carrier, including any air travel, any rail travel, any shipping services and any other means of transport. The customer has to use all of the services provided by that single carrier even if one or more legs of the shipment would be cheaper, quicker or more efficient if provided by an independent carrier. Even if one of these single carrier networks wanted to interact with an independent carrier, it would be extremely difficult. Most of the single carrier networks are built on legacy mainframe or at best Windows 3.1 systems using Electronic Data Interchange (EDI) to process and track their shipments. EDI is an outdated data exchange protocol used between heterogeneous systems where the business rules for data interchange are rigidly defined so that the systems can interact with each other. These legacy EDI systems are effective within single proprietary networks, but they lack the flexibility to interact with other vendors and customers that are not utilizing their particular legacy EDI business rules. This limitation is compounded by how EDI has been utilized. Instead of creating standardized formats, EDI "standards" have fractured into hundreds of class and function "standards", each with dozens of versions and updates. As such, these proprietary single carrier networks lack the capability to quickly and easily interact with independent vendors and customers.
By relying on a single carrier network for its logistics services, a company is subject to the vagaries of that single carrier, as well. If the single carrier network raises prices, any company relying on that carrier network's services has to accept those price increases in the short term until it can negotiate a better deal with another logistics provider. If the employees of the selected single carrier network go on strike, the reliant company suffers as well. If the selected carrier has inflexible and inefficient routing procedures for certain shipments, the carrier's clients are burdened by these inflexibilites and does not have the option to choose more efficient routes for a given shipment.
There is a need for a method and system that has the flexibility to provide the most efficient and cost effective logistics support and service on a transactional basis. There is a need for such a system and method to be able to integrate a host of logistics vendors, via an interconnected network, across any industry, at any time no matter what vendor, carrier or mode of transportation is being used and no matter what country the shipment is being handled in or delivered to so that any shipping customer can send a shipment anywhere in the world using the most cost-effective carrier and manner of shipment with minimal problems.
Also, individual shipping organizations have developed proprietary systems to track shipping containers and/or packages within their own distribution networks. While these systems work well for tracking containers and/or packages within these specific proprietary networks, these systems, by definition, lack the flexibility to cut across proprietary distribution networks and track a container or package being shipped by numerous vendors possibly using several modes of transportation, such as railroad, truck, airplane or ship, and across several geographical and political locales. In addition, individual, independent carriers, that are not part of an integrated and proprietary distribution network, presently use inefficient and inadequate methods to track containers and their shipments. This inability to efficiently and effectively track containers across various vendors and modes of transport is a significant competitive and financial hindrance, and as global trade increases, these shortcomings will only be magnified.
Also, in the shipping industry, because carriers and/or vendors have inadequate or nonexistent means to track and manage their own containers, they often lose track of their own inventory and may be forced to borrow containers from other carriers and are charged a fee if not returned within a specified period. . Compounding the problem, these carriers do not effectively track these container loans. Usually, the carriers rely on manual systems such as paper-based systems to track these container loans and, as a result, the loaning carrier may not be appropriately compensated. Often times, these borrowed containers are never returned to the loaning carrier.
There is a need for a method and system that has the flexibility to track containers for any industry, at any time no matter what vendor, carrier or form of transportation is being used so that any interested party can check the location of one of its containers and/or shipments. An object of this invention is to satisfy this need.
SUMMARY OF THE INVENTION
The present invention is directed to a method and system that has the flexibility to integrate numerous logistics vendors, via an interconnected network, across any industry, at any time, no matter what vendor carrier ("vendor neutral") or mode of transportation is to be used and no matter what country the shipment is being handled in or delivered to.
According to one aspect of the present invention a system for providing logistics services is provided. The system comprises a server storing a shipment booking engine program, input data in communication with the server, vendor rate data in communication with the server, shipment insurance rate data in communication with the server, shipment duty and tax rate data in communication with the server, shipment datatables in communication with the server, an interconnected data network, a site host system in operative communication with the server, a network access device connected to the data network and a tracking engine program stored on the server and shipment tracking number data in communication with the server. When the shipment tracking engine program is activated, the shipment tracking number is input into the shipment tracking engine program and the shipment tracking engine program retrieves all of the information relating to the input tracking number from the shipment datatables. The logistics service may further comprise an interconnected data network and a site host system in operative communication with the server. The site host system may activate the shipment tracking engine program and provide the shipment tracking number data to the tracking engine program. Further, at least one of the input data, the vendor rate data, the shipment insurance rate data, the shipment duty and tax rate data, the shipment datatable information and the shipment tracking number data may be communicated to the server using electronic data transmission technology.
Further, the electronic data transmission technology used may be extensible markup language (XML).
In a second aspect, a method for providing logistics services is provided. The method comprises providing a landed cost quoting engine program, providing input data, providing vendor rate data, providing shipment insurance rate data, providing shipment duty and tax rate data, activating the landed cost quoting engine program to calculate a vendor neutral landed cost quote using the input data, the vendor rate data, the shipment insurance rate data and the duty and tax rate data, providing a shipment booking engine program, providing shipment datatables, activating the shipment booking engine program to generate a shipment booking, providing a tracking engine program, providing shipment tracking number data and activating the tracking engine program to use the provided shipment tracking number data to retrieve all of the information relating to the input tracking number from the shipment datatables. The method may further comprise providing a registration engine program, providing system user data, providing denied party data and activating the registration engine program to determine whether the provided system user data matches the provided denied party data and generating a denied user response if the specific system user data matches the denied party data.
The method may have at least one of the steps of providing input data, providing vendor rate data, providing shipment insurance rate data, providing shipment duty and tax rate data, providing shipment datatable information, providing shipment tracking number data, providing system user data and . providing denied party data being provided using electronic data transmission technology.
The method may have the electronic data transmission technology used as being extensible markup language (XML).
The method may have the step of providing input data as including determining a Harmonization Tariff System (HTS) code.
In a third aspect, a system for providing tracking services is provided. The system comprises a server, input data in communication with the server, shipment datatables in communication with the server, an interconnected data network, a site host system in operative communication with the server, a network access device connected to the data network, a tracking engine program stored on the server and shipment tracking number data in communication with the server. When the tracking engine program is activated, the shipment tracking number is input into the tracking engine program and the tracking engine program retrieves information relating to the input tracking number from the shipment datatables.
Further, the system may have an interconnected data network and a site host system in operative communication with the server. The site host system activates the shipment tracking engine program and provides the shipment tracking number data to the tracking engine program.
In other aspects, various combinations and subset of the above aspects are provided.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other aspects of the invention will become more apparent from the following description of specific embodiments thereof and the accompanying drawings which illustrate, by way of example only, the principles of the invention. In the drawings, where like elements feature like reference numerals (and wherein individual elements bear unique alphabetical suffixes):
FIG. 1 illustrates an overview of an embodiment of the system of the present invention; FIGS. 2A, 2B, 2C, 2D, 2E, 2F and 2G illustrate an exemplary process for requesting a landed cost quote for an embodiment of the system of the present invention: FIG. 3 depicts an exemplary input screen for inputting shipment information to receive a landed cost quote from an embodiment of the system of the present invention;
FIG. 4A depicts an exemplary input screen for a Harmonized Tariff System (HTS) code classifier from an embodiment of the system of the present invention;
FIG. 4B depicts an exemplary screen for the HTS code classifier of an embodiment of the present invention illustrating the generation of an HTS code using a code generation wizard of the depicted embodiment;
FIG. 5 A depicts an exemplary screen for the HTS code classifier of an embodiment of the present invention illustrating a sample search for an HTS code using a text search function of the depicted embodiment;
FIG. 5B depicts an exemplary screen for the HTS code classifier of an embodiment of the present invention illustrating the results of the sample search using the text search function bf the depicted embodiment;
FIG. 5C depicts an exemplary screen for the HTS code classifier of an embodiment of the present invention illustrating selection of an HTS code using the text search function of the depicted embodiment; FIG. 6 depicts an exemplary vendor set chart from an embodiment of the present invention; FIG. 7 depicts an exemplary vendor set chart illustrating associated vendors for each vendor set from an embodiment of the present invention; FIG. 8 depicts an exemplary rate chart for a vendor set from an embodiment of the present invention; FIGS. 9A, 9B and 9C illustrate an exemplary process for booking a shipment in an embodiment of the system of the present invention; FIGS. 10A and 10B depict an exemplary input screen for inputting shipment information to book a shipment in an embodiment of the system of the present invention; FIG. 11 is a block diagram of a tracking system used in an embodiment of the invention; FIG. 12 is a block diagram of a shipment tagged with a tracking device for the embodiment of FIG. 11 ; FIG. 13 A is ablock diagram ofthe tracking system ofFIG. il; FIG. 13B is a block diagram of another embodiment of the tracking system of FIG 11; FIG. 14 is a block diagram of a container tracking area associated with an embodiment of a tracking system of FIG. 11; FIG. 15 is a block diagram of a tracking server of the embodiment of FIG. 11;
FIG. 16 A is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention showing status information of a container tracked by the embodiment;
FIG. 16B is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention showing status information containers for a particular client;
FIG. 17A is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention illustrating how a user can change locations to check the status of containers at other sites;
FIG. 17B is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention illustrating a listing of flights for a particular client;
FIG. 18 is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention illustrating dynamic staging data;
FIG. 19 is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention illustrating a historical search on a particular container; FIG. 20 is an exemplary screen shot generated by software of an embodiment of the tracking system of the present invention illustrating a client monitoring a specific load plan;
FIG. 21 A and 2 IB illustrate an exemplary process for tracking a shipment booked in an embodiment of the tracking system of the present invention;
FIG. 22 depicts an exemplary screen illustrating tracking information for a shipment booked in an embodiment of the present invention;
FIGS. 23A and 23B depict an exemplary quote request in Extensible Markup Language (XML) from an embodiment of the present invention; and
FIGS. 24A and 24B depict an exemplary booking request in Extensible Markup Language (XML) from an embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
The description which follows, and the embodiments described therein, are provided by way of illustration of an example, or examples, of particular embodiments of the principles of the present invention. These examples are provided for the purposes of explanation, and not limitation, of those principles and of the invention. In the description which follows, like parts are marked throughout the specification and the drawings with the same respective reference numerals.
The Comprehensive Logistics Service Provider
Referring to Fig. 1, a comprehensive logistics service provider 20 provides full, end-to-end logistics support for the businesses it supports. The comprehensive logistics service provider 20 is in communication with a number of web site host operators or site hosts 22 and with a number of logistics service providers, such as integrators/specialized service providers 24 or logistics vendors 26, via a computer network such as the internet. These integrators/specialized logistics service providers 24 and vendors 26 may include freight forwarders, independent carriers, air transportation companies, rail transport companies, trucking companies, shipping companies and a number of other carrier vendors. The site hosts 22 support and maintain web site programs 34 on web servers 30 for their own or someone else's benefit. Anyone accessing a web site 34 that uses the present invention is referred to as a system user 28. A system user 28 accesses a web site 34 through a network access device 32, such as a computer. The network access device 32 interacts with the web site 34 via the network, usually through a browser software program such as Netscape Navigator® or Microsoft Internet Explorer®, to create a web page 36 for the user 28 on the network access device 32. Any type of business requiring logistics support, shipping, documentation, trade compliance and related services can be supported using the system of the present invention. However, by way of example, two different business models are discussed herein. The first business model is a merchant-type business format 40. The second business model is an auction-type business format 50. The main distinction between the two is that in the merchant-type format 40, the merchant sells his own goods to various buyers 42 either directly or through grouping methods (such as catalogues, co-ops, VARs), while in the auction-type format 50, the web site sponsor acts as an exchange for matching participating sellers 54 with interested buyers 42. The business sponsoring an auction-type format, generally speaking, does not sell its own goods.
The comprehensive logistics service provider 20 of the present invention uses three automated service components and an automated registration component to provide logistics services to the businesses it supports. The three service components are: 1) a landed cost shipment quote generation engine 62, 2) a shipment booking engine 64 and 3) a shipment tracking engine 66. These "engines" are software modules that reside on a server or servers 60 maintained and operated by the comprehensive logistics service provider 20. The registration component is a registration engine 68 which, in certain circumstances, registers users of the system and performs validation checks as described below. The quoting engine 62 performs the operation of generating complete, door-to-door landed cost shipment quotes. The booking engine 64 calculates an updated landed cost shipping rate and books the shipment based on this updated rate. The tracking engine 66 tracks booked shipments throughout the shipping process.
The Quoting Engine
Referring now to Figs. 1 and 2A-2G, a user 28 may get a landed cost shipment quote from the system of the present invention in the following manner. In step 100, a buyer 42 accesses a business's web site 34 which generates the business's web page 36 on the buyer's network access device 32. (Most of the time, the user 28 will be a buyer 42 so the following discussion, in order to simplify the discussion, describes the use of the system from a buyer's perspective. It should be understood, however, that the system operation described herein would apply to any user 28 of the system.) At step 102, the buyer 42 reviews the web site 34 until the buyer 42 finds and selects a product or item of interest. Upon selection of an item, the web site 34 retrieves the data for that particular item from an item data table 70 (Fig. 1). The information for the item data table 70 is provided and maintained by the merchant or business sponsoring the web site 34. In an auction-type business model, the sellers 54 are the ones who provide the particular information about the item they are selling. The buyer 42 at this point, as step 104 indicates, usually wants to find out pricing information, including shipment costs, for the product of interest and makes such a request of the web site 34. At step 106, before providing such information, the web site 34 may have the buyer 42 register with the web site 34. All of this information is stored to a buyer data table 72 (Fig. 1). If a seller 54 is involved, the seller 54 usually has to register with the web site 34 as well, and all of the seller information is stored to a seller data table 74 (Fig. 1). At step 108, the web site 34 responds to the buyer's request for product purchase and shipping information by pulling together the purchase price information from the merchant's own databases. Simultaneously, the web site 34 activates a quote interface 76 from the site host server 30 (Fig. 1). At step 110, the quote interface 76 retrieves the information it needs from the site host's data tables, such as the item data table 70, the buyer data table 72 and/or the seller data table 74. The quote interface 76 displays the retrieved information to the buyer 42 for verification, and it requests the buyer 42 to provide any additional information (e.g., shipping mode, additional shipping services, pickup and delivery locations) that is necessary to generate a quote. At step 112, the buyer 42 verifies the retrieved information and corrects any information that needs to be corrected and adds any additional information that needs to be added.
Fig. 3 depicts a sample web page 36 that a buyer 42 may see. The customer ID 200 is usually a required field and is used as an identifier between the web site merchant and the comprehensive logistics service provider 20. The next three fields, the origin country field 202, the origin zip/postal code field 204 and the address type field 205, are required fields. These fields designate the shipment origination information. In the auction-type business format, the seller's location information is usually used and stored in the seller data table 74. In a merchant-type format, since the merchant knows and assigns the location of products it is selling (e.g., in a warehouse, at a certain distribution center), the shipment origination information is usually stored in the item data table 70 along with specific product information. If the information retrieved for fields 202-205 is incorrect, then the system user 28 needs to change this information. The origin country field 202 is preferably a pull down menu that lists all the countries that the comprehensive logistics service provider 20 can legally ship from. The address type field 205 is also preferably a pull down menu that specifies the type of location that the item is being shipped from (e.g., a business location, a residential location, a governmental location).
The next two fields 206, 208 designate the shipment destination information. Specifically, the destination country and the destination zip/postal code are entered into these fields. These too are required fields. This information is usually stored in and retrieved from the buyer data tables 72. If the actual destination of the shipment is different from the buyer address retrieved from the data table 72, then the buyer 42 needs to change these fields 206, 208 to reflect the proper shipment address. The destination country field 202 is preferably a pull down menu that lists all the countries that the comprehensive logistics service provider 20 can legally ship to.
The next field 210 is for a Harmonized Tariff System (HTS) code. This field is optional, but failure to include this code will cause the system to generate an incomplete shipment quote that does not include duties and taxes. The HTS code is an internationally recognized code that identifies the type of product being shipped and facilitates the shipment of goods in international trade. HTS codes are fairly complex. The first six digits are internationally standardized across most countries, and are arranged in a hierarchical fashion with section designations at the top level, chapter designations at the next level and, finally, heading and item designations at the next two levels. Presently, using these first six digits there are twenty-one section designations to choose from, fifty-nine chapter designations to choose from and one thousand twelve heading and item designations to choose from. This results in a total of eight thousand one hundred fifty-four HTS codes from which a buyer 42 has to choose. Plus, many countries use additional digits to increase the level of detailed information provided in this system. As such, without assistance, selecting the proper HTS code is fairly difficult.
To assist the buyer 42 in this selection, the system provides the buyer 42 with the option of using an HTS classifier to determine the proper HTS code. By clicking on the HTS classifier icon 212, the buyer 42 is directed to an HTS classifier web page as depicted in Figs. 4 A and 5 A. At this web page, the buyer 42 has the option of searching for the proper HTS code by doing a text search or using templates pre-programmed into the system (commonly referred to as a "wizard"). The buyer 42 may select the text search option by clicking on the "Text Search" icon 214 or the buyer 42 may select the wizard option by clicking on the "Wizard" icon 216. Assuming the buyer 42 elects to use the wizard option by clicking on the "Wizard" icon 216, the first screen of the wizard, as depicted in Fig. 4A, would appear. The wizard has four fields that must be completed: 1) a section field 218, 2) a chapter field 220, 3) a heading field 222 and 4) an HTS item field 224. In the section field 218, the buyer 42 selects a "section" which identifies a broad category that describes the product to be shipped. The buyer uses pull down menus to increasingly refine the descriptions - and therefore, their related HTS code - by completing all of the fields of the HTS wizard. The pull down menus list all of the Harmonized Tariff System categories for each field.
Fig. 4B illustrates a sample wizard template with all of its fields completed. In the sample, the section selected is section 04 which covers "Prepared Foodstuffs; Beverages, Spirits, and Vinegar". The section descriptor is still very broad so the buyer has to choose a chapter from the chapter field pull down menu to further refine the product classification. In the example depicted, the chapter selected is chapter 17 which covers "Sugars and sugar confectionery". The chapter descriptor is more refined than the section descriptor, but is still very broad in regard to the exact items being shipped. The buyer 42 further refines the product's classification by completing the heading field 222 and the HTS item field 224. In the example, the heading selected is "Molasses resulting from the extraction or refining of sugar", and the HTS Item selected is "Cane Molasses". As the user follows the wizard's flow, the wizard automatically determines the levels of the HTS code for the product described by the field entries by referencing data tables containing all of the HTS code information. Once all the fields have been completed, the HTS code program displays the constructed 6- digit HTS code in the HTS code field 226. In the Fig. 4B example, the HTS code for the product to be shipped "Cane molasses" is 170310. This is the number that is entered into the HTS code field 210 of the online quoting screen depicted in Fig. 3. Assuming instead that the buyer 42 elects to use the text search option by clicking on the "Text Search" icon 214, the first text search screen, which is depicted in Fig. 5 A, would appear. In the first step of the text search, the buyer 42 enters a description of the item the buyer 42 wishes to search for in the search field 228 and clicks on the "Submit Query" button 230. In the example depicted, the buyer 42 is searching for the HTS code for "Cane molasses". As depicted in Fig. 5B, once the "Submit Query" button 230 is activated, the HTS code program searches its databases and returns code descriptions containing the searched terms in the code description field 232. In the example depicted, only one descriptor was found containing the search term, "cane molasses". In step 2 of the text search option, the buyer 42 selects which of the returned product descriptors best describes the product to be shipped. Once the buyer 42 selects the product descriptor that he believes is most appropriate, the HTS code program, as illustrated in Fig. 5C, returns the HTS code for that product descriptor in the Harmonized Code field 234. As in the Fig. 4B example, the HTS code for the product to be shipped in the Fig. 5C example, "Cane molasses", is 170310. This number is the code that is entered into the HTS code field 210 of the online quoting screen (Fig. 3).
Referring again to Fig. 3, the HTS code has been determined and input into the HTS code field 210. The next field is the piece type field 235. In the piece type field 235, the configuration of the item to be shipped is designated (e.g., package, pallet, container, loose). The piece type field 235 preferably uses a pull down menu. The next field is the service type field 237. In the service type field 237, the delivery manner is specified (e.g., air-parcel standard; ocean-parcel standard; 2-3 day service, via air; ocean container). The service type field 237 preferably uses a pull down menu as well. The next seven fields contain information specific to the item being shipped and are required fields. Most of this information is usually stored in and retrieved from the item data tables 70. A height field 236, a width field 238, a length field 240 and a weight field 242 specify the height, width, length and weight, respectively, of the item to be shipped. If the item requires specialized packaging, then these figures would include the packaging. A count field 244 displays the number of items that the buyer 42 indicated he wanted to purchase. A value field 246 contains the estimated value of the entire shipment. Finally, a dangerous good field 247 designates whether the item to be shipped is dangerous (e.g., hazardous waste). In the example illustrated in Fig. 3, the item is not a dangerous good. The dangerous good field 247 preferably uses a pull down menu. Though not depicted here, the buyer 42 may also request special services, such as guaranteed delivery data and additional insurance. Any additional services requested would then be factored into the final quote. Once the buyer 42 has entered all of the required information described above into the Online Quoting screen, the buyer 42 clicks on the "Quote" button 248 to get a landed cost shipment quote.
Referring again to Fig. 2B, in step 114, the clicking of the "Quote" button 248 activates the quote interface 76 which gathers all of the shipment information submitted by the buyer 42 and formulates an electronic data request containing all of the submitted shipment information. All of the information contained in the request is described herein as if formatted using Extensible Markup Language (XML). Additional data transfer methods, such as EDI and HTTP post, can also be used, depending on clients' business and technical requirements.
At step 116, the electronic quote request packet is sent to and received by a security application resident on the comprehensive logistics service provider's server 60, which verifies the data and sender, and forwards authorized data to appropriate applications. In this example, at step 118 (Fig. 2B), the quoting engine 62 parses out the data contained in the electronic quote request data stream and saves it into memory for use in shipment cost calculations. While any electronic data transmission technology can be used, these examples use XML packets and parsers that transmit and parse out data to the quoting engine 62. There are four components to a landed cost shipment quote that the quoting engine 62 must determine: 1) pre-shipment costs (e.g., packing costs), if any; 2) freight charge for delivery from the shipment origin to the shipment destination (the "door-to-door freight charge"; if multiple carriers and/or freight facilitators are involved, then this charge is the sum of all participating vendors' freight charges); 3) insurance costs; and 4) any shipment duties and taxes.
At step 120, the quoting engine 62 determines the first component of the landed cost quote, pre-shipment costs. Packing costs are relatively common pre- shipment costs and will be discussed for illustrative purposes for this example. Packing costs are calculated if the buyer 42 requests packing services, and/or the seller, insuring agent, shipping provider, and/or government regulations require packaging. A shipment packing cost depends on a number of variables including, among others, the volume and weight of the item to be shipped, the sensitivity of the item being shipped and any special handling requirements for such items (e.g., toxic waste). Note that if packaging is required and/or requested, all shipment calculations requiring the shipment's dimensions - size, volume, weight - always include the additional dimensions of the packaging.
At step 122, the quoting engine 62 starts the process of determining the second component of the landed cost shipment quote, the door-to-door freight charge. Before the quoting engine 62 can calculate freight costs, the quoting engine 62 first has to determine what sets of vendors (or "vendor set") are capable of handling the shipment. Referring to Fig. 6, the quoting engine 62 uses five key elements to determine what vendors are capable of handling the shipment: 1)
< shipment weight class codes, 2) service class codes, 3) commercial class codes, 4) origin region codes and 5) destination region codes. The quoting engine 62 can use actual data values for each of these key elements to determine which vendors to use, or the quoting engine 62 can use codified tables for each of these elements. The process demonstrated here describes how codified tables could be used. To determine the shipment weight class code, the quoting engine 62 calculates the actual weight of the shipment at step 124. At step 126, the quoting engine 62 next calculates a shipment volume-weight factor based on dividing the volume of a shipment item by a standard conversion factor (166 cubic inches/lb for international shipments, and 192 cubic inches/lb for domestic-only shipments within the United States). At step 128, the quoting engine 62 compares the actual weight of the shipment to the calculated volume-weight factor of the shipment to determine the shipment's chargeable weight. The greater of the shipment's actual weight versus the shipment's volume-weight factor is the shipment's chargeable weight. In the example request illustrated in Fig. 3, the calculated volume- weight factor is the chargeable weight because the volume- weight factor 1301 lbs. ((60in x 60in x 60in)/166 in3/lb) is greater than the shipment's actual weight of 20 lbs.
At step 130, with the chargeable weight determined, the quoting engine 62 searches a pre-set weight class code look up table to find the weight class code for the determined chargeable weight. Referring to Fig. 6, the weight class code for the illustrated example (chargeable weight =1301 lb.) is "1". At step 132, the quoting engine 62 identifies the standard shipment services (e.g., normal delivery, air versus ocean mode, lose package versus containerized cargo) and any special shipment services requested by the buyer 42 (e.g., 2-3 day, express, additional insurance) to find their related service class codes. The quoting engine 62 searches a pre-set system look up table of service class codes to find the codes that match the standard and/or any special service requested. Referring to Fig. 6, the service class code for the illustrated example (2-3 day service, via air) is "2". At step 134, if the system user 28 and/or host site 22 has not provided a commercial class code, then the quoting engine 62 can determine a commercial class code by searching a pre-set look up table based on the entered HTS code. The commercial class codes not only identify the product type or commodity being shipped, but also indicate if the shipped product has any special handling requirements (e.g., item is perishable and must be refrigerated, item is hazardous and requires special shipping precautions). Referring to Fig. 6, the commercial class code for the illustrated example is "1". At step 136, the quoting engine 62 determines an origin region code. The origin region codes are stored in a pre-set look up table and are linked to possible shipment origin countries and postal codes. To find an origin region code, the quoting engine 62 searches the pre-set look up table to find an origin code that corresponds to the shipment origin country and postal code sent by the electronic data request. At step 138, similar to determining the origin region code, the quoting engine 62 uses the shipment destination and postal code sent by the electronic data request to find a destination region code stored in a pre-set destination region code look up table. These electronic data requests can be made via any electronic data transmission technology, although XML is the sample technology described herein. Referring to Fig.6, the origin region code and the destination region code for the illustrated example are "1" and "24" respectively.
Once all of the codes are determined, as indicated at step 140, the quoting * engine 62 uses the actual data values or the equivalent selected codes to determine which vendor sets can handle the shipment. In the example illustrated in Fig. 6, the quoting engine 62 has determined that vendor sets "100", "105" and "108" are capable of handling a shipment with a "1" weight class code, a "2" service class code, a "1" commercial class code, a "1" origin region code and a "24" destination region code. Referring to Fig. 7, vendor sets are groups of vendors that work together to complete an entire shipment. The example shipment discussed herein is an international shipment (U.S. to New Zealand) with seven stages (or "legs"). As illustrated on the top half of Fig. 7, the shipment goes from a shipper 250 in the U.S. to an origin inland vendor 252, such as a railroad or trucking company, which transports the shipment to an origin agent 254. The origin agent 254 handles the transfer of the shipment from the origin inland vendor 250 to a gateway-to-gateway carrier 256. The gateway-to-gateway carrier 256 is the vendor who carries the shipment from one designated transportation gateway to another transportation gateway. As illustrated in Fig. 8, there are certain designated transportation gateways throughout the world, such as Chicago; New York; Los Angeles, and Auckland, New Zealand. The gateway-to-gateway carriers are the vendors that carry shipments between these major shipment hubs. These vendors are typically airlines or shipping companies. In the example illustrated, a gateway-to-gateway carrier 256 that travels from the Chicago gateway to the Auckland, New Zealand gateway is required. Referring again to Fig. 7, once the gateway-to-gateway carrier 256 reaches the destination gateway, the carrier 256 works with a destination agent 258 which transfers the shipment to a destination inland vendor 260, such as a railroad or trucking company. The destination inland vendor 260 finishes the shipment by delivering it to the designated consignee 262. Fig. 7 illustrates a resultant vendor set table 264 for the three vendor sets that were selected by the quoting engine 62 in this example. The vendor set table 264 has identifying vendor set numbers that link to specific vendors that will be used for each leg of the shipment for that given vendor set. The chart illustrates that in some cases the same vendor may be able to handle the entire shipment, such as vendor set 100, or that in other cases, a number of different vendors work together to complete a shipment, such as vendor sets 105 and 108. The vendor set table 264, and the vendor set numbers and codes contained therein, are created by the comprehensive logistics service provider 20.
Referring again to Fig. 2D, after determining the vendor sets that could possibly be used for the shipment at step 140, the quoting engine 62 next determines the shipment rates for each selected vendor set at step 142. At step 144, the quoting engine 62 first determines if the rates for each vendor of the selected vendor sets are on file locally in a master vendor rate data table 80 (Fig. 1) and that they are current. If they are on file locally and current, the quoting engine 62 retrieves this rate information and, as indicated in step 148 and described below, performs calculations using this vendor rate information to determine each vendor set's rate for the shipment requested. If a vendor's rates are not on file locally or not current, the quoting engine 62 requests an electronic data update, as indicated in step 146, to all of the vendor databases that it needs to get current rate information from. One method to request and retrieve this data is via an application program interface (API) call. While activating API calls is the sample method used in the description of this invention to communicate to another system, any data request and retrieval technology can be used. Referring to Fig. 1, if the vendors in the vendor set are coordinated by an integrator/specialized logistics service provider 24, then the API call is made on an integrator/specialized logistics service provider's consolidated vendor rate date table 82. The consolidated vendor rate data table 82 stores all of the vendor data for each vendor that works with that specific integrator/specialized logistics service provider 24. The integrator/specialized logistics service providers 24 maintain and update their consolidated vendor rate data tables 82 either manually or by making their own electronic data requests (e.g., via API calls) on affiliated vendor's rate data tables 84. If the comprehensive logistics service provider 20 deals directly with a vendor 26 and/or does not go through an integrator or specialized logistics service provider 24, this data request is made directly to that vendor's database 84. In a preferced embodiment, the data can be retrieved by API calls and sent back to the comprehensive logistics service provider's server 60 in a pure data stream format, such as in XML. Whether using XML, EDI, or any other data transmission method, each data stream must be checked against a predefined and standardized data definition (i.e., all anticipated data elements, along with their structures and acceptable values) to ensure that the data stream is well-formed and valid. While the use of the invention described herein is not limited to or by these listed technologies, any data retrieval and transmission technology can be used with the processing described herein. If using XML, XML schemas and/or Document Type Definitions (DTD's) can be used to define the standard elements. DTD's are definitional templates which define the data structure for each data element in an XML data stream. XML schemas go further by defining how to describe the structure of XML documents (Structures"), and providing improved management of dates, numbers, and other special data ("Datatypes"). The data streams sent back to the server 60 are parsed, and the parsed out data is saved to the appropriate fields in the master vendor rate data tables 80. At step 148, with the master vendor rate data tables 80 updated, the quoting engine 62 performs the rate calculations for each vendor set to determine the shipment rate for each vendor set for the requested shipment. Referring again to Fig. 8, the quoting engine 62 has to determine the rates and costs for three main legs of the shipment. The first main leg of the shipment 300 is picking up the shipment from the shipper 252 and transporting it to the gateway-to-gateway carrier 256 at an origin gateway 302 (e.g., Chicago O'Hare Airport (ORD)). The second main leg of the shipment 304 is transporting the shipment from the origin gateway 302 to a destination gateway 306 (e.g., Auckland Airport (AKL)), via the gateway-to-gateway carrier 256. The third main leg of the shipment 308 is receiving the shipment from the gateway-to-gateway carrier 256 at the destination gateway 306 and transporting the shipment from the destination gateway 306 to the consignee 262. At step 150 (Fig. 2E), the quoting engine 62 determines the rate and costs for the first leg of the shipment 300 (from the origin to the origin gateway). Referring to Fig. 8, most vendors designate cost zones for pick-up and delivery to a particular gateway. The cost zones are usually based on postal or mileage. If using postal codes, each particular zone will usually cover a range of postal codes. If using mileage, the distance from point 1 to point 2 is the measurement used, and each zone is defined as a range of values that the mileage falls within. Additional methods of zoning are used, but can usually be classified as a version of one of these two. Again, the invention described here is not limited to how zones are classified, as the processes described herein are adaptable. The vendor set depicted in Fig. 8, vendor set 100, has three cost zones (A, B and C) surrounding the ORD gateway. Each zone represents a different rate for transporting a shipment to the designated gateway. When calculating the rates for other vendor sets, however, these zones will change because each vendor set has its own zones and costs for a particular gateway.
In the example illustrated in Fig. 8, the shipper/origin of the shipment is located in zone A for vendor set 100. The rate to transport a shipment from zone A to the ORD gateway for vendor set 100 is fifty dollars ($50), as chart 310 on Fig. 8 indicates. Referring to Fig. 2E, the next step 152 is to determine the rate for the second leg of the shipment for the selected vendor set. The second leg of the shipment is from the origin gateway 302 to the destination gateway 306. Since this portion of the shipment is not dependent on the origin or destination location, this rate is pulled directly from the vendor set's rates on file in the - 3 master vendor rate data tables 80. For vendor set 100, the gateway-to-gateway, rate is indicated on chart 312 of Fig. 8 as one thousand dollars ($1000). Referring to Fig. 2E again, the next step 154 is to determine the rate for the third leg 308 of the shipment (from the AKL to destination). This rate determination is similar to the rate determination for the first leg 300 of the shipment. The zone for the destination location is determined (e.g., zone C) and the rate for that zone is retrieved. In the example in Fig. 8, the shipment destination is in zone C in relation to Auckland Airport (AKL). The rate for vendor set 100 for transporting a shipment from AKL to zone C is one hundred dollars ($100) as indicated in chart 310 of Fig. 8. With all the rates for the legs of the shipment determined, the quoting engine 62, at step 156 (Fig. 2E), adds all of these rates together along with any additional costs, such as pickup/delivery costs, agent handling fees, special service fees (e.g., 2-3 day service), to determine the door-to-door freight charge for that particular vendor set. The quoting engine 62 then calculates the door-to-door freight charge for each vendor set that the quoting engine 62 selected. Once all of the door-to-door freight charges are calculated for each vendor set, the quoting engine 62, at step 158 (Fig. 2E), selects the vendor set with the lowest cost. Similar processing can have the vendor sets evaluated for fastest delivery time, guaranteed delivery date and other factors against all vendor sets or against a subset of preferred vendors/vendor sets.
With the packing cost and the door-to-door freight charge determined, at step 160, the quoting engine 62 next determines the insurance premium for the shipment. At step 162, the quoting engine 62, as it did with the vendors' shipping rates, first determines whether the insurance vendors' rates are on file locally in a master insurance rate data table 86 (Fig. 1) and that they are current. If the insurance rates are on file locally and are current, the quoting engine 62 continues the process of determining the required insurance premium at step 166. If an insurance vendor's rate information is not on file locally or not current, the quoting engine 62 activates another data request, as denoted in step 164, to all of the affiliated insurance providers 88. Again, the example illustrated uses API calls to communicate to another system, but any data request and retrieval technology can be used with the invention described herein. The API call opens up a communication line with each insurance provider's database 90 and retrieves the necessary information. The retrieved information, similar to the information retrieved from the vendors' rate databases, is sent back to the comprehensive logistics service provider's server 60, in this example via an XML data stream format, and is parsed with the current insurance information stored to the appropriate fields on the master insurance rate data table 86. At step 166, the quoting engine 62 uses various shipment information, such as its origin and destination, the HTS code, the product size and weight, the product's value, to search each insurance vendor's look up table information stored on the master insurance rate data tables 86 to determine the lowest cost insurance premium for the requested shipment quote.
With the packing cost, the door-to-door freight charge and & insurance premium determined, at step 168, the quoting engine 62 determines all the duties and taxes that may be due on the shipment. At step 170, the quoting engine 62 uses various shipment information, such as its origin and destination, the product size and weight, the product's value, the HTS code, the product size and weight and the product's value to search the duty and tax look up tables resident on the master duty and tax rate data tables 92 to determine the duties and taxes for the^ requested shipment.
At step 172, the quoting engine 62 adds all of the determined and calculated components of the quote together to come up with a final quote to return to the requesting buyer 42. Specifically, the quoting engine 62 adds together the pre-shipment charges (e.g., packing costs), if any; the calculated door-to-door freight charge; the determined insurance premium and the calculated, duties and taxes. At step 174, the quoting engine 62 sends the final determined quote in an electronic data stream to the site host server 30 that requested the quote. A status message is also sent which states that a shipment quote was successfully generated. If insufficient or incorrect information was provided by the requester in the original request, the quoting engine 62 sends an enor message to the site host server 60 rather than a quote, as indicated in step 176. In the example described herein, these various messages are shown being sent in an
XML data stream. At step 178, the host's server 30 browser and software parses the quote response data stream and uses the shipment quote information from the quoting engine 62 to determine a total price (i.e., product price + shipment price) to display to the buyer 42 on his network access device 32.
The Booking Engine
Once the buyer 42 has received the product price quote, which includes the shipment quote, he can either do nothing or accept the quote by purchasing the product. If the buyer 42 purchases the product, this activates the process to book the shipment of the product as indicated in step 400 (Fig. 9A). The web site 34 activates a booking interface 93 from the site host server 30. At step 402, the booking interface 93 retrieves as much of the information it needs to book the shipment from the local data tables stored on the host site 22. The booking interface 93 generates a web page 36 for the buyer's review with the retrieved information inserted in the appropriate fields. At step 404, the buyer 42 verifies the retrieved information, correcting it where necessary, and approves it. Figs. 10A-B depict a sample web page 36 that a buyer 42 may see. The booking web page is very similar to a quote request web page, except that the booking web page requests more detailed information on the seller and the buyer. The additional information is needed because when a shipment is booked, the booking engine 64 also registers the seller and the buyer (e.g. , to verify that they are not on a domestic and/or international denied parties lists), as discussed in detail below. The customer ID 500 is usually a required field and is used as an identifier between the web site merchant and the comprehensive logistics service provider 20. The next thirteen fields 502-524 contain detailed information about the seller. The next twelve fields 526-548 after that contain detailed information about the buyer 42. The next field 550 contains a description of the item being shipped. The next field 554 is for the HTS code. When booking a shipment, this field must be completed. The buyer 42 can enter the HTS code directly if he remembers it or, as with the quote request web page, he can use the HTS Classifier by clicking on the HTS classifier icon 556. Once in the HTS classifier, the process of using it to determine the HTS code is the same as described above for a quote request. The next field is the piece type field 557. In the piece type field 557, the configuration of the item to be shipped is designated (e.g., package, pallet, container, loose). The piece type field 557 preferably uses a pull down menu. The next field is the service type field 559. In the service type field 559, the delivery manner is specified (e.g., air-parcel standard; ocean-parcel standard; 2-3 day service, via air; ocean container). The service type field 559 preferably uses a pull down menu as well. The next seven fields 558-569 contain information specific to the item being shipped and are the same entries required when requesting a quote. Once the buyer 42 has entered and verified all of the required information into the Online Booking screen, the buyer 42 clicks on the "Book" button 570 to book the shipment.
Referring again to Fig. 9A, in step 406, the clicking of the "Book" button 570 activates the booking interface 93 which gathers all of the shipment information submitted by the buyer 42 and formulates an electronic request containing all of the submitted shipment information. As noted earlier, any electronic data request and transmission technology can be used, usually dependant on the host site's business and technical requirements. In the example described herein, the information contained in the electronic booking request is formatted into an XML data stream as with the quote request (see Fig. 14 for an abbreviated sample of a booking request using XML). At step 408, the booking request is sent to and received by the booking engine 64 resident on the comprehensive logistics service provider's server 60. At step 410, the booking engine 64 parses out the data contained in the electronic booking request data stream and saves it into memory for use in booking the shipment.
Before booking the shipment, the booking engine 64, at step 412, runs a registration subroutine. The registration subroutine functions exactly like the registration engine 68. The registration subroutine and the registration engine 68 perform the necessary function of checking whether the parties to the transaction are on the U.S. State Department's denied party list, as indicated at step 414. Parties listed on the denied party list are not allowed to ship items in or out of the U.S. The registration subroutine and the registration engine 68 use the detailed information submitted about the parties to the shipment (the seller and the buyer information) to determine if a party to a shipment is a denied party by comparing the submitted seller and buyer information to data stored on a denied party data table 95 maintained and updated by the comprehensive logistics service provider 20. At step 416, if the registration subroutine or engine 68 detects that a party to a shipment is on the denied party list, the comprehensive logistics service provider 20 notifies the U.S. State Department. The parties to the shipment and the web site merchant are not notified. Similarly, verifications are performed against other limiting factors, such as an Embargoed Countries List.
The registration process may be performed separately from the booking process if the merchant wants to "register" user of its system prior to actually booking a shipment. To register a user 28, the merchant web site 34 requires the user 28 to complete a web page form requesting detailed information about the user 28. This web page form requests information similar to the detailed seller and buyer information requested by the booking screen (Fig. 10). Once the form is completed, the web site 34 triggers a registration interface 96 that formulates a URL request containing all of the user's information. In the example described herein, the regisfration request is sent as an XML data sfream to the registration engine 68 resident on the server 60 and read via an API call. The registration engine 68, like the other engines, parses the XML data stream and uses the information contained therein to verify the web site user 28 against various limits and/or exclusions (e.g., the denied the party data table 95, embargoed countries).
At step 418, the booking engine 64 runs a shipment cost subroutine to determine the current cost of the requested shipment. The shipment cost subroutine functions in exactly the same manner as the quoting engine 62 described above. At step 420, after the shipment quote subroutine has selected a shipment vendor set and determined a shipment cost, the booking engine 64 compares the current generated shipment cost with any quote that the system may have given the buyer 42 previously through the quoting engine 62. At step 421, if the cunent calculated shipment cost has changed from the cost that was previously quoted, the booking engine 64 notifies the buyer 42 of this change.
At step 422, the booking engine 64 creates a booking record and saves it to the master shipment data table 94. The booking engine 64 notifies the selected vendor of the shipment details, as indicated at step 424. This notification is preferably done by transmitting the shipment information in an XML data stream to the selected vendors 26 or to their affiliated integrator/specialized logistics service provider 24. However, any electronic messaging or data transmission technology, from XML or EDI to simple email, or even a manual phone call can be used for this step. The booking engine 64 also notifies the buyer 42 that the shipment is booked and provides the buyer with the shipment tracking number and the guaranteed landed cost price of the shipment, as indicated at step 426.
The Tracking Engine
After the shipment has been booked, the comprehensive logistics service provider 20 monitors and tracks all the shipments that are booked in its system. The vendors 26 responsible for the shipment provide cunent and updated shipment status information to the master shipment data tables 94 on a periodic basis. The vendor 26 can provide the status information to the comprehensive logistics service provider 20 in any manner feasible. The vendor 26 can provide it manually or preferably via an information network, for example through a web page via a browser or by sending an electronic data sfream such as EDI or XML directly from the vendor's shipment data tables 99 to the server 60 for parsing and storage on the master shipment data tables 94. If an integrator/specialized service provider 24 is involved, the data is electronically transmitted from the integrator/service provider's consolidated shipment data tables 98 directly to the master shipment data tables 94 on the comprehensive logistics service provider's server 60. The information can be provided to the master shipment data tables 94 directly from the shipment itself. If some form of tracking mechanism is employed in the shipment (e.g., an RF or GPS tag in the shipping container), the shipment status and location information can be sent directly from the shipment, via the network, to update the master shipment data tables 94 automatically on a fairly continuous or on at least a periodic basis.
Following is a description of an embodiment of a tracking system. Referring to Fig. 11, the container tracking system 710 of the embodiment, through a central tracking station 712, has the flexibility and capability to automatically track containers and their shipments worldwide, regardless of country, industry, carrier, owner or mode of transportation. It is flexible enough to allow for manual data collection using the same technology if any automated means become unavailable for reasons such as, but not limited to, maintenance, damage, or interference. The system of the present invention can automatically track containers and their shipments inter- and/or intra-modally, inter- and/or infra-industry and inter- and/or infra-carrier.
Referring to Fig. 12, containers 722 that are part of the system of the present invention are tagged with a tracking device 740. The different tracking devices 740 that may be used in the system of the present invention are described in detail below. Referring to Fig. 12 A, one embodiment of the container tracking system 710 of the present invention is depicted. The central tracking station 712 includes a container tracking server 714 which serves as the information hub and data storage device for all of the containers 722 in the system. The container tracking server 714 can be a single unit, or set or sets of coordinated servers and/or mainframe computers (not depicted). A communications link 742 is established between the container tracking server 714 and numerous station servers 716. The communications link 742 between the container fracking server 714 and the station servers 716 may be established in any manner suitable for that purpose, including the Internet, direct land lines, satellite, telecommunications or any other securable transmission and receiving method. The Internet because of its interconnectivity and established worldwide infrastructure of multi-hosted, multi-located web servers is the preferred communications method.
Referring to Fig. 13 A, each station server 716 is located at a container tracking site 718. The container tracking sites 718 may be any site or sites where the operator of the container fracking system 710 wants to collect data on a system container 722. These sites usually include, at a minimum, any place where a container changes possession among carriers, vendors, industries, or modes at areas such as airports, shipping ports, rail yards, truck docking areas and staging areas. Each station server 716 communicates with a single or numerous automated and/or manual tracking device readers 720. The tracking device readers 720 collect the information encoded on each container fracking device 740 when the tracking device 740 is read. The information collected on each container 722 by the readers 720 is communicated to each respective station server 716 which communicate all of the collected information to the main container tracking server 714 via the communication links 742.
In another embodiment of the tracking system, the data from the station servers 716 may be sent first to specific client servers instead of going directly to the container fracking server 714. The container tracking system operator then extracts the data it wishes to maintain on the main container tracking server 714 from these client servers. This way only the information that the fracking system operator designates as critical to the tracking system operator is maintained on the container fracking server 714, keeping valuable space on the container tracking server memory free. All of the other non-extracted, but more client-specific, client-proprietary information on the client's server remains on the client's server and is maintained by the client. In another embodiment of the present invention, the client's server and the container tracking server 714 receive information simultaneously from the station servers except that the container tracking server 714 only receives information the operator of the container tracking system has designated as critical for its fracking purposes. The information collected and stored on the central container tracking server 714 is made available to each client of the system. Each client can access the information on the container tracking server 714 at any time to find the location and status of one of their tracked containers. An interested client may access the container fracking server 714 by an extranet 730 set up with the tracking system operator. The extranet 730 is a direct link between a server 726 at the client's site 728 and a web server 732 located at the central tracking station 712. The extranet can be designed using direct land lines, satellite, telecommunications, the Internet, or any other securable transmission and receiving method. The web server 732 communicates with the container tracking server 714 making the stored container information available to the inquiring client. The client may also access the central fracking station web server 732 through the Internet 734. A firewall 736 is in place to separate the client extranet portion 730 of the web server 732 from the Internet portion 734 of the system so that certain information sensitive to specific clients is restricted from general Internet accessibility.
In the embodiments, as described above, where client servers, in addition to the container tracking server 714, are also involved in the data collection and storage process, clients may access the client servers in addition to accessing the container fracking server 714 to retrieve information. In one embodiment, the client servers are the client's primary information retrieval resource when the container 722 is within the client's tracking and monitoring network because the client servers collect and maintain more detailed, client specific information than the more general information stored on the container tracking server 714. However, when these same containers 722 leave the client's tracking and monitoring network, the client can still track and monitor these same containers 722 through the global information available on the container tracking server 714.
Referring to Fig. 13B, an embodiment of the container tracking system 710 is depicted. In this embodiment, the containers 722 are tracked using satellite-based, global positioning system (GPS). In this embodiment, the container tracking devices 740 attached to each container communicate directly with the container tracking server 714 through the satellites 738 of the GPS. As such, the container tracking system 710 of the present invention has the capability to pinpoint the exact location of every container 722 anywhere in the world at any time. As with the embodiment described above, each client can access the information on the container tracking server 714 or on a client server at any time to find out the location and status of one of its containers.
In the following sections, further details are provided for container fracking devices, container monitoring devices, a container tracking server and client accessible information, aspects of which are part of the embodiment of the tracking engine.
Container Tracking Devices
Depending on the type of system employed, the fracking device 740 may be a passive or active GPS tracking chip, a passive or active radio frequency identification (RFID) tag, a combination of both RFID and GPS or, it is foreseen, any form of remote tracking tag technology developed. If combined chips are used, means of programming and reading the chips may be slightly different based on the technologies used, but the data tracked and collected will be the same. Additionally, in any combined-chip embodiment, additional means for turning each chip on and off are included in these designs.
The tracking device 740 is either pre-programmed prior to attachment to the container 722 or it is programmed immediately after attachment to the container 722. The tracking devices 740 of the present invention are programmed with unique container identification information which is permanently locked into the memory of the tracking device 740. The operator of the container tracking system 712 establishes the unique code to be programmed into each container tracking device 740. The unique container identifier information programmed into the tracking device 740 contains, at a minimum, container specification information, container ownership information and a specific alphanumeric container identifier. An example of such a code is AKE3123FX where "FX" identifies the owner of the container, "AKE" specifies the type of container based on standard industry designators and "3123" is a unique alphanumeric value assigned to that specific container by the operator of the container tracking system. The permanent code programmed into the tracking device 740 is also stored on the container tracking server 714 at the central fracking station 712. Once a container 722 is tagged and coded, the system of the present invention can track it. In one embodiment, a powered GPS fracking chip is used to allow for uninterrupted, real-time, global fracking of each container. Each powered GPS tracking chip sends the information for the container it is affixed to through the satellite system to the container tracking server 714. In another embodiment of the container tracking system 710 of the present invention, a passive GPS tracking chip is used. In this embodiment, the passive GPS tracking chip receives a signal from the satellite system and, based on this signal, constantly stores and updates the location of the container 722 it is affixed to on the chip. This is known as passive positioning. This internally stored container location information is then retrieved in several ways by a GPS chip reader which sends this retrieved information to the container tracking server 714. The passive GPS chip information may be retrieved by periodic timed bursts, at preset way points, at preset destination points or via any other programmed data transmission trigger.
In another embodiment, the fracking device 740 may be an RFID tag. The RFID tag may be supplied by any number of commercial suppliers. One such supplier is Intermec Technologies Corporation which supplies an RFID tag identified by the trade-mark Ihtellitag. Intermec, as well as other suppliers, supply both passive and active RFID tags. Active RFID tags transmit a signal for retrieval by a data collection device. Passive RFID tags reflect or backscatter an RF transmission sent from the data collector back to the data collection device. In various embodiments, the RFID tracking devices 740 may be read, may be written to, may be rewritten to or may have individual bytes programmed and permanently locked. The use of automated tracking devices 740, such as GPS and RFID, in the system, the embodiment eliminates the need for manual container tracking, and no personnel are required to intercept, interpret or optically scan containers 722 within the system of the invention. However, the system 710 of the present invention is flexible enough and has the capability to adjust for real world situations where the automated systems of the present invention might go down.
The system 710 of the present invention has the capability to manually track the containers 722 within the system, through manual GPS, manual RFLD, optical scanning or even manual data entry, if necessary. For example, standard bar code technology, employing either a one or two dimensional bar-code symbology, may be used on the container fracking devices 740 as a back-up system.
Container Monitoring Site
In the RF embodiment, the system containers are tracked when they pass by RFID readers. These readers are preferably fixed, either geographically or permanently affixed to container fransports (e.g., ships, trucks, conveyors, cranes, tractors, etc.), but may be portable (hand-held). In the GPS system embodiment, the capability exists to track the system at any time, at any location in the world. The only present limitations on using a GPS system, as opposed to an RF system, are mostly non-technical restraints such as government regulations (U.S. or foreign) on the use of GPS in certain situations (e.g., the FAA presently does not allow the use of external GPS while in flight). Referring to Fig. 14, an example container tracking area 750 is depicted. The depicted container fracking area 750 is an airport, but it should be clear from the description of the present invention that the container fracking area could be any area where the operator of the container tracking system 710 desires to track container 722 movement, such as a port, a truck staging area, a warehouse, etc. An airport is only described by way of a single example. The container tracking area 750 of Fig. 14 has container monitoring sites 752 at several locations throughout the container tracking area 750. There is a container monitoring site 752 at the point where containers 722 are passed into the terminal baggage area 754. There is a container monitoring site 752 where the baggage is loaded onto the plane 756, and there is a container monitoring site 752 at the cargo staging area 758.
The hardware to collect information at each container monitoring site 752 is essentially the same. As such, the container information collection process at the cargo staging area 758 is described herein as exemplary of the container information collection process at all the container monitoring sites 752.
In this example, the cargo staging area 758 is set up to track containers 722 anywhere within the boundaries of the cargo staging area 758. The cargo staging area 758 has fixed data collectors 760 at each access point to the cargo staging area 758. These fixed data collectors 760 in this example are RFID tracking device readers. These RFID data collectors 760 operate by constantly sending out an RF signal and when an RFID tracking device 740 passes within this fransmitted signal, the RFID tracking device 740 reflects or backscatters this RF signal back to the RFID data collector 760. From this reflected signal, the RFID data collector 760 collects all of the container's programmed information. Presently, several suppliers can provide RFID data collectors, including intermec Technologies Corporation which sells several types of data collectors, both portable and fixed.
As depicted in Fig. 14, as a container 722 passes by the fixed RFID data collectors 760 at the gates to the cargo staging area 758, the RFID data collectors 760 read the tracking devices 740 of the containers 722 on the truck. The RFID data collectors 760 relay this information to a monitoring site RF antenna 762. The monitoring site RF antenna 762 downloads this information to a station server 716 which in turn transmits this information to the master data files on the container tracking server 714 at the central tracking station 712. The fixed RFID data collectors 760 may also be programmed to collect additional and more specific information. For example, the fixed RFID data collectors 760 on one side of the access gate can be programmed to detect inbound traffic and the RFID data collectors 760 on the other side of the gate can be programmed to detect outbound fraffic. In addition to fixed RFID data collectors 760, the monitoring site 752 may also use portable RFID data collectors 764 carried by site monitoring personnel, if the fixed RFID readers become temporarily unavailable. These portable RFID readers could also be used to spotcheck a container or update its status by the site monitoring personnel reading the RFID tracking device 740 of the container 722 of interest with the portable RFID data collectors 764. The portable RFID data collectors 764 work in the same way as the fixed RFJD data collectors 760. The data collected from the containers 722 by the portable RFID data collectors 764 is sent to the station server 716 via the antenna 762 in the same manner as the fixed data collectors 760 transmit data to the station server 716. Since the monitoring site antennas 762 only have a set range, the portable RFID data collectors 764 are equipped to batch or store the read container information temporarily if they are outside the range of the antenna 762, and once the portable RFID data collector 764 comes back into range of the antenna 762, the portable data collector 764 uploads all of the batched container information to the station server 716 in the same manner as described above.
The portable RFID data collectors 764 may also be used to write information to the memory of the fracking device 740. The types of information that may be written to the fracking device memory and ultimately collected is limitless. Nevertheless, some of the additional container information besides the name of the container owner and the container specifications that the tracking system operator may want includes information on the container's itinerary, information on the name of the organization that is currently in possession of the container, notification as to whether the container has ever carried any dangerous or hazardous goods, among other things.
Container Tracking Server
As described above, as tracking devices 740 of the containers 722 of the present system 710 are read by data collectors 760, 764 all over the world, this information is fransmitted to the container tracking server 714, and if applicable to a client server, where it is stored and maintained.
Referring to Fig. 15, the container fracking server 714 maintains a number of datatables. The datatables depicted here are merely exemplary of some tables that a tracking system operator might desire to maintain. The actual datatables maintained on the container tracking server 714 depends on the information that the system operator wants to maintain. The datatables on the container tracking server 714 may include a container information datatable 800, a client company datatable 802, a data collection device datatable 804, a monitoring site datatable 806, a optional monitoring personnel datatable 808 and a shipment specific datatable 810. The container information datatable 800 may include specific information about the container including the container's fracking device code, and the container's specifications, among other data items. The client company datatable 802 contains information on clients that are participants in the container tracking system 710. The data collection device datatable 804 includes information on all of the data collection devices that are part of the container tracking system 710. The monitoring site datatable 806 contains specific information on the worldwide monitoring sites, such as specific airport or dock configuration information. The monitoring personnel datatable 808 contains information on all the personnel that can monitor, collect, and/or update data from the system's containers. The shipment specific datatables 810 may actually be a number of datatables. These datatables contain information on specific shipments using a system container. Information on the specific articles being shipped in a specific container, information on how the shipment is being broken down between containers, master air bill or ocean bill of lading information, specific mode of fransport information (e.g., flight number, truck number) are all stored in these datatables.
Client Accessible Information
As described above, the client can access the container tracking server 714 by either the Internet or client specific extranet. Refe ing to Figs. 16-20, sample client user screens are depicted for an assumed client airport.
In Figs. 16A and 16B, sample screens are depicted showing container summary information. Fig. 16A shows the container status, where containers are refened to as LED's (Unit Load Devices), of all the containers at a particular client site, in this case an airport. Fig. 16B shows the status of all the containers for a particular client. Thirteen are inbound, sixteen are cargo containers, ten are mail containers and ten are baggage containers.
Fig. 17A shows how a user can change locations to check the status of containers at other sites. Fig. 17B provides a listing of all the inbound flights for a particular client and a listing of all the containers, broken down by content, on those inbound flights.
Fig. 18 shows a screen displaying dynamic staging data so that the client can track a container through all facets of their staging and loading operation.
Fig. 19 illustrates a screen where the client has performed a historical search on a particular container. To do this, the client enters the container number into the search area and executes the search. The container tracking server 714 returns a historical container activity list for the searched container.
Fig. 20 depicts a screen where the client is monitoring a specific load plan. To do this, the client enters a specific transport identifier number, such as a flight number. The search will query the container tracking server 714 for this transport identifier and return the load plan for this transport identification number. The above described screens are merely a representative sample of all the screens that can be generated for use with this system. Any information that is stored on the container tracking server 714 or any combination of such information can be manipulated to make any screen that is considered worthwhile. For example, it is possible with the right data feeds from the Federal Aviation Administration (FAA) that the exact real-time location of every flight, not just projected arrival times, can be displayed on these screens for the client's information as well. It is also possible to use the container positioning information and geographical mapping software to graphically depict where a client's container is actually located.
The tracking system of the embodiment can also help clients in managing demmrage. It can help clients determine how much a company bonowing a client's container owes the client for bonowing such container. With this system, the client can know exactly how long and for what purposes the company bonowed the container. It also helps the client to track down what in the past would have been lost containers. With this system, it is conceivable that a container would never be lost again. The tracking system of the embodiment also provides advanced warning of any shipment problems or delays. If while monitoring the shipment, the comprehensive logistics service provider 20 notices a problem or delay, the comprehensive service provider 20 can attempt to remedy the problem immediately and can provide the buyer 42, or any system user 28, pre-notification of the problem so they can re-act accordingly before the problem or delay becomes unconectable.
Further detail is provided on the use of an embodiment of the tracking system is provided below.
Refe ing to Figs. 21A-21B and 22, a system user 28 can track the status of its shipment at any time. At step 600, the user 28 accesses the web page 36 of the merchant that sold the item or that handled the auction, or the web page of the comprehensive service provider 20 and enters the shipment tracking number at the appropriate place on the web page 36. The web page 36 may also allow the user 28 to search for the tracking number if the user 28 does not have it. At step 602, when the user 28 enters the tracking number, the web site 34 activates the tracking interface 97 which formulates an electronic tracking request data stream containing the tracking number. At step 604, the tracking request is sent to the tracking engine 66 resident on the comprehensive logistics services provider's server 60. At step 606, the tracking engine parses out the tracking number from the data stream.
At step 608, the tracking engine 66 determines whether the tracking information on file in the master shipment data tables 94 for the requested tracking number is cunent. If it is not, at step 610, the tracking engine 66 requests a data update from the databases of the vendors 26 or the integrators/specialized service providers 24 handling the shipment. In the example described herein, this request is performed via an API call, but any data retrieval and transmission technology can be used. At step 612, the shipment status information retrieved from the vendors' databases 99 is sent back to the comprehensive logistics service provider's server 60, for example, in an XML data stream format. When received, the status data from the data streams are . parsed out and stored to the master shipment data tables 94. The tracking engine 66 takes the updated status data and sends to the site host 22 as a data stream where the site host 22 re-formulates the data and presents the data on the web page 36. Refening to Fig. 12, a sample tracking status web page 36 is illustrated. The status web page shows that delivery of the shipment is complete and shows the date and time certain key shipping events happened.
It will be appreciated that the tracking system as described herein may be implemented as a separate system, apart from other aspects of the embodiment described herein.
While the present invention has been described with certain particularity, it is not meant to be limited to the above described embodiment. Many modifications will be obvious to those skilled in the art. Therefore, the present invention will encompass the above described embodiment as well as any modifications which will fall within the scope of the appended claims. Any element in a claim that does not explicitly state "means for" performing a specified function, or "step for" performing a specific function, is not to be inteφreted as a "means" or "step" clause as specified in 35 U.S.C. §1 12, Tf6. In particular, any use of "step of in the claims herein is not intended to invoke 35 U.S.C. §112, |6.

Claims

CLAIMSWhat is claimed is:
1. A system for providing logistics services comprising: a server storing a shipment booking engine program; input data in communication with the server; vendor rate data in communication with the server; shipment insurance rate data in communication with the server; shipment duty and tax rate data in communication with the server; shipment datatables in communication with the server; an interconnected data network; a site host system in operative communication with the server; a network access device connected to the data network; a tracking engine program stored on the server; and shipment tracking number data in communication with the server; wherein when the shipment tracking engine program is activated, the shipment tracking number is input into the shipment tracking engine program and the shipment tracking engine program retrieves all of the infonnation relating to the input tracking number from the shipment datatables.
2. The logistics service system of claim 1, further comprising: an interconnected data network: a site host system in operative communication with the server wherein the site host system activates the shipment tracking engine program and provides the shipment tracking number data to the tracking engine program.
3. The logistics service system of claim 2, wherein at least one of the input data, the vendor rate data, the shipment insurance rate data, the shipment duly and tax rate data, the shipment datatable information and the shipment tracking number data is communicated to the server using electronic data transmission technology.
4. The logistics service system of claim 3, wherein the electronic data transmission technology used is extensible markup language (XML).
5. A method for providing logistics services comprising: ' providing a landed cost quoting engine program; providing input data; providing vendor rate data; providing shipment insurance rate data; providing shipment duty and tax rate data; activating the landed cost quoting engine program to calculate a vendor neutral landed cost quote using the inpuf'data, the vendor rate data, the shipment insurance rate data and the duty and tax rate data; providing a shipment booking engine program; providing shipment datatables; activating the shipment booking engine program to generate a shipment booking; providing a tracking engine program; providing shipment tracking number data; and activating the tracking engine program to use the provided shipment tracking number data to retrieve all of the information relating to the input tracking number from the shipment datatables.
6. The logistics service provision method of claim 5, further comprising: providing a registration engine program; providing system user data; providing denied party data; and activating the registration engine program to determine whether the provided system user data matches the provided denied party data and generating a denied user response if the specific system user data matches the denied party data.
7. The logistics service provision method of claim 6, wherein at least one of the steps of providing input data, providing vendor rate data, providing shipment insurance rate data, providing shipment duty and tax rate data, providing shipment datatable information, providing shipment tracking number data, providing system user data and providing denied party data is provided using electronic data transmission technology.
8. The logistics service provision method of claim 7, wherein the electronic data transmission technology used is extensible markup language (XML).
9. The logistics service provision method of claim 8, wherein the step of providing input data includes determining a Harmonization Tariff System (HTS) code.
10. A system for providing tracking services comprising: a server; input data in communication with the server; shipment datatables in communication with the server; an interconnected data network; a site host system in operative communication with the server; a network access device connected to the data network; a tracking engine program stored on the server; and shipment tracking number data in communication with the server; wherein when the tracking engine program is activated, the shipment tracking number is input into the tracking engine program and the tracking engine program retrieves information' relating to the input tracking number from the shipment datatables.
11. A system for providing tracking services as in claim 10, said system further comprising: an interconnected data network; and a site host system in operative communication with the server wherein the site host system activates the shipment tracking engine program and provides the shipment tracking number data to the tracking engine program.
PCT/US2001/002479 2000-01-28 2001-01-26 System and method for providing comprehensive logistics services WO2001055931A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001231144A AU2001231144A1 (en) 2000-01-28 2001-01-26 System and method for providing comprehensive logistics services

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US17884900P 2000-01-28 2000-01-28
US60/178,849 2000-01-28
US58709900A 2000-06-02 2000-06-02
US09/587,099 2000-06-02

Publications (1)

Publication Number Publication Date
WO2001055931A1 true WO2001055931A1 (en) 2001-08-02

Family

ID=26874737

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/002479 WO2001055931A1 (en) 2000-01-28 2001-01-26 System and method for providing comprehensive logistics services

Country Status (2)

Country Link
AU (1) AU2001231144A1 (en)
WO (1) WO2001055931A1 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1485775A2 (en) * 2002-02-21 2004-12-15 Promega Corporation Rf point of sale and delivery method and system using communication with remote computer and having features to read a large number of rf tags
US6922720B2 (en) 1999-09-10 2005-07-26 Portogo, Inc. Systems and methods for insuring data over the internet
EP1564648A2 (en) * 2004-02-14 2005-08-17 Universitätsklinikum Düsseldorf Anstalt des öffentlichen Rechts Method for monitoring laboratory samples
US7333942B1 (en) * 1999-03-26 2008-02-19 D-Net Corporation Networked international system for organizational electronic commerce
EP1998473A1 (en) * 2006-02-20 2008-12-03 Kabushiki Kaisha Kobe Seiko Sho (Kobe Steel, Ltd.) Information synchronization system
US7602296B2 (en) 2006-06-02 2009-10-13 Ulibarri Giovanni M System and method for transport security control and tracking
US7711646B2 (en) 1999-09-10 2010-05-04 Transurety, Llc Methods and apparatus for providing coverage for receiver of transmission data
US7735732B2 (en) 2000-10-20 2010-06-15 Promega Corporation Radio frequency identification method and system of distributing products
WO2011054712A1 (en) * 2009-11-06 2011-05-12 Deutsche Post Ag Method and system for initiating a courier transport
WO2011054710A1 (en) * 2009-11-06 2011-05-12 Deutsche Post Ag Method and system for courier task announcement
WO2014146169A1 (en) * 2013-03-19 2014-09-25 Tushare Australia Pty Ltd Systems and methods for managing sending of items
USRE47599E1 (en) 2000-10-20 2019-09-10 Promega Corporation RF point of sale and delivery method and system using communication with remote computer and having features to read a large number of RF tags

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5253165A (en) * 1989-12-18 1993-10-12 Eduardo Leiseca Computerized reservations and scheduling system
US5835716A (en) * 1995-12-15 1998-11-10 Pitney Bowes Inc. Method and system for brokering excess carrier capacity

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5253165A (en) * 1989-12-18 1993-10-12 Eduardo Leiseca Computerized reservations and scheduling system
US5835716A (en) * 1995-12-15 1998-11-10 Pitney Bowes Inc. Method and system for brokering excess carrier capacity

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
ADAMS ERIC J.: "Trace it or track it", WORLD TRADE, vol. 10, no. 6, June 1997 (1997-06-01), pages 40 - 41, XP002939463 *
AMERICAN SHIPPER, vol. 37, no. 4, April 1995 (1995-04-01), pages 64 *
CASSIDY ET AL.: "Rites of passage", TRAFFIC WORLD, vol. 260, no. 8, 22 November 1999 (1999-11-22), pages 40, XP002939465 *
DATABASE IAC TRADE & INDUSTRY [online] BONNEY JOSEPH: "Encompass, version 1.5", XP002939466, retrieved from 07826433 accession no. Dialog Database accession no. 17000430 *
DATABASE WORLD REPORTER [online] FITZPATRICK MICHELLE: "Logistics of transport may be E-commerce's greatest obstacle", XP002939467, accession no. Dialog Database accession no. 8915452 *
GUDMUNDSSON ET AL.: "The development of electronic markets in logistics", INTERNATIONAL JOURNAL OF LIGISTICS MANAGEMENT, vol. 10, no. 2, 1999, pages 99 - 113, XP002939464 *
KRTBN KNIGHT-RIDDER TRIBUNE BUSINESS NEWS, 28 December 1999 (1999-12-28), pages 5 PAGES *

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7333942B1 (en) * 1999-03-26 2008-02-19 D-Net Corporation Networked international system for organizational electronic commerce
US7555535B2 (en) 1999-09-10 2009-06-30 Transurety, Llc Methods and apparatus for securing and providing coverage for transmission data
US6922720B2 (en) 1999-09-10 2005-07-26 Portogo, Inc. Systems and methods for insuring data over the internet
US10235717B2 (en) 1999-09-10 2019-03-19 Transurety, Llc Coverage for transmission of data apparatus and method
US7020692B2 (en) 1999-09-10 2006-03-28 Portogo, Inc. Systems and methods for insuring data transmissions
US8660962B2 (en) 1999-09-10 2014-02-25 Transurety, Llc Method and apparatus for providing coverage for transmission of data
US7908340B2 (en) 1999-09-10 2011-03-15 Transurety, Llc Methods and apparatus for providing coverage for sender of transmission data
US7246157B2 (en) 1999-09-10 2007-07-17 Transurety, Llc Systems and methods for underwriting coverage for data transmissions
US7711646B2 (en) 1999-09-10 2010-05-04 Transurety, Llc Methods and apparatus for providing coverage for receiver of transmission data
US7349954B2 (en) 1999-09-10 2008-03-25 Transurety, Llc Systems and methods for reports based on transmission-failure claims
US7735732B2 (en) 2000-10-20 2010-06-15 Promega Corporation Radio frequency identification method and system of distributing products
US7942321B2 (en) 2000-10-20 2011-05-17 Promega Corporation Radio frequency identification method and system of disturbing products
USRE47599E1 (en) 2000-10-20 2019-09-10 Promega Corporation RF point of sale and delivery method and system using communication with remote computer and having features to read a large number of RF tags
USRE46326E1 (en) 2000-10-20 2017-02-28 Promega Corporation RF point of sale and delivery method and system using communication with remote computer and having features to read a large number of RF tags
US7661591B2 (en) 2000-10-20 2010-02-16 Promega Corporation RF point of sale and delivery method and system using communication with remote computer and having features to read a large number of RF tags
US8025228B2 (en) 2000-10-20 2011-09-27 Promega Corporation RF point of sale and delivery method and system using communication with remote computer and having features to read a large number of RF tags
US7967199B2 (en) 2000-10-20 2011-06-28 Promega Corporation Radio frequency identification method and system of distributing products
US7784689B2 (en) 2000-10-20 2010-08-31 Promega Corporation Radio frequency identification method and system of distributing products
US7791479B2 (en) 2000-10-20 2010-09-07 Promega Corporation RFID point of sale and delivery method and system
EP1485775A2 (en) * 2002-02-21 2004-12-15 Promega Corporation Rf point of sale and delivery method and system using communication with remote computer and having features to read a large number of rf tags
KR100766679B1 (en) * 2002-02-21 2007-10-15 프로메가 코포레이션 Rf point of sale and delivery method and system using communication with remote computer and having features to read a large number of rf tags
KR100850602B1 (en) 2002-02-21 2008-08-05 프로메가 코포레이션 Method and apparatus for scanning rfid
EP1485775A4 (en) * 2002-02-21 2006-08-16 Promega Corp Rf point of sale and delivery method and system using communication with remote computer and having features to read a large number of rf tags
EP1564648A2 (en) * 2004-02-14 2005-08-17 Universitätsklinikum Düsseldorf Anstalt des öffentlichen Rechts Method for monitoring laboratory samples
EP1564648A3 (en) * 2004-02-14 2006-05-24 Universitätsklinikum Düsseldorf Anstalt des öffentlichen Rechts Method for monitoring laboratory samples
EP1998473A1 (en) * 2006-02-20 2008-12-03 Kabushiki Kaisha Kobe Seiko Sho (Kobe Steel, Ltd.) Information synchronization system
EP1998473A4 (en) * 2006-02-20 2011-03-23 Kobe Steel Ltd Information synchronization system
US7602296B2 (en) 2006-06-02 2009-10-13 Ulibarri Giovanni M System and method for transport security control and tracking
EP2325785A1 (en) * 2009-11-06 2011-05-25 Deutsche Post AG Method and system for courier task announcement
EP2325787A1 (en) * 2009-11-06 2011-05-25 Deutsche Post AG Method and system for initiating a courier transport
WO2011054710A1 (en) * 2009-11-06 2011-05-12 Deutsche Post Ag Method and system for courier task announcement
WO2011054712A1 (en) * 2009-11-06 2011-05-12 Deutsche Post Ag Method and system for initiating a courier transport
WO2014146169A1 (en) * 2013-03-19 2014-09-25 Tushare Australia Pty Ltd Systems and methods for managing sending of items

Also Published As

Publication number Publication date
AU2001231144A1 (en) 2001-08-07

Similar Documents

Publication Publication Date Title
US20170316293A1 (en) System and method for arranging shipment and insurance for an item
KR100975610B1 (en) Common carrier system
US7895092B2 (en) Systems and methods for integrated global shipping and visibility
US6988079B1 (en) System and method for amalgamating multiple shipping companies using reusable containers and wide area networks
US7667604B2 (en) Context-aware and real-time item tracking system architecture and scenarios
WO2001055931A1 (en) System and method for providing comprehensive logistics services
Kalakota et al. Mobile applications for adaptive supply chains: A landscape analysis
KR20010064668A (en) Electronic commercial transaction method and apparatus for foreign visitor
KR20010102869A (en) cellular phone ( - a course of transportation - ) information service system for carriage transportation
Jakobs et al. An Integrated Approach Towards Next Generation Tracking & Tracing
Li et al. A Research on Application of Mobile Commerce in Logistics Industry
JP2002032615A (en) Transport mediation method
WO2003017163A1 (en) System for facilitating transactions between freight customers and service providers
WO2001073592A2 (en) System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller
MXPA06007653A (en) Integrated global tracking and virtual inventory system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ 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 UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG 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 GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

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 1205 DATED 21/03/03 )

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

Ref country code: JP