EP1642654B1 - Procédé et système pour pré-charger d'un colis selon un plan de livraison - Google Patents

Procédé et système pour pré-charger d'un colis selon un plan de livraison Download PDF

Info

Publication number
EP1642654B1
EP1642654B1 EP05024191A EP05024191A EP1642654B1 EP 1642654 B1 EP1642654 B1 EP 1642654B1 EP 05024191 A EP05024191 A EP 05024191A EP 05024191 A EP05024191 A EP 05024191A EP 1642654 B1 EP1642654 B1 EP 1642654B1
Authority
EP
European Patent Office
Prior art keywords
package
destination address
load
label
delivery
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Lifetime
Application number
EP05024191A
Other languages
German (de)
English (en)
Other versions
EP1642654A3 (fr
EP1642654A2 (fr
Inventor
Juan R. Perez
Duane Anderson
David Potteiger
Michael Burgess
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
United Parcel Service of America Inc
United Parcel Service Inc
Original Assignee
United Parcel Service of America Inc
United Parcel Service 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 United Parcel Service of America Inc, United Parcel Service Inc filed Critical United Parcel Service of America Inc
Priority claimed from EP01986528A external-priority patent/EP1385640B1/fr
Publication of EP1642654A2 publication Critical patent/EP1642654A2/fr
Publication of EP1642654A3 publication Critical patent/EP1642654A3/fr
Application granted granted Critical
Publication of EP1642654B1 publication Critical patent/EP1642654B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B07SEPARATING SOLIDS FROM SOLIDS; SORTING
    • B07CPOSTAL SORTING; SORTING INDIVIDUAL ARTICLES, OR BULK MATERIAL FIT TO BE SORTED PIECE-MEAL, e.g. BY PICKING
    • B07C3/00Sorting according to destination
    • B07C3/18Devices or arrangements for indicating destination, e.g. by code marks
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B07SEPARATING SOLIDS FROM SOLIDS; SORTING
    • B07CPOSTAL SORTING; SORTING INDIVIDUAL ARTICLES, OR BULK MATERIAL FIT TO BE SORTED PIECE-MEAL, e.g. BY PICKING
    • B07C7/00Sorting by hand only e.g. of mail
    • B07C7/005Computer assisted manual sorting, e.g. for mail

Definitions

  • the present invention relates to a method of and a system for performing a package preload in accordance with a dispatch plan to capture, store and print package level detail in a machine-readable format to allow automation of the pre-load sortation process of a parcel delivery service.
  • Pre-load sortation is a process in which carrier pre-loaders load packages onto delivery vehicles for delivery to the ultimate destination.
  • a carrier destination facility generally has a plurality of package cars that are pre-loaded simultaneously and each package car has a variety of potential load positions.
  • Pre-loaders have the responsibility of ensuring that the packages are loaded on the correct shelf of the correct package car and, to date, this process has been manual.
  • Pre-loaders physically examine the destination address on the package label and determine from memory or from written pre-load charts, which package truck delivers to that address and which shelf on the truck holds the packages for that address. This is a complex task and requires that pre-loaders receive extensive training on how to properly load packages.
  • the manual intensiveness of this pre-load process causes errors in pre-loads and increased training costs. In today's environment with high turnover rates, the increased training time negatively impacts the ability to create and sustain a workforce capable of providing quality loads.
  • Dispatch plans are integrally related to the pre-load process.
  • a dispatch plan is the schedule or route through which a carrier assigns work to carrier service providers (such as package car drivers) to efficiently coordinate and schedule the pickup and delivery of packages.
  • Dispatch plans are well known in the carrier industry and are used daily by commercial carriers to manage driver delivery routes.
  • Dispatch plans are also integrally tied to the pre-load process as a pre-load depends in large part on the dispatch plan assigned to the delivery vehicles that are loaded. Because pre-load handling instructions are based upon a dispatch plan, significant changes to a dispatch plan often resulted in changes to the pre-load process. Because the pre-load processes known in the art are knowledge-based, a carrier is limited on how often it can change a dispatch plan without disrupting the pre-load process. This inflexibility in dispatch planning results in inefficient delivery routes and untimely deliveries.
  • the presentation needs to be sufficiently simple to understand that an inexperienced pre-loader can correctly perform a pre-load.
  • a pre-load system configured to provide handling and pre-load instructions for a package necessarily requires the package destination address information to generate the handling instructions.
  • US-A-5292004 discloses a process for addressing a message or item to a recipient, the process including allocating an identifier and a locator.
  • the identifier comprises a code for geographical location and recipients telephone number.
  • the locator comprises co-ordinates defining a geographical zone.
  • DE-A-4412097 discloses a parcel distribution system in which parcels are grouped as delivery-round assemblies in a container adapted for unit load on a vehicle with other such containers. Each container has shelves to permit parcels to be placed in the correct order.
  • US-A-4832204 discloses a package handling and sorting system reliant upon scanning electronically readable labels. The system generates an electronic trail of package movements, thus providing a capability to trace packages lost in transit.
  • the present invention provides systems and methods for electronically-capturing a destination address of a package and for using the destination address to automate a package pre-load operation.
  • a method of performing a package preload in accordance with a dispatch plan said package having a shipping label that includes a destination address, and said dispatch plan including an allocation of work for a specified geographical area between a plurality of delivery vehicles, wherein each of said delivery vehicles is assigned responsibility for a pickup and delivery area within said geographical area and each of said delivery vehicles includes a plurality of package load positions, said package preload method including the steps of:
  • a system for performing a package pre-load in accordance with a dispatch plan said package having a shipping label that includes a destination address, and said dispatch plan including an allocation of work of a specified geographical area between a plurality of delivery vehicles, wherein each of said delivery vehicles is assigned responsibility for a pickup and delivery area within said geographical area and each of said delivery vehicles includes a plurality of package load positions, said system comprising:
  • a MaxiCode is a two-dimensional symbology that encodes roughly 100 characters of data in an area of one square inch. MaxiCodes are well-known in the art and have been the subject of several patents, among them U.S. Patent Nos. 5,610,995 to Zheng et al. and 6,149,059 to Ackley. In 1996, the American National Standards Institute (ANSI) recommended MaxiCode as the most appropriate vehicle for sorting and tracking transport packages and carriers such as the United Parcel Service (UPS) use MaxiCodes on shipping labels to encrypted basic billing and shipping information. To date, however, the storage capacity of the MaxiCode label has restricted encoding to basic top-level shipping information such as city, state and zip.
  • ANSI American National Standards Institute
  • UPS United Parcel Service
  • Fig. 1 is a high-level flowchart that shows the process for MaxiCode compression and decompression in accordance with an embodiment of the present invention.
  • a user program 110 captures label information and formats the label information as an ANSI-compliant interface string ("interface string").
  • interface string an ANSI-compliant interface string
  • ANSI-compliant means that the interface string matches the ANSI format described in the ANSI specification MH10.8.3M-1996; however, one of ordinary skill in the art will readily recognize that the present invention is not limited to this specification.
  • the ANSI specification is inclusive where pertinent as to the content and/or encoding for each field and describes a sentence structure for the data. Elements of the sentence include messages and formats.
  • a message contains two formats; and messages and formats use headers and trailers to identify where they begin and end, and to identify their type.
  • ANSI-compliant interface strings input to the compressor
  • ANSI-compliant label strings output from the compressor
  • formats '01' and '05' carry predominantly printable ASCII data (32 to 127 decimal, excluding '*' (42 decimal)), while format '07' is restricted to the following 55 different symbols: ( ⁇ CR>, 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', ⁇ Fs>, ⁇ Gs>,',', '''', '#', '$', '%', '&', ''', '(', ')', '*', '
  • Fig. 2 shows a data specification for an interface string.
  • Data elements are placed in a prioritized sequence so that lower priority data elements are more likely to be impacted in the event that data truncation occurs in the compression or label generation processes that follow.
  • the data specification shown in Fig. 2 allocates five fields to store shipping destination address information; these fields are "ship to address line 1" through "ship to address line 5.” If more information is stored in the destination address fields than can be represented by a MaxiCode, the address is truncated. In a preferred embodiment, no truncation occurs until the '07' format of an ANSI-compliant label string is populated with at least 45 symbols. Because the symbols are post compression, the number of ANSII characters incorporated in the interface string prior to truncation can vary.
  • no fields are explicitly protected from truncation as any field destined to reside in the '07' format (compressed area) is susceptible to truncation.
  • the most critical shipping information is rarely truncated.
  • the user program 110 is configured to store the most important destination address data in those fields that are least susceptible to truncation. Table 1 illustrates a compression priority order for data fields .
  • Fig 3A shows an exemplary destination address as it might appear on a shipping label.
  • Fig. 3B shows the same destination information reformatted by the user program 110 as an uncompressed interface string according to the data specification requirements shown in Fig. 2 . If the compression priority order shown in Table 1 were applied to this example, the shipping information most susceptible to truncation by the compression process of the present invention is the "Attn: Sam Smith.”
  • the interface string from the user program 110 is sent to a compressor application 115 which compresses the destination address data and reformats the record as an ANSI-compliant label string ("label string").
  • label string The compression algorithm used in the compression application 115 is a novel modification of a traditional Huffman encoding technique.
  • a Huffman compression algorithm assumes data files consist of some byte or character values that occur more frequently than other byte values in the same file. By analyzing data that is typical of the data to be encoded, a frequency table can be built for each character value that appears within the data. A Huffman tree is then built from the frequency table. The purpose of the Huffman tree is to associate a bit string of variable length with each character value in the frequency table. More frequently used characters are assigned shorter strings, while characters that appear less frequently are assigned longer bit streams. In this manner, a data file may be compressed.
  • the compression algorithm implemented in the compression application 115 differs from traditional compression algorithms in several important aspects.
  • other compression algorithms known in the art compress at a file or record level.
  • the compression technique of the present invention compresses specific fields within a record.
  • the compression routine predominately compresses address-type data.
  • the compression algorithm of the present invention does not limit the compression substitution to single character values. Instead, the compression technique described herein searches for and replaces strings of characters. In a preferred embodiment, character strings vary from one to four characters in length.
  • Figs. 4A - 4H show a compression substitution table in accordance with one embodiment of the present invention that associates bit strings to each of the character strings that appear in shipping destination addresses.
  • This substitution table is the result of recursive tests run against approximately five million package label records to identify the character strings in the compression substitution table and to identify the frequency in which these character strings appear in destination addresses. More frequently used character strings were assigned shorter bit strings and less frequently used character strings were assigned longer bit strings.
  • the compressor reads in the fields in prioritized order, as dictated by Table 1. Compression of the fields occurs till the total length of the compressed string is 31 bytes. A truncation flag is set in the header, which is prepended to this stream of 31 bytes, resulting in a total of 32 bytes. The resultant 32-byte stream may contain values ranging from 0 to 255. This compressed stream is then mapped to our set of 55 possible values, resulting in a stream of 45 bytes. This is the stream which is placed in the '07' format portion of the ANSI compliant label string (output from the compressor).
  • Fig. 5 shows a data specification for the label string outputted by the compressor application 115 in one embodiment of the present invention.
  • the label string is then formatted into a printable format and a shipping label that includes a MaxiCode symbol is printed.
  • space considerations limit the amount of shipping information that can be encoded in the traditional MaxiCode symbol to city, state and zip, the compression process described above permits greater shipping detail to be encoded in the MaxiCode.
  • all of the shipping destination information may be encoded in a compressed MaxiCode.
  • FIG. 1 the decompression process is shown in the right column of the flow diagram.
  • a shipping label containing a compressed MaxiCode is scanned and decoded to create an ANSI-compliant label string.
  • the processes for scanning and decoding a two-dimensional MaxiCode symbology are well known in the art and are described in detail in one or more U.S. patents, one of which is U.S. Patent No. 5,610,995 to Zheng et al . It will be readily apparent to one of ordinary skill in the art that the compressed MaxiCode symbol on a shipping label can be scanned and decoded using a variety of methods and the present invention is intended to encompass any and all of these.
  • the ANSI-compliant label string is then passed to a decompressor application 120, which decompresses the label string by performing an inverse mapping of the compressed data.
  • the decompressor application 120 outputs an ANSI-compliant interface string that, in a preferred embodiment, is identical to the original string that was inputted into the compressor application when the label was generated.
  • the decompressor application 120 first maps the stream of 55 values back to the compressed stream of 32 bytes containing 256 possible values (0-255 decimal). The decompressor application 120 then reverses the foregoing process by using the compression substitution table to re-build the destination address by extrapolating all of the bit strings stored in the compressed fields to their original character form. The decompressor places an '*' (42 decimal) character into any field which had been truncated, if the truncation flag is set.
  • a smart shipping label 200 is shown in Fig. 6 and includes a routing code 210, a postal bar code 215, a service icon 220, a tracking number 225, a tracking number bar code 230 and a compressed MaxiCode 235.
  • Much of the information encoded on the label is in machine-readable format that allows the automation of the sortation and pre-load processes.
  • Fig. 7 shows the architecture of a smart shipping label generation system 300 .
  • the architecture comprises a customer shipping system 310 in communication with a carrier server (hereafter a "UPS server") 315.
  • the customer shipping system 310 may be a proprietary system of the client or may be one of several shipping systems available from third-party vendors.
  • the customer shipping system 310 includes a client application 320 in communication with a smart label tool 325.
  • the client application 320 resides on an AS/400 or Windows NT platform. But it will be readily apparent to one of ordinary skill in the art that this list of platforms is exemplary and that the smart label system may be configured to run on other platforms as well.
  • the smart label tool 325 resides at the customer site as part of the customer shipping system 310, but it should be readily apparent that the smart label tool 325 can reside on the UPS server 315 or a third-party server as well.
  • the smart label tool 325 uses a formatted output sub-system (FOSS) engine 330 to generate shipping label image files.
  • Fig. 7 also shows the communication between the customer shipping system 310 and the UPS server 315.
  • a customer shipping system 310 equipped with a smart label tool 325 is capable of generating a smart shipping label without accessing the UPS server 315.
  • the customer shipping system 310 accesses the UPS server 315 on a quarterly basis to update the routing code tables that are used to generate the routing code 210 on the smart label.
  • documentation and other software updates will reside on a UPS server website and may be accessed by the customer shipping system 310 as needed.
  • Fig. 8 illustrates the architecture of the smart label tool 325.
  • the smart label tool 325 includes an application program interface (API) 350 configured to communicate with both the client application 320 and a smart label tool interface 355.
  • API application program interface
  • the smart label tool interface 355 functions as a front end to control the communication between the FOSS engine 330 and the client application 320.
  • Additional components of the smart label tool that are not illustrated in the figure are a configuration file that handles the system settings and a series of output logs that track the operation of the system and errors that occur during the process.
  • the process begins with the client application 320 sending package label data to the API 350, which, in turn passes the label data to the smart label tool interface 355.
  • the API 350 thus functions as an interface between the customer shipping system 310 and the smart label tool 325.
  • the smart label tool interface 355 receives the label information from the API and performs a data validation routine to confirm that the label information includes all of the elements needed to generate a smart label and/or a pickup summary barcode (PSB). If essential data is missing from the label information, an error code and a detailed report of the error are generated.
  • PSB pickup summary barcode
  • the smart label tool interface 355 passes the label data to the FOSS engine 330, which compresses the shipping destination address of the label information using the MaxiCode compression process described above.
  • the FOSS engine 330 takes the label data as input and generates an electronic image of a smart shipping label, which is then written to the client hard-drive, where it can be printed and affixed to a package.
  • pre-load sortation is a process in which employees of the carrier, referred to herein as pre-loaders, load packages onto delivery trucks for delivery to the ultimate destination.
  • a carrier destination facility generally has a plurality of package cars that are being pre-loaded simultaneously.
  • each package car is equipped with a plurality of shelves to hold the packages to be delivered.
  • Pre-loaders have the responsibility of ensuring that the packages are loaded on the correct shelf of the correct package car and, to date, this process has been manual. Pre-loaders physically examine the destination address on the package label and determine from memory, which package truck delivers to that address and which shelf on the truck holds the packages for that address. This is a complex task and requires that pre-loaders receive extensive training on how to properly load packages. Not surprisingly, the manual intensiveness of this pre-load process causes errors in pre-loads and increased training costs. In today's environment with high turnover rates, the increased training time negatively impacts the ability to create and sustain a workforce capable of providing quality loads.
  • a PAS enables simplification of the pre-load operations by providing a handling instruction for every package handled by a pre-loader.
  • the handling instruction indicates the route (delivery vehicle) and the load position within the delivery vehicle for loading the package.
  • Fig. 9 is a high-level diagram that illustrates the operation of a PAS according to an embodiment of the present invention.
  • Step 1 a package bearing a smart shipping label arrives at the carrier destination facility. The package is scanned and the destination address of the package is captured from the compressed MaxiCode symbol.
  • Step 2 the destination address captured from the scanning process is validated. If the validation routine returns an error, a pre-loader is prompted to review the electronically captured address against the destination address printed on the shipping label.
  • Step 3 the destination address is sent to the PAS tool.
  • the PAS tool receives the destination address as input and compares the address against a dispatch plan to determine which delivery truck is assigned to deliver to the destination address and which shelf on the delivery truck will hold those packages that are delivered to that address.
  • the PAS tool then generates a package assist label (PAL) 500.
  • PAL package assist label
  • the PAL 500 is a mechanism for conveying the pre-load handling instructions 510.
  • Fig. 10 illustrates a PAL 500 in accordance with one embodiment of the invention.
  • three digits on the left side of the PAL (“208") indicate the delivery vehicle and route for loading the package.
  • the four digits that follow the hyphen (“7000") indicate the load position, sometimes known as a shelf position, within the delivery vehicle for loading the package.
  • Other information that is present on the PAL 500 illustrated is a package tracking number 225, primary 515 and secondary 520 package sortation information, a low to high indicator 525, a commit time 530 and an irregular drop-off indicator 535.
  • the primary 515 and secondary 520 sortation numbers identify the primary and secondary sortation belts for the package.
  • the presence of this information on the PAL 500 simplifies the movement of the package to the sortation belt that delivers the package to the package car.
  • the low to high indicator 525 indicates an order for loading a package car and in one embodiment is based on a primary street number of the package destination address. Thus, if a street range is given a handling instruction (i.e. 1-10 Main Street as R120-1888), if a low to high indicator 525 is set the packages are loaded from 1-10. On the other hand, if a load to high indicator 525 is not set, packages are loaded high to low (10-1 in this example).
  • an order is set in a dispatch plan and takes into account the direction a driver will be delivering for a particular street range.
  • the commit time indicator 530 on a PAL 500 indicates when a package is committed for delivery at a particular time. In a preferred embodiment, a commit time may be based on the service level desired by the customer, such as Next Day Air, Second Day Air or Ground.
  • the irregular drop-off indicator 535 on a PAL 500 indicates the location in the facility where irregular packages are sorted manually. Irregular packages are typically too large or too heavy or shaped in such a way that they cannot be placed on a sortation belt. In Step 4, a PAL 500 is affixed to the package and in Step 5, the package is loaded pursuant to the loading instruction on a PAL 500.
  • the pre-load operation is greatly simplified by generating handing instructions for each package in the pre-load process.
  • the simplified presentation of handling instructions allows an inexperienced pre-loader to become productive almost immediately as the knowledge base necessary to perform the pre-load operation is reduced.
  • pre-loaders were required to memorize potentially hundreds of addresses to load a delivery vehicle. Using the process described above, a pre-loader can readily perform the pre-load operation relying largely on the information present on the PAL 500.
  • Another advantage to the compressed MaxiCode and PAS process is that a carrier had greater flexibility to update dispatch plans. Because pre-load handling instructions are based upon a dispatch plan, significant changes to a dispatch plan often result in changes to the pre-load process. In the past, because the pre-load handling instructions were knowledge based, a carrier would be limited on how often it could change its dispatch plan without disrupting the pre-load operation. By reducing the knowledge base through the generation of the package handling instructions 510 on a PAL 500, a carrier can modify its dispatch plan without negatively impacting the pre-load process. This, in turn, creates the possibility that dispatch plans can be modified dynamically to provide customized delivery times.
  • a pre-load application to receive a dispatch plan and generate a scheme or plan for pre-loading.
  • the destination address is captured by a pre-load label application and compared against a dispatch plan, or in another embodiment against a pre-load plan, to generate handling instructions for that package.
  • the handling instructions are generated on a PAL 500, but one of ordinary skill in the art will readily recognize that other methods of generating handling instructions are available. For example, package handling instructions are sent to a monitor that a pre-loader reviews as a package is loaded onto a package car.
  • dispatch plans previously designed based upon dated historical data are now designed using more accurate, more recent information.
  • the basis for dispatch plans designs are not limited to historical data and may be based at least in part on a forecast of work for the day that the dispatch plan will be executed.
  • dispatch plans and pre-load schemes are updated daily to accommodate the work volumes anticipated for a given day.
  • a user may adjust a dispatch plan in real-time to allow for more current data to be factored into the dispatch plan.
  • Dispatch plans are well known in the art and are used daily by commercial carriers. In general, the term refers to the method in which work is assigned to carrier service providers (including pickup and delivery vehicles) to allow packages to be picked up and delivered in an orderly manner.
  • carrier service providers including pickup and delivery vehicles
  • the following paragraphs describe a dispatch planning system (DPS) by which a dispatch plan is created; however, it will be readily apparent to one of ordinary skill in the art that the present invention is equally advantageous with any dispatch plan no matter what method is used to create it.
  • DPS dispatch planning system
  • the first step in automating a pre-load operation is to electronically capture one or more dispatch plans.
  • a DPS in accordance with the present invention creates and maintains a variety of dispatch plans. Prior to the present invention, a single dispatch plan would be created and implemented manually. Changes to a dispatch plan required careful planning and communication between a center management team in charge of the dispatch plan and a pre-load team charged with the pre-load operation. The reason for this was that changes to the dispatch plan affected a change to the delivery vehicle routes and thus necessitated changes to the pre-load handling instructions.
  • the present invention allows a user to update or change a dispatch plan and to implement automatically that change in the pre-load operation.
  • a DPS receives electronically the dispatch plans from the DPS as well as package data from a flexible data capture (FDC), which is part of the production flow system.
  • Package data may arrive electronically via an origin package level detail (OPLD) feed into FDC or may be entered manually at a pre-load site by an operator.
  • OPLD origin package level detail
  • the PAS matches the package data to the dispatch plan and produces a PAL that is applied to each package.
  • the PAS provides the ability to monitor the pre-load operations and make adjustments to the dispatch plan during a package sort to account for unexpected changes in sort volume or carrier staffing.
  • a common component in a DPS is a graphical user interface (GUI) that allows a user to easily generate a dispatch plan and compare the dispatch plan against alternative dispatch plans.
  • GUI graphical user interface
  • a DPS user can simulate different dispatching options and access a detailed comparison of two or more dispatch plans.
  • a user can provide a sensitivity analysis to contrast multiple dispatch plans across different variable values.
  • a DPS in accordance with the present invention might compare multiple dispatch plans across several cost-benefit scenarios.
  • GUIs are used to simplify the process of planning, assigning work and simulating dispatch plan alternatives by using a series of map overlays that allow a user to dispatch work in different combinations.
  • an operator uses the interface to simulate a variety of dispatch plans via commands and/or through "click and drag" operations.
  • Fig. 11 illustrates a first layer of a map overlay that represents next day air work assignments for a given geographical area.
  • the map overlays allow a user to highlight street segments, clusters of sequence numbers or clusters of ZIP+4s and assign work to a specific driver.
  • dispatch statistics are calculated. For example, in one embodiment, planned work hours and delivery statistics are calculated as delivery stops are assigned. Other statistics relating to dispatch may be similarly calculated as will be readily apparent to one of ordinary skill in the art.
  • Another benefit of the system is that historical data can be used in conjunction with the interface to allow a user to estimate an expected delivery time for any set of stops in a cluster.
  • Fig. 12 illustrates a second layer of the map overlay for the same geographical area.
  • This second layer represents pickup work assignments for the geographical area and a user uses this layer to assign pickup work to the drivers that service the area.
  • Customer requests, volume availability requirements and delivery area statistics generally determine pickup work. The user assigns pickups based on these requirements and characteristics.
  • the second layer calculates dispatch statistics as work is assigned and provides a graphical representation of the pickup area.
  • every pickup point as identified by its ZIP+4, can be expanded on the screen to provide additional information, such as for example, scheduled pickup time and historical pickup time.
  • specific pickups that are subsequently assigned to other drivers can be specifically excluded from a route of a driver assigned to the area using this second layer.
  • Fig. 13 illustrates a third layer of the map overlay for the same geographical area.
  • This third layer represents other delivery work assignments for the geographical area and a user uses this layer to assign other delivery work to the drivers that service the area.
  • the third dispatch planning layer allows the user to assign the balance of the work clusters available in the selected area as defined by a historical set of data points.
  • actual ZIP+4 information including street information or a portion thereof
  • dispatch plans rather than relying on historical or work measurement data.
  • a user can design a trace (delivery route) manually, using existing sequence numbers as a tracing scheme.
  • drives or other carrier service providers may be given the option to design a trace or, in still another embodiment, optimization algorithms may be used to enhance the trace design.
  • a variety of methods for designing a trace may be used with the present invention, including manual route design, wherein a user clicks and drags from one street segment to another thereby building the trace one street at a time.
  • Alternative methods for designing a trace include driver adjustments that allow a driver to make route adjustments and communicate the adjustments directly via the PAS, routing based on existing sequence numbers, routing optimization based on operations research algorithms or a combination of the above.
  • DPS Upon completion of the dispatch planning in the third layer, DPS provides the user with final dispatch plan results including any unassigned street segments, sequence numbers, ZIP+4 clusters, final planned times and overlaps flagged as in error or needing additional revision. Once a final dispatch plan is designed, including routing detail, it is published to the PAS for execution.
  • Fig. 14 illustrates a fourth layer of the map overlay for the same geographical area.
  • This fourth layer is used to evaluate dispatch plan performance and to provide feedback to the dispatch plan designer.
  • the information provided by the fourth layer of the map overlay includes: actual trace of the driver (driver mapping), late next day air stops, inconsistent dispatch adjustments, send-agains after specific times, non-consecutive send-agains, pickups before a preset time, and high claim accounts.
  • historical information supporting the DPS can be used to develop special day plans and contingency plans.
  • the DPS of the present invention will allow a user to develop multiple driver level plans that can be communicated directly to the PAS based on projected package volume levels.
  • a fifth level of the map overlay is available that contains statistics aimed towards reducing service failures and improved performance. As an illustrative example, pickup and delivery stops that have a high claims history are highlighted and given special attention to avoid future claims.
  • Fig. 15 is a PAS process flow diagram that shows how the routing system interfaces with the address information and sequencing system to translate the routing and dispatch information into pre-load sorting and loading instructions for use in the PAS.
  • the routing system assists in the assignment of simplified sequence identifiers, which aid in pre-load simplification.
  • the routing system is designed to graphically illustrate a delivery vehicle shelf configuration and the destination address ranges assigned to a specific driver.
  • the routing system is further configured to allow a user to make click-and-drag adjustments as needed to modify the loading and handling instructions communicated to the PAS.
  • the aforementioned invention which comprises an ordered listing of selectable services can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.
  • a "computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.
  • the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical).
  • an electrical connection electronic having one or more wires
  • a portable computer diskette magnetic
  • RAM random access memory
  • ROM read-only memory
  • EPROM or Flash memory erasable programmable read-only memory
  • CDROM portable compact disc read-only memory
  • the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Claims (15)

  1. Procédé de réalisation d'une charge préalable de paquets en fonction d'un plan de distribution, le paquet ayant une première étiquette d'expédition (200) qui comprend une adresse de destination, et le plan d'expédition comprenant une affectation de tâches pour une zone géographique spécifiée entre plusieurs véhicules de livraison, dans lequel chacun des véhicules de livraison a la responsabilité d'une zone d'enlèvement et de livraison sous sa responsabilité dans ladite zone géographique et chacun des véhicules de livraison comprend plusieurs positions de chargement de paquets, le procédé de chargement préalable de paquets comprenant les étapes suivantes :
    l'émission du plan de distribution à un système d'assistance au chargement préalable avec un format électronique,
    la capture électronique de l'adresse de destination sur la première étiquette d'expédition (200),
    l'affectation, par le système d'assistance au chargement préalable, du paquet à l'un des véhicules de livraison et à une position de chargement dans le véhicule de livraison qui est affecté en fonction d'au moins une partie de l'adresse de destination du paquet,
    la création d'une instruction (510) de manutention de paquet qui identifie le véhicule affecté de livraison et la position de chargement dans le véhicule affecté de livraison,
    la fixation de ladite instruction (510) de manutention de paquet audit paquet ; et
    le chargement du paquet en fonction des instructions de manutention de paquet.
  2. Procédé selon la revendication 1, dans lequel la création d'une instruction de manutention de paquet comprend en outre la création d'une étiquette (500) d'aide de paquet qui comprend ladite instruction de manutention de paquet, et dans lequel la fixation de ladite instruction de manutention de paquet audit paquet comprend la fixation de ladite étiquette (500) d'aide de paquet.
  3. Procédé selon la revendication 1 ou 2, dans lequel l'étape de capture électronique de l'adresse de destination comprend la lecture d'une symbologie portée par l'étiquette d'expédition (200) qui a l'adresse de destination codée sur elle.
  4. Procédé selon l'une quelconque des revendications précédentes, dans lequel la seconde étiquette d'expédition (510) comprend un identificateur de véhicule de livraison, un identificateur de position de chargement et au moins un élément parmi un identificateur de niveau de service et un temps d'engagement.
  5. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre l'étape consistant à passer ladite adresse de destination dudit système d'assistance au chargement préalable à un programme de validation d'adresse pour confirmer que ladite adresse de destination est une adresse valide.
  6. Procédé selon la revendication 5, dans lequel un utilisateur reçoit une interrogation d'avoir à réviser la capture électronique d'adresse de destination par vérification sur l'adresse de destination imprimée sur la première étiquette d'expédition, (200) lorsque le programme de validation d'adresse donne une erreur.
  7. Système d'exécution d'un chargement préalable de paquets en fonction d'un plan de distribution, le paquet ayant une étiquette (200) d'expédition qui contient une adresse de destination, et le plan d'expédition comprenant une affectation de tâches d'une zone géographique spécifiée entre plusieurs véhicules de livraison, dans lequel chacun des véhicules de livraison se voit affecter la responsabilité d'une zone d'enlèvement et de livraison dans ladite zone géographique et chacun des véhicules de livraison comprend plusieurs positions de chargement de paquets, le système comprenant :
    un dispositif de lecture de paquets destiné à lire la première étiquette d'expédition du paquet et à capturer l'adresse de destination,
    un outil d'assistance au chargement préalable en communication électronique avec le dispositif de lecture de paquets qui reçoit l'adresse de destination et compare au moins l'adresse de destination au plan d'expédition pour la création d'une instruction de manutention de paquet, et
    un dispositif générateur d'étiquettes qui crée une seconde étiquette d'expédition qui contient l'instruction de manutention de paquet (510) à fixer audit paquet de façon à permettre audit paquet d'être chargé.
  8. Système selon la revendication 7, dans lequel l'instruction de manutention de paquet identifie l'un des véhicules de livraison qui est responsable de la tâche exécutée à l'adresse de destination.
  9. Système selon la revendication 8, dans lequel l'instruction de manutention de paquet identifie l'une de plusieurs positions de chargement sur le véhicule de livraison.
  10. Système selon l'une quelconque des revendications 7 à 9, dans lequel ledit dispositif de lecture de paquets comprend un parmi un lecteur de code barre, et un lecteur de MaxiCode.
  11. Système selon l'une quelconque des revendications 7 à 10, comprenant en outre un dispositif d'application qui fixe ladite instruction (510) de manutention de paquet audit paquet.
  12. Système selon la revendication 11, comprenant en outre un dispositif générateur d'étiquettes configuré pour créer une étiquette (500) d'aide de paquet qui comprend lesdites instructions (510) de manutention de paquet, dans lequel ledit dispositif d'application est configuré pour fixer ladite étiquette (500) d'aide de paquet audit paquet.
  13. Système selon l'une quelconque des revendications 7 à 12, comprenant en outre une application de planification d'expédition qui crée le plan d'expédition et publie le plan d'expédition pour l'outil d'assistance préalable au chargement.
  14. Système selon l'une quelconque des revendications 7 à 13, comprenant en outre un système de validation d'adresse qui reçoit l'adresse de destination et renvoie un code d'erreur lorsque l'adresse de destination n'est pas une adresse valide.
  15. Système selon la revendication 14, dans lequel l'outil d'assistance préalable au chargement demande à un utilisateur de comparer l'adresse de destination à l'étiquette (200) d'expédition lorsqu'un code d'erreur est reçu du système de validation d'adresse.
EP05024191A 2000-12-11 2001-12-11 Procédé et système pour pré-charger d'un colis selon un plan de livraison Expired - Lifetime EP1642654B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US25466100P 2000-12-11 2000-12-11
EP01986528A EP1385640B1 (fr) 2000-12-11 2001-12-11 Dispositif de compression utilisable pour l'impression intelligente d'une etiquette et le prechargement d'un colis

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
EP01986528A Division EP1385640B1 (fr) 2000-12-11 2001-12-11 Dispositif de compression utilisable pour l'impression intelligente d'une etiquette et le prechargement d'un colis

Publications (3)

Publication Number Publication Date
EP1642654A2 EP1642654A2 (fr) 2006-04-05
EP1642654A3 EP1642654A3 (fr) 2006-04-12
EP1642654B1 true EP1642654B1 (fr) 2008-07-16

Family

ID=35986203

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05024191A Expired - Lifetime EP1642654B1 (fr) 2000-12-11 2001-12-11 Procédé et système pour pré-charger d'un colis selon un plan de livraison

Country Status (1)

Country Link
EP (1) EP1642654B1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4832204A (en) * 1986-07-11 1989-05-23 Roadway Package System, Inc. Package handling and sorting system
US5292004A (en) * 1988-02-03 1994-03-08 Roger Cesarini Process for addressing to a recipient
DE4412097C1 (de) * 1994-04-08 1995-06-14 Hellmann Gmbh & Co Kg Geb Verfahren zur Verteilung von Paketen

Also Published As

Publication number Publication date
EP1642654A3 (fr) 2006-04-12
EP1642654A2 (fr) 2006-04-05

Similar Documents

Publication Publication Date Title
US9214000B2 (en) Method and system for performing a package pre-load operation in accordance with a dispatch plan
US7574447B2 (en) Inbound package tracking systems and methods
US6829369B2 (en) Coding depth file and method of postal address processing using a coding depth file
CA2475077C (fr) Procedes et systemes d'affranchissement global consolide
US8598482B2 (en) Intelligent barcode systems
US11526842B2 (en) System and method for item tracking
CA2385473C (fr) Systeme et procede de tri de courrier interdepartemental
CN101305379B (zh) 利用通用编码系统来追踪邮件的系统及方法
EP1642654B1 (fr) Procédé et système pour pré-charger d'un colis selon un plan de livraison

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

17P Request for examination filed

Effective date: 20051118

AC Divisional application: reference to earlier application

Ref document number: 1385640

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

17Q First examination report despatched

Effective date: 20060529

AKX Designation fees paid

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AC Divisional application: reference to earlier application

Ref document number: 1385640

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REF Corresponds to:

Ref document number: 60134898

Country of ref document: DE

Date of ref document: 20080828

Kind code of ref document: P

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2310314

Country of ref document: ES

Kind code of ref document: T3

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081216

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20080716

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20080716

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20080716

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20080716

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20090417

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081231

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081231

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081231

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081016

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20080716

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20080716

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081017

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 15

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 16

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 17

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20201201

Year of fee payment: 20

Ref country code: IT

Payment date: 20201110

Year of fee payment: 20

Ref country code: FR

Payment date: 20201112

Year of fee payment: 20

Ref country code: GB

Payment date: 20201202

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: BE

Payment date: 20201116

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20210112

Year of fee payment: 20

REG Reference to a national code

Ref country code: DE

Ref legal event code: R071

Ref document number: 60134898

Country of ref document: DE

REG Reference to a national code

Ref country code: GB

Ref legal event code: PE20

Expiry date: 20211210

REG Reference to a national code

Ref country code: BE

Ref legal event code: MK

Effective date: 20211211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20211210

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20220405

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20211212