The various transportation logistics tasks, such as order processing, order fulfillment, transportation of goods and tracking, are assigned to individual client/server objects which make up the building blocks of the computerized logistics management system. A tokenized message handling scheme allows client and server objects to share information, even where the respective data types do not match. An external processing manager provides script handling services to other client applications, allowing those applications to modify the performance of other program objects and to communicate with the outside world.
|
0. 86. A delivery management system, comprising:
at least one rate server having rate information based upon a set of rules by which a carrier delivers;
at least one client configured to collect input information from a user;
at least one supervisory server including at least one computer configured to provide registration services to facilitate communication between the rate server and the client via a client/server architecture utilizing an interprocess communication mechanism, said communication being independent of said supervisory server; and
whereby rules by which the user operates are isolated from the set of rules by which the carrier delivers.
0. 27. A logistics management system to facilitate the process of shipping goods by a shipper via a carrier, comprising:
a rate server, connected to a network, having a set of rules by which said carrier transports;
a client application, connected to the network, having a set of rules by which said shipper ships; and
a supervisory server, connected to the network, through which said rate server and said client application register to establish a mutual message communication capability by which said rate server and said client application thereafter pass messages independently of said supervisory server over an interface between them, said interface isolating the set of rules by which the shipper ships from the rules by which the carrier transports.
0. 71. A logistics management system to facilitate the process of shipping goods by a shipper via a carrier, comprising:
a rate server, connected to a network, having a set of rules by which said carrier transports;
a client application, connected to the network, having a set of rules by which said shipper ships;
a supervisory server, connected to the network, with which said rate server and said client application register to facilitate communication of messages between said rate server and said client application independently of said supervisory server; and
an interface associated with at least one of said rate server and said client application which isolates the set of rules by which the shipper ships from the set of rules by which the carrier transports.
0. 55. A logistics management method for facilitating the process of shipping goods by a shipper via a carrier, said shipper having a computer-implemented client application that has access to a network and which is related to shipping said goods, said client application having a set of rules by which the shipper ships, said method comprising the steps of:
providing a rate server having a set of rules by which the carrier transports in order to determine data related to shipping the goods;
providing access to said rate server on said network from the client application such that said rate server is separately located from said client application on said network; and
communicating the determined data from said rate server to said client application through an interprocess communication mechanism connected to said network and thereby isolating the set of rules by which the shipper ships from the rules by which the carrier transports.
0. 92. A computer-controlled apparatus configured to perform a method for facilitating the process of shipping goods by a shipper via a carrier, said shipper having a computer-implemented client application that has access to a network and which is related to shipping said goods, said client application having a set of rules by which the shipper ships, said method comprising the steps of:
providing a rate server having a set of rules by which the carrier transports in order to determine data related to shipping the goods;
providing access to said rate server on said network from the client application such that said rate server is separately located from said client application on said network; and
communicating the determined data from said rate server to said client application through an interprocess communication mechanism connected to said network and thereby isolating the set of rules by which the shipper ships from the rules by which the carrier transports.
0. 91. A computer-readable storage medium containing a set of computer-executable instructions for a method for facilitating the process of shipping goods by a shipper via a carrier, said shipper having a computer-implemented client application that has access to a network and which is related to shipping said goods, said client application having a set of rules by which the shipper ships, said set of instructions comprising:
providing a rate server having a set of rules by which the carrier transports in order to determine data related to shipping the goods;
providing access to said rate server on said network from the client application such that said rate server is separately located from said client application on said network; and
communicating the determined data from said rate server to said client application through an interprocess communication mechanism connected to said network and thereby isolating the set of rules by which the shipper ships from the rules by which the carrier transports.
0. 43. A logistics management system to facilitate the process of shipping goods by a shipper via a carrier, comprising:
a rate server having a record of one or more rates applicable to said carrier and further having an embedded set of predefined methods representing rate computation rules of said carrier, said rate server being connected to a network for sending, receiving and handling messages;
at least one client application connected to said network and is separately located from said rate server on said network, said client application having a user interface to permit the shipper to process shipments of goods;
said rate server having a shipper interface for defining a set of operations accessible to said client application, the set of operations representing a procedure by which the shipper ships goods to thereby isolate the set of operations by which said shipper ships from rules by which said carrier transports; and
at least one supervisory server for making said operations of said rate server accessible to said client application, said supervisory server being connected to said network for sending messages to and receiving messages from said rate server and said client application and for handling messages sent and received based upon a predefined set of rules.
0. 13. A logistics management system to facilitate the process of shipping goods by a shipper via a carrier, comprising:
a rate server comprising computer-implemented rate storage and calculating means, said rate server having message processing means for sending, receiving and handling messages;
said rate server having database means for maintaining a record of rates applicable to said carrier and further having an embedded set of predefined methods representing rate computation rules of said carrier;
at least one client application comprising computer-implemented input and output means separate from said rate server and having a user interface to permit the shipper to process shipments of goods;
said rate server having a shipper interface means for defining a set of operations accessible to said client application; the set of operations representing a procedure by which the shipper ships goods to thereby isolate the set of operations by which said shipper ships from rules by which said carrier transports;
at least one supervisory server for integrating operations of said rate server, and for making said operations accessible to said client application, said supervisory server having message processing means for sending messages to and receiving messages from said rate server and said client application and for handling messages sent and received based upon a predefined set of rules.
1. A logistics management tool to facilitate the process of shipping goods by a shipper via a selected one of a plurality of carriers, comprising:
a plurality of rate servers comprising computer-implemented rate storage and calculating means, at least one rate server for each of said plurality of carriers, at least one of said rate servers having message processing means for sending, receiving and handling messages;
at least one of said rate servers database means for maintaining a record of the rates applicable to a given one of said carriers and further having an embedded set of predefined methods representing the rate computation rules of said given one of said carriers;
at least one client application comprising computer-implemented input and output means separate from said rate servers and having a user interface to permit the shipper to interact with said logistics management tool in order to process the a shipment of goods;
at least one of said rate servers having a shipper interface means for defining a set of operations accessible to said client application; the set of operations representing the a procedure by which the shipper ships goods to thereby isolate the set of operations by which a said shipper ships from the rules by which a said carrier transports;
at least one supervisory server for integrating operations of said at least one rate server, and for making said operations accessible to said client application, said supervisory server having message processing means for sending messages to and receiving messages from said at least one rate server and said client application and for handling messages sent and received based upon a predefined set of rules.
0. 90. A logistics management system to facilitate the delivery of goods comprising:
a network architecture for passing messages;
a supervisory server having a registrar enabling communication with said network architecture;
at least one client application having a set of shipper rules and a first data processing service including a first registration service to register said client application with said registrar for establishing a line of communication between said client application and said network architecture, a first interface service to collect input data, generate a request message based on said input data and said set of shipper rules and display a response message, and a first message handling service to communicate said request message and said response message between said client application and said network architecture; and
at least one rate server having a set of carrier rules and a second data processing service including a second registration service to register said rate server with said registrar for establishing a line of communication between said rate server and said network architecture, a second interface service to generate said response message based on said set of carrier rules and said request message, and a second message handling service to communicate said request message and said response message between said rate server and said network architecture;
wherein said first and second message handling services enable communication between said at least one client application and said at least one rate server via said network architecture and isolate said set of carrier rules from said set of shipper rules.
2. The tool of
3. The tool of
4. The tool of
5. The tool of
6. The tool of
7. The tool of
8. The tool of
9. The tool of
10. The tool of
11. The tool of
12. The tool of
0. 14. The system of
0. 15. The system of
0. 16. The system of
0. 17. The system of
0. 18. The system of
0. 19. The system of
0. 20. The system of
0. 21. The system of
0. 22. The system of
0. 23. The system of
0. 24. The system of
0. 25. The system of
0. 26. The system of
0. 28. The system of
the client application includes a client interface for communicating with the client application; and
the rate server is configured to communicate with the client application via the client interface.
0. 29. The system of
at least one predefined request message issued by the client application to the rate server; and
at least one predefined response message issued by the rate server to the client application.
0. 30. The system of
the predefined request message includes a weight and a delivery date for a package to be shipped; and
the predefined response message includes a cost for shipping the package.
0. 31. The system of
0. 32. The system of
0. 33. The system of
0. 34. The system of
0. 35. The system of
0. 36. The system of
0. 37. The system of
0. 38. The system of
0. 39. The system of
0. 40. The system of
0. 41. The system of
0. 42. The system of
at least one predefined response message that includes a cost for shipping one or more packages issued by the rate server to the client application.
0. 44. The system of
at least one predefined response message including a cost for shipping the package is issued by the rate server to the client application.
0. 45. The system of
0. 46. The system of
0. 47. The system of
0. 48. The system of
0. 49. The system of
the client application includes a client interface for communicating with the client application; and
the rate server is configured to communicate with the client application via the client interface.
0. 50. The system of
0. 51. The system of
0. 52. The system of
0. 53. The system of
0. 54. The system of
0. 56. The method of
communicating the determined data to the client application through an accessible client interface.
0. 57. The method of
issuing a request message by the client application to the rate server; and
issuing a response message by the rate server to the client application.
0. 58. The method of
the request message includes a weight and delivery date for a package to be shipped; and
the response message includes a cost for shipping the package.
0. 59. The method of
providing the rate server with a knowledge base of rate structures and carrier practices pertaining to the carrier.
0. 60. The method of
providing the client application with a knowledge base of the shipper's practices pertaining to the shipper.
0. 61. The method of
0. 62. The method of
collecting via a user interface input information from a user about a desired shipping operation.
0. 63. The method of
providing an interprocess communication mechanism for passing messages between the rate server and the client application.
0. 64. The method of
0. 65. The method of
providing an external processing manager for interfacing with external data bases or other application programs.
0. 66. The method of
providing a device manager for interfacing with external peripheral devices.
0. 67. The method of
providing the client application with a document server for printing a shipping document.
0. 68. The method of
installing the rate server on a first computer system, with the client application being a second computer system; and
providing the determined data of the rate server to the client application over a global-wide area network.
0. 69. The logistics management method of
0. 70. The method of
issuing a response message by the rate server to the client application, wherein the response message includes a cost for shipping one or more packages.
0. 72. The system of
the client application includes a client interface for communicating with the client application; and
the rate server is configured to communicate with the client application via the client interface.
0. 73. The system of
at least one predefined request message issued by the client application to the rate server; and
at least one predefined response message issued by the rate server to the client application.
0. 74. The system of
the at least one predefined request message includes a weight and a delivery date for a package to be shipped; and
the at least one predefined response message includes a cost for shipping the package.
0. 75. The system of
0. 76. The system of
0. 77. The system of
0. 78. The system of
0. 79. The system of
0. 80. The system of
0. 81. The system of
0. 82. The system of
0. 83. The system of
0. 84. The system of
0. 85. The system of
0. 87. The system of
0. 88. The system of
0. 89. The system of
|
This is a division of U.S. patent application Ser. No. 08/128,358 entitled “Logistics System for Automating Transportation of Goods”, filed Sep. 28, 1993, now U.S. Pat. No. 5,485,369.
The present invention relates generally to computerized systems for expediting the shipping of goods in commerce. More particularly, the invention relates to a computerized logistics system for managing and integrating various aspects of order processing, order fulfillment and goods transportation and tracking.
In the past, computerized systems for expediting the shipping of goods have fallen into two rather diverse categories. At the low cost end of the spectrum have been the standalone postage meters and mail manifest systems used by small businesses to automate the package weighing and carrier manifest printing functions. At the other end of the spectrum are the mainframe computer-based systems employed by large nationwide mail order merchandisers. At both ends of the spectrum the systems have had a number of limitations.
The standalone mail manifesting systems are limited in that they are designed to automate only the shipping functions such as printing mailing label and mailing manifest by the shipping clerk or shipping department. As such, the conventional standalone system was not integrated with the customer order department or with the order fulfillment and order packaging departments. Hence, conventional standalone systems have lacked the ability to take order size, package size or time in transit into account when selecting the least cost carrier.
Large mainframe order processing systems are also limited. Due to the complexity of mainframe computer architecture and associated software systems, it is not practical to use these solutions in the small or moderate sized business environment. Mainframe-based systems often require years to develop and to customize for a particular organization's needs. Thereafter, large data processing departments are needed to maintain the system and keep it operational.
The present invention provides a high-performance, cost-effective logistics system which is readily adaptable to a wide variety of different organizations. The system is suitable for deployment on a single, standalone computer or on a computerized network comprising many computers. Among the advantages of the present system are (1) substantial reduction in freight costs; (2) a major increase in fulfillment accuracy; (3) convenient order tracking to facilitate warranty, lot and serial number tracking; (4) improved customer service; (5) a readily customizable system which can be adapted to virtually any shipping operation; (6) a robust system having a long useful life; (7) graphical user interface screens for easy training and use; and (8) greatly reduced implementation costs in a system with increased effectiveness.
As more fully described herein, the logistics management system of the invention facilitates the process of shipping goods by a shipper having a predefined set of shipping requirements via a carrier having a predefined rate structure. The system employs a multitasking operating system environment for running a plurality of computer processes substantially simultaneously. The environment has a means for interprocess communication whereby messages may be passed between the computer process. A supervisory server, running in the operating system environment, provides registration services to connect one or more computer processes to the interprocess communication mechanism. The system further employs at least one rate server, also running in the operating system environment, substantially simultaneously with the supervisory server. The rate server or servers provide access to carrier rate structure data and also provide predefined data processing services using the carrier rate structure data in response to a predefined set of request messages. The predefined data processing services include the providing of response messages based at least in part on the carrier rate structure data. More specifically, the rate server or servers have registration means for communicating with the supervisory server to invoke the registration services of the supervisory server and thereby establish a connection to the interprocess communication means. In the presently preferred embodiment there is one rate server for each carrier (e.g., U.S. Postal Service, Federal Express, United Parcel Service, etc.) and these servers are provided with a complete knowledge base of all rate structure data and shipping rules and regulations pertaining to that carrier.
In addition to the supervisory server and one or more rate servers, the logistics managements system also includes at least one client process running in the operating system environment substantially simultaneously with the supervisory server and also with the rate server or servers. The client process has a user interface for collecting input information from a user about a desired operation and for providing output information. More specifically, the client process also has registration means for communicating with the supervisory server, to invoke the registration services of the supervisory server, and thereby establish a connection to the interprocess communication means. The client process has a preprogrammed set of rules which are reflective of a given shipper's predefined set of shipping requirements. The client process also has a processing means for using the preprogrammed set of rules and using at least a portion of the input information to issue request messages to one or more rate servers and to interpret response messages received from the rate severs in order to provide the output information. In the presently preferred embodiment the client process is preprogrammed with a knowledge base to reflect the shipping organization's rules, regulations and practices. In this way, the client process presents a familiar view of day-to-day operations, as seen by the organization's personnel who are responsible for taking orders, packaging goods and shipping goods to customers. Because the sometimes complex rules and regulations of the carriers are fully handled by the rate servers, users interacting with the client process do not need to have a full and complete understanding of the carrier's rules and regulations in order to properly ship goods in a cost-effective and timely manner.
As more fully set forth herein, the supervisory server, the rate server or servers and the client process or processes are interoperable through the interprocess communication means (a) to receive input information from a user via the user interface of the client process, (b) to use the input information to issue a request message to the rate server via the interprocess communication means, (c) to process the issued request message and thereby cause a response message to be generated by the rate server, (d) to send the response message to the client process via the interprocess communication means, and (e) to provide output information based on the response message. The output information can range from simply displaying information on a screen to the user, to printing a mailing label or manifest or to updating records in a company database.
For a more complete understanding of the invention, its objects and advantages, reference may be had to the following specification and to the accompanying drawings.
The logistics system of the invention serves as a management tool for the automated order processing, packaging, shipping and transportation of goods. The system is highly flexible and adaptable and thus the invention can be implemented in many forms. Therefore, in order to illustrate the principles of the invention an exemplary order processing, packaging and shipping operation will be illustrated and described. It will be understood that the invention provides a collection of building blocks or program objects which can be assembled in a variety of different ways to easily construct a logistics management system for practically any application.
Referring to
The order packaging station may also comprise one or more computer terminals to which a bar code scanning device 28 may be optionally attached. The scanning device would be used, for example, to scan the universal product code (UPC) of each item as it is picked from the warehouse shelves and placed into the shipping container 30.
The shipping station 26 similarly may include one or more computer terminals to which a scanning device 32, electronic scale 34 and mailing label printers 36 may be attached. Preferably, the printers are capable of printing the necessary shipping documents, bills of lading, manifests and so forth, as well as the appropriate package labeling. If desired in the alternative, the package label may be preprinted (e.g. at the packing station) and the scanning device 32 may be used to read the label and thereby automatically enter the package identifying number into the system.
The logistics management system of the invention may be implemented in software and run from a variety of different computer platforms. Preferably, at least portions of the logistics management software are installed and run on each of the computer terminals illustrated in FIG. 1. In addition, the logistics management system software may also be installed and run on other computers attached to the network, such as computer 38. As will be more fully described below, the logistics management system is also capable of interfacing with non-native computer systems, e.g., previously existing company database systems, via an external processing management system. To illustrate this, an external database 40 is depicted in FIG. 1. The database may be resident, for example, on a mini-computer or mainframe computer used to store company financial records. If necessary, the external database system may be connected via a gateway 42 to the local area network bus 20.
Client/Server Architecture
The presently preferred logistics management system is implemented using a client/server architecture and a multitasking operating system. Although the presently preferred system runs under the OS/2 operating system, use of OS/2 is not a requirement. Any multitasking operating system can be used. A multitasking operating system was selected for the preferred embodiment because it permits multiple processes (and multiple threads) to run effectively simultaneously. The multitasking operating system thus allows multiple programs to run effectively simultaneously and to communicate with each other through an interprocess communications (IPC) mechanism.
One benefit of the multitasking operating system is that the present invention allows the logistics management task to be split into multiple pieces. This architecture is quite advantageous since it allows updates or changes to be effected with respect to part of the system without affecting the rest of the system. The client/server architecture derives benefit from the multitasking operating system by allowing the overall logistics management task to be subdivided along functional lines. As will be more fully explained below, the presently preferred embodiment places carrier-related information, such as shipping rates, shipping rules, time in transit information and the like in one or more rate servers. These servers are responsible for making all determinations regarding how a given carrier's rules and rate structures are to be interpreted. The presently preferred embodiment facilitates the particular shipper's requirements, such as order taking, order fulfillment, inventory control and the like, in one or more client applications. These client applications may be customized to conform quite closely to a given shipper's operation. These client applications call upon the necessary rate servers, as needed, for the appropriate shipping rates and shipping requirements of the selected carrier.
The multitasking operating system and the client/server architecture of the preferred embodiment comprises the logical structure of the logistics management system. The physical structure, i.e., how many computers are used and how those computers are interconnected, can vary widely and still implement the above-described logical client/server architecture. More specifically, the preferred embodiment is constructed to support distributed applications in which different pieces of the total client/server structure are run on multiple machines interconnected together via a network. In general, there is no limitation on how the respective client/server components are to be distributed across the network. Thus, for example, in the system illustrated in
The present invention uses a plurality of program building blocks or program objects, each having a specific function within the overall client/server architecture. The building blocks or program objects which make up the presently preferred embodiment are illustrated collectively in FIG. 2.
The Presently Preferred Program Objects
The presently preferred program objects are described in Table I below. Broadly speaking, these objects can be classified as being client objects or server objects. For example, the objects bearing the designation “server” or “manager” function as server objects. The objects designated as “client” or “administration” (admin) function as client objects.
More specifically, servers such as rate servers encode the knowledge required to answer questions such as how to calculate shipment rates or how to band shipments. Thus, rate servers provide the knowledge regarding a specific carrier's requirements. Typically, rate servers are provided with specific details regarding a given shipment's weight or the required delivery date by a client application. Also typically, rate servers do not have user interface screens. Servers simply appear as icons on the user's desktop and wait to be asked a question by a client. Provided the question includes the right details, the server will then return the correct answer to the client. Servers can reside anywhere on a network, so they may not necessarily be visible as icons on a particular user's computer screen.
Clients are principally responsible for asking specific questions of the servers. Clients have responsibility for gathering and displaying information. As such, clients usually have user interface screens through which a user can enter data or input data through an attached scanning device.
Manager objects are principally responsible for managing aspects of the logistics management system, such as the communication between clients and servers, or communication with printers, scanners and the like. Administration objects are principally responsible for providing a user interface mechanism whereby the user may edit system settings and scripts.
TABLE I
Program Object
Function
Supervisory Server:
Acts as a repository for system wide information.
Document Server:
Manages the client requests for non-carrier docu-
ment formats and the printing of those documents.
FedEx Rate Server:
Manages the Federal Express rates, carrier rules
and documentation requirements.
UPS Rater Server:
Manages the UPS rates, carrier rules and
documentation requirements.
RPS Rate Server:
Manages the RPS rates, carrier rules and
documentation requirements.
LTL Rate Server:
Manages the LTL rates, carrier rules and
documentation requirements.
Supervisory Manager:
Acts as a repository for machine-specific
information.
Ext. Process Manager:
Manages the client requests for access to outside
services such as remote databases and remote
computers.
Device Manager:
Manages the client requests for access to outside
devices such as printers, scanners, and scales.
Reset Database:
Resets the sample database to its default values to
facilitate training exercises.
Introduction to the
A tutorial for the new user.
system:
Reports:
Double-clicking this icon will run a third party
report generator program.
Supervisory
Allows the user to edit system settings, manage
Administration:
shipper information and allows users to send
messages to other computers.
Script Administration:
Allows the user to create and edit scripts used by
the External Processing Manager.
FedEx Administration:
Allows the user to configure the Federal Express
Server settings such as account numbers, EDI
settings and to close out the manifests.
UPS Rate
Allows the user to configure the UPS Server
Administration:
settings such as account numbers, rates, discounts
and to close out the manifests.
RPS Administration:
Allows the user to configure the RPS Server
settings such as account numbers, rates, discounts
and to close out the manifests.
LTL Administration:
Allows the user to configure the LTL Server
settings such as account numbers, and rates,
discounts and to close out.
Search and Trace:
A client application which allows the user to
search and trace specific packages, shipments and
orders.
Shipments:
A client application which allows the user to
process shipments comprised of multiple
packages per order.
Packages:
A client application which allows the user to
process shipments comprised typically of one
package per order.
Bills of Lading:
Allows the user to create bills of lading for LTL
Motor Freight Shipments.
LTL Shipments:
Allows the user to create and rate bills of lading
for LTL Motor Freight Shipments.
Document
Allows the user to configure the Document Server
Administration:
with UCC-128 serial number information and
In an actual implementation of the system, one supervisory server and at least one supervisory manager would be provided. Specifically, one (and only one) supervisory server is provided for the entire network. In addition, one supervisory manager is provided for each CPU that will be running client or server applications on the network. This is illustrated in
Although multiple CPU, distributed architecture installations represent a powerful configuration, it is possible to implement the invention on a single, standalone, CPU. This is illustrated in
Referring to
Overall Icon View—System Folder
The presently preferred embodiment places icons for all user-selectable program objects in the Logistics Management System folder or window, shown in FIG. 2. In this regard, the window shows a sample set of icons for the presently preferred system. Each icon is a pointer to a separate client, manager or server object. By double-clicking on the appropriate icon, its object is started. For example, double-clicking on the Shipments Client starts that program object running. Typically, once an object is started, it continues to run and is able to communicate with other program objects via the interprocess communications (IPC) mechanism.
Shipments Client
Shown in
The operator types or scans the Reference # (such as order #, pick ticket #, . . . ) and the system may be set to look up the associated information form one or more local and remote sources such as databases and mainframe or minicomputer terminal sessions. The upper left quadrant of the screen is to record information for the shipment as a whole.
The lower left quadrant is used to record specific information for each package in the shipment. In all client data entry screens there are several special data entry provisions. Any field which has an ellipsis ( . . . ) at its right edge has additional related fields of data available to be “examined” or edited by touching the F10 key or clicking the Examine icon. A popup window with the associated fields is displayed for the user. In addition, most fields may be set up to “browse” available valid entries. They may browse from database records or from “hard-coded” values in scripts.
The Shipments client and most other clients are capable of processing shipments of mixed modes; e.g. small parcel ground, small parcel air, LTL motor freight, air freight, and TL motor freight.
Packages Client
Shown in
Script Administration
The Script Administration object, shown in
UPS Rate Adjustments
Referring to
Serial Port 2 Configuration
The Serial Port 2 Configuration screen, shown in
Document Administration
The Document Administration object, shown in
Document Server
The document server, illustrated as one of the icons in
Device Manager Object
The Device Manager provides a device-independent means of interfacing with peripheral devices. Device drivers can be added or removed without modifying the software. The Device Manager also provides integrated testing tools.
The Device Manager of the presently preferred embodiment has the ability to monitor power, through an uninterruptible power supply connected to the system. If power fails, the other applications are notified, and an orderly shutdown of the system will take place. This prevents loss or corruption of data by sudden power outage or by subsequent failure of battery power, once the reserves of the uninterruptible power supply have been depleted. The monitoring service provided by the Device Manager can shut down multiple machines on a network connected through one uninterruptible power supply.
Referring to
Double-clicking on the COM2 icon brings up the configuration screen shown in FIG. 4E. Selecting the purl-down menu designated “Device” brings up the device selection menu shown in FIG. 4H. Using the device selection menu the Toledo 8213 Scale may be selected, as illustrated. Thereafter, by returning to the device manager menu of
Alternately, from the device manager menu of
The client/server architecture utilized by the logistics management system affords a great deal of flexibility. The client and server program objects are designed to work independently of one another, communicating with one another through a tokenized message handling mechanism discussed below. In this way, rate server data and user data are separated from one another. The advantage of this is that when a given carrier changes the way rates are handled, the affected rate server can be modified (to change the type or amount of data stored in that rate server, for example) without affecting the user's data in any way. This separation is important since carrier requirements and carrier service options may change at any time.
The presently preferred embodiment implements an internal version numbering scheme which provides a mechanism to allow client applications to determine what version of a server they are communicating with. In so doing, the client applications are able to make any necessary adjustments or to disconnect from that server if incompatibilities are found. This provides greater reliability, since server applications are given the ability to handle communications with servers intelligently.
Separation between client and server objects also makes possible an automatic updating capability whereby a user's existing setup information is automatically merged into a new installation when an application is updated or reinstalled. This reduces the amount of setup time due to reinstallation.
Each server of the presently preferred embodiment has built-in debugging capabilities which allow server transactions to be displayed on the screen or logged to a file for later analysis. The presently preferred rate servers optimize shipments to minimize cost through the use of shipment pricing rules supplied by the carrier. Optimization occurs “live” as a shipment is being processed, or, alternatively, at the end of the day when all packages shipped are then optimized. The rate servers can directly access carrier-supplied data, such as Federal Express routing and rate file data. This allows the user to load in new rate information as soon as such information is provided by the carriers. In addition, the rate servers of the presently preferred embodiment have the ability to rate and process a package, but to withhold it from the manifest until notified to do so. This allows “pack and hold” or future shipping. This is important in an automated system where a package may be processed upstream, but not placed on the manifest until it reaches the shipping dock.
In the presently preferred embodiment client applications have editable bar code templates, to allow data to be entered via a barcode scanner. Because the templates are editable, they can be added to, deleted from or modified by the user without the need for additional programming. Clients can also process in “batch” mode, reading data from a source and sending that data to the appropriate rate servers for processing. The sources for data can include databases, files or direct connection to a host computer via serial or network connection.
As stated above, the presently preferred embodiment uses a multitasking operating system which supports the processing of multiple processes or multiple threads effectively simultaneously. This allows client applications and server applications to operate effectively concurrently. To illustrate how multiple threads operate in the presently preferred embodiment refer to FIG. 5. In
Communication between client and server, whereby requests are passed to the server and responses passed back to the clients, may be accomplished in a variety of different ways. In general, the methods of communicating between multiple processes running on the same CPU include shared memory, semaphores, pipes, queues and signals. The methods of communicating between multiple processes running on different CPUs (distributed architecture) include mechanisms such as NETBIOS, named pipes, sockets and mail slots. Collectively all of these methods of communicating between multiple processes form part of the interprocess communication (IPC) mechanism. Not all multitasking operating systems provide each of the IPC mechanisms. The presently preferred embodiment runs under the OS/2 operating system and uses LAN Server to provide operating system support for a distributed application architecture over a network. The presently preferred embodiment uses named pipes as the IPC mechanism.
Named pipes allow one process to communicate with another process as follows. The client process first requests a named pipe connection to a server process. Once this connection is made, there is little distinction between the client process and the server process, since either can communicate with the other. One advantage of using the named pipe IPC mechanism is that the client process machine does not have to be running under the same operating system as the server process. All that is required is that the operating system platform on which the client process is running will support named pipes. Thus, a client process running under MS-DOS, or under MS-DOS with windows, for example, could establish communication with a server process running under the presently preferred OS/2 system, provided named pipe communication is supported. Essentially, under a named pipe communications scheme, the server process is known by a pipe name. Programs wishing to connect to that server will use the pipe name, in a fashion similar to using a file name. For example, pipe names may take the form:
\PIPE\pipename; or
\\server\PIPE\pipename.
Although the named pipe IPC mechanism permits communication between any server and any client, the presently preferred configuration constrains communication to a tree-structured communications scheme illustrated in FIG. 6. Referring to
The presently preferred communications scheme permits objects to communicate with devices, external databases and other computer systems which are not part of the client/server logistics management system. To accommodate this certain objects are given the ability to communicate with the outside world. These objects include the device manager, which communicates with hardware devices, such as printers, bar code scanners, modems, postal scales and the like. Communication with external databases and other programs which do not form a part of the client/server logistics management system (e.g., accounting software packages, spreadsheet programs, operating system utilities and the like) are communicated with through the external processing manager.
Because the presently preferred embodiment can be implemetned in multiple CPU environments (distributed architecture), an announcement mechanism is provided in order to extend the communications scheme to multiple CPUs across a network. The supervisory managers are preprogrammed with the ability to send “announcements” across the network operating system according to the named pipe protocol which has been implemented. Thus, as illustrated in
In summary,
The tokenized message handling scheme is very flexible, in that new tokens can be added at any time to accommodate new features, without the need to rewrite all client and server data structures. This is in contrast to the conventional fixed field data structure used in conventional data communication schemes. In the conventional, fixed field data structure scheme adding a new data value often requires all program modules to be rewritten to accommodate the added data field. The tokenized message passing scheme of the present invention avoids this problem. If a new data field is required, to support a new feature, for example, a new token is created and only those objects which make use of the new value will need to be reprogrammed to scan for the newly added token. All remaining objects simply ignore tokens which are undefined for them.
The presently preferred tokenized message passing scheme implements automatic data type conversion. As set forth in Table II, the type definitions of all values associated with tokens are predefined, thus the tokenized message passing scheme has advance knowledge of the data types of all values. This allows the tokenized message handling scheme to perform all data type conversions, removing the need for client and server objects to perform type conversions. In other words, a server can pass a long word value to a client which is expecting a string value. The tokenized message handling scheme performs the data conversion automatically so that the server does not need to be aware of the client's data type requirements and the client does not need to be aware of the server's data type requirements.
External Processing Manager
In order to allow the client server logistics management system to communicate with the outside world, e.g. with external data bases or other application programs, the external processing manager is provided. The external processing manager is, itself, a client of a supervisory manager, as illustrated in FIG. 6. The external processing manager, in turn, operates as a server to provide external processing functions to other clients. In
In the preferred embodiment, the external processing manager interfaces with the REXX command interpreter supplied with the OS/2 operating system. The external processing manager is designed to receive its instructions from an ASCII file called a script file. If desired the script file can be encrypted to prevent unauthorized access. The script file comprises a list of program commands or instructions written in the REXX language. If desired, the REXX language command set can be extended to add additional commands. This may be done by embedding the additional commands in the external processing manager. The external processing manager would envoke the REXX interpreter and register itself as the source of the additional commands. In this way, the REXX interpreter would automatically pass control to the external processing manager to handle the additional commands. The external processing manager is designed to communicate directly with the REXX interpreter, passing the script file commands to the REXX interpreter and requesting the output of the REXX interpreter to be directed back to the external processing manager, where appropriate. In this way, the external processing manager is given access to the operating system and to all other application programs running on the operating system. This is a very powerful command which allows the logistics management system to interface with other applications which may not necessarily be designed to integrate directly with the logistics management system. For example, the external processing manager could use the REXX interpreter to send SQL queries to a database, in order to upload information about a customer's account from the accounting system software.
The external processing manager's ability to handle scripts provides another powerful feature. Scripts may be written for the purpose of modifying the performance of other program objects comprising the logistics management system. Scripts can be used, for example, change the shipments client to provide a reminder message to the user in the event the user attempts to ship a package without first entering the weight of the package. Similarly, a script could be written to change the shipments client to supply a convenient list of package dimension sizes, allowing the operator to quickly fill in the size of a package in the appropriate field by simply selecting it from a list. In general, the scripting language can be used to provide virtually any custom tailoring that a shipper might want to implement. The REXX language is straightforward and easy to use, thus most customizing to meet the user's requirements can be done in the field, without the need to access or modify the underlying program source code.
In running a script to modify the performance of a program object, the external processing manager uses the existing IPC mechanism. Through this mechanism the external processing manager can request a data item stored by the object or it may supply a data value as an input to the data object. In addition, the external processing manager can request that one or more operations defined for that object to be performed. Thus the external processing manager serves as an alternate to the normal user interface as a means for manipulating data or performing operations.
From the foregoing it will be seen that the present invention provides a logistics management system comprising a plurality of building blocks or client/server objects. These objects can be configured to communicate in a variety of different ways to accommodate virtually any transportation-related logistics application. Thanks to the client/server architecture and the support for distributed architectures, the overall logistics management task is readily subdivided into highly self contained functional units. When changes in a given function are required, only the object providing the function normally needs to be changed. The client/server objects provide further flexibility through the external processing manager and scripting language, whereby individual objects can be modified to provide special features quite readily on an as needed basis.
While the invention has been described in its presently preferred form, it will be understood that the principles of the invention may be extended to a wide variety of different forms. Accordingly, the preferred embodiment described herein should be considered as exemplary of the principles of the invention and not as a limitation of the scope of the claims.
TABLE II
APPENDIX
TYPE
MAXIMUM
I/O TOKEN
VALUE DESCRIPTION
DESCRIPTION
LENGTH
Registry
To register a program:
REGISTER
PROG_ID_ . . . id from
string
PROGRAM
PROGISTI.H machine on
ID
which program is running
MACHINE
blank if no network use
getmachinename( ) function
To unregister a program:
UNREGISTER
PROG_ID_ . . . id from
string
PROGRAM
PROGISTI.H machine on
ID
which program is running
MACHINE
blank if no network use
getmachinename( ) function
Use this to get a list of ALL programs running in the environment. If
FILENAME is blank, then either the program is not a server or it is a server
you cannot use. For historical purposes, you may use ENUM SERVER as
well as ENUM PROGRAM.
ENUM
your current/local machine
string
PROGRAM
blank if no network use
MACHINE
getmachinename( ) function
[
PROG_ID_ . . . id from
string
150
ID
PROGISTI.H user-friendly
NAME
name of the program for
DISPLAY PURPOSES ONLY!!
TYPE
“server type” mask from
ushort
MACHINE
PROGISTI.H machine on
string
which program is running FOR
DISPLAY PURPOSES ONLY!!
ZONE
where is the program running?
short
1 = on your local machine
2 = somewhere else
FILENAME
pipe name you may use to
string
access server - BLANK IF
YOU CANNOT ACCESS
SERVER
. . . ]
Announcements
Use this to send an announcement. Only include the DATA token if you need
it (it uses a queue slot on the receiving machines). You may include one or
more specific machine names if you want the announcement sent to specific
machines. If you don't specify MACHINE or if it is blank, the announcement
will be sent to all machines currently in the environment.
ANNOUNCE
ANN_ . . . from ANNOUNCE.H
long string
ANNOUN
ID
optional string
CE_DATA
[DATA
LEN]
[
[MACHINE
destination machine name
string]
. . . ]
Miscellaneous
Use this to close the environment. This is harmless and will not close
anything that is not ready to be closed. It will never shut down a machine.
SHUTDOWN
System Numbers
If QUERY/ENUM/MODIFY SYSNBR is used with an SYSNBR ID that does
not yet exist, an entry is automatically added to the number list with these
defaults:
Last value
(VALUE)
0
used
First in
(START)
I
sequence
Limit/last in
(STOP)
2147483646
(maximum
sequence
long)
In all cases, the value passed for TOK-SYSNBR must be non-zero (except
for ENUM) and unique within all programs that might ever be running in the
system. The recommendation is to use the appropriate TOK_ . . . define for
your SYSNBR value.
To got the next number in sequence:
QUERY
see rules above
short
SYSNBR
VALUE
next number in sequence
long
To get the status of an entry in the number list:
ENUM
see rules above
short
SYSNBR
ID
short
VALUE
see doc above
long
START
see doc above
long
STOP
see doc above
long
INCREMENT
see doc above
long
To get the status of all entries in the number list:
ENUM
SYSNBR
(no value specified)
[
ID
short
VALUE
see doc above
long
START
see doc above
long
STOP
see doc above
long
INCREMENT
see doc above
long
. . . ]
To change the status of an entry in the number list:
MODIFY
SYSNBR
see rules above
short
VALUE
see doc above - optional
long
START
see doc above - optional
long
STOP
see doc above - optional
long
INCREMENT
see doc above - optional
long
If any optional token is not specified, the previous value is not changed. This
can be used to change certain numbers without being required to change
others. For example, if you add to entry and want to use the defaults for
START, STOP and INCREMENT but want specify you own VALUE, you
can do it.
Shipper Maintenance
All of these commands deal with the master list of shippers. Clients can
access the master list via ENUM. An announcement is sent when any shipper
information of any kind changes. This allows other programs to know when
they need to do another ENUM - especially if they are storing additional
shipper information in parallel with this master list. Other programs can use
LOCK and UNLOCK to prevent a shipper from being deleted “out from under,
them”.
To get full information on all current shippers:
ENUM
SHIPPER
[
Unique ID for this shipper
string
SHPAB-
ID
unique shipper short name
BRLEN
SYMBOL
follows C rules for a variable
NAME
user-friendly shipper name
string
undefined
FOR DISPLAY PURPOSES
ONLY!!
ERRCODE
validity/status of shipper
string
SHPAB-
SHPNA
name/address
boolean
BRLEN
SHPABBR
shipper abbreviation
LOCK
is shipper locked by some
. . . ]
program?
To get full information on a shipper:
ENUM
SHIPPER
shipper ID (from ENUM
SHIPPER)
ID
unique ID for this shipper
string
SHPAB-
SYMBOL
unique shipper short name
BRLEN
follows C rules for a variable
NAME
user-friendly shipper name
string
undefined
FOR DISPLAY PURPOSES
ONLY!!
ERRCODE
validity/status of shipper
string
SHPAB-
SHPNA
name/address
boolean
BRLEN
SHPABBR
shipper abbreviation
LOCK
is shipper locked by some
program?
To change a shipper's information:
MODIFY
shipper ID (from ENU
string
SHPAB-
SHIPPER
SHIPPER)
BRLEN
SHPNA
name/address - optional
SHPABBR
shipper abbreviation - optional string
To add a shipper:
ADD
SHIPPER
To delete a shipper:
DELETE
shipper ID (from ENUM
SHIPPER
SHIPPER)
To check-out a shipper to a program to prevent deleting:
LOCK
shipper ID (from ENUM
SHIPPER
SHIPPER)
PROGRAM
PROG_ID_ . . . ID from
PROGISTI.H
MACHINE
machine on which program is
running string blank if no
network use
getmachinename( ) function
To check-in a shipper (UNLOCK):
UNLOCK
shipper ID (from ENUM
SHIPPER
SHIPPER)
PROGRAM
PROG_ID_ . . . ID from
PROGISTI.H
MACHINE
machine on which program is
running string blank if no
network use
getmachinename( ) function
Commitment Code
To get the master list of available commitments:
ENUM
COMMIT-
MENT
[
COMMIT_ . . . ID from RATER.H
string
undefined
ID
Commitment short name
SYMBOL
follows C rules for a variable
NAME
user-friendly commitment
string
undefined
name FOR DISPLAY
. . . ]
PURPOSES ONLY!!
START
use manifest mode?
boolean]
[MANIFEST
/* default package info */
[
SHIPDATE
date (TDC)
long 0
SHIPPER
ID
short 0
DONTBAND
don't band yet
boolean
SERVICE
ID (see FDXRATER.H)
short 0
PKGTYPE
ID (see RATER.H)
short 0
PAYTYPE
payment type (see RATER.H)
short 0
PAYORACCT
payor account number
string
LFDX_-
PAYOR
WEIGHT
Weight
long 3
REF
reference
string
LEN_RE-
FER-
ENCE
LENGTH
package length
short 0
WIDTH
package width
short 0
HEIGHT
package height
short 0
RCPID
recipient ID
string
LEN_RE-
CIPIENT-
ID
RCP-
recipient contact name
string
NALEN_-
CONTACT
CON-
TACT
RCP-
recipient company name
string
NALEN_-
COMPANY
COM-
PANY
RCPADDR1
recipient address line 1
string
NALEN_-
ADDR
RCPADDR2
recipient address line 2
string
NALEN_-
ADDR
RCPCITY
recipient city
string
NALEN_-
CITY
RCPSTATE
recipient state
string
NALEN_-
STATE
DEST
postal code
string
NALEN_-
ZIP
RCPPHONE
recipient phone number
string
MAX-
PHONE-
LEN
CODAMOUNT
COD amount
long 2
CODTYPE
logical OR of COD_ . . .
short
HAZ
hazardous materials?
boolean
SIGREL
signature release?
boolean
DIRECTDEL
direct delivery (Dingle)?
boolean
HOLD
hold for delivery?
boolean
SATDEL
Saturday delivery?
boolean
DECVAL
declared value
long 0
ICE
weight of dry ice (whole lbs)
short 0
]
LISTID
next package list ID
long 0
ITEM
LISTID
id
long 0
[
SHIPDATE
date (TDC)
long 0
SHIPPER
ID
short 0
DONTBAND
don't band yet
boolean
SERVICE
ID (see FDXRATER.H)
short 0
PKGTYPE
ID (see RATER.H)
short 0
PANTYPE
payment type (see RATER.H)
short 0
PAYORACCT
payor account number
string
LFDX_-
PAYOR
WEIGHT
Weight
long 3
REF
reference
string
LEN_RE-
FER-
ENCE
LENGTH
package length
short 0
WIDTH
package width
short 0
HEIGHT
package height
short 0
RCPID
recipient ID
string
LEN_RE-
CIPIENT-
ID
RCP-
recipient contact name
string
NALEN_-
CONTACT
CON-
TACT
RCP-
recipient company name
string
NALEN_-
COMPANY
COM-
PANY
RCPADDR1
recipient address line 1
string
NALEN_-
ADDR
RCPADDR2
recipient address line 2
string
NALEN_-
ADDR
RCPCITY
recipient city
string
NALEN_-
CITY
RCPSTATE
recipient state
string
NALEN_-
STATE
DEST
postal code
string
NALEN_-
ZIP
RCPPHONE
recipient phone number
string
MAX-
PHONE-
LEN
CODAMOUNT
COD amount
long 2
CODTYPE
logical OR of COD_ . . .
short
HAZ
hazardous materials?
boolean
SIGREL
signature release?
boolean
DIRECTDEL
direct delivery (Dingle)?
boolean
HOLD
hold for delivery?
boolean
SATDEL
Saturday delivery?
boolean
DECVAL
declared value
long 0
ICE
weight of dry ice (whole lbs)
short 0
]
MSN
ID
long 0
RTCODE
routing code
string
9
COMMIT-
code (see RATER.H)
short 0
MENT
ARRIVE
date (TDC)
long 0
DIMWT
dimensional weight
short 0
[TRACKNBR
tracking number/COD tracking
string
11]
#
CODRETTRK
COD return tracking number
string
11]
CONTENTS
/* ignored for now */
RATE
LISTID
ID
long 0
standard
see SERVER.DOC
COD
COD charge
long 2
DECVAL
declared value charge
long 2
HAZ
dangerous goods charge
long 2
SATDEL
saturday delivery charge
long 2
SATPU
saturday pickup charge
long 2
ALASKACHG
Alaska delivery charge
long 2
HAWAIICHG
Hawaii delivery charge
long 2
DIMRATE
any package DIM rated?
boolean
END
LISTID
ID
long 0
[DELETE
true to just throw list away
boolean]
[
/* if manifest*/
standard
see SERVER.DOC
]
VOID returns a list of other MSNs whose data was changed. Package
documentation should be reprinted and any data saved should be QUERYed
again:
VOID
ID
MSN
long 0
[
MSN
list of MSNs
long 0
. . . ]
LIST
BAND
SHIPPER
ID
short 0
[
18
NAME
displayable form of shipdate
string
ID
thing to pass to band
long 0
. . . ]
LIST
DEL
[TRANSMIT]
SHIPPER
ID
short 0
[
NAME
displayable shipdate &
string
21+
ID
seqnum filename
string
12
. . . ]
LIST
TRANSMIT
SHIPPER
ID
short 0
[
NAME
shipdate & seqnum
string
21+
ID
filename
string
12
. . . ]
(see PRINT section - SERVER.DOC)
LIST
PRINT
. . .
. . .
BAND
SHIPPER
ID
short 0
ID
thing returned from LIST
long 0
ID
filename created
string
12
DEL
[TRANSMIT]
[
ID
filename (returned from LIST)
string
12
. . . ]
(see PRINT section - SERVER.DOC)
PRINT
. . .
/* courier & summary report */
ID
filename (returned from LIST)
string
12
/* ASTRA label */
MSN
package master sequence
long 0
number
[PRINT-
ignore print error?
boolean]
ERROR
/* rate chart */
SHIPPER
ID
short 0
/* airbill */
MSN
package master sequence
long 0
number
. . .
[MORE
true
boolean]
QUERY
PRINT
(see PRINT section - SERVER.DOC)
. . .
. . .
QUERY
ITEM
Standard stuff
(see (ENUM section - SERVER.DOC)
ENUM
SHIPPER
[
SYSNBR
POWERSHIP plus number
string
ACCOUNT
FedEx account number
string
USER
IIN user Id
string
PWD
IIN password
string
PWD
IE password
string
USER
recipient user Id
string
ORIGIN
origin station
string
TRACKNBR
first tracking number
string
TRACKNBR
last tracking number
string
CODTRK
first COD tracking number
string
CODTRK
last COD tracking number
string
CODRETTRK
first COD return tracking
string
number
CODRETTRK
last COD return tracking
string
number
SIGREL
signature release authorization
string
number
PWRSHP
POWERSHIP plus complaint
boolean
DIMRATE
use dimensional rating
boolean
GNDSAVER
use Express saver
boolean
. . . ]
ENUM
CONTROL
SHIPPER
ID
TRACKNBR
last package tracking number
string
used
CODTRK
last COD tracking number
string
used
CODRETTRK
last COD return tracking
string
number
COUNT
cycle count
long 0
COUNT
transfer count
long 0
ENUM
CONFIG
DIAL
Hayes-compatible dialout
string
LFDX_-
command
DIAL
BAUD
baud rate
short
PORT
port
short
DIR
expedite directory
string
LFDX_-
PATH
see FDXRATER.H for more information on each element
MODIFY
SHIPPER
ID
[see ENUM SHIPPER section]
MODIFY
CONTROL
SHIPPER
ID
[see ENUM CONTROL section]
MODIFY
CONFIG
[see ENUM CONTROL section]
(after END with MANIFEST TRUE, use this to change item information)
MODIFY
ITEM
MSN
package master sequence
long 0
number
[DONTBAND don't band yet boolean]
/*see RATER.C */
LOCK
SHIPPER
ID
UNLOCK
SHIPPER
ID
REFRESH
SHIPPER
LOAD
ZONE
/*URSA routing file - -
unZIPs!*/
SHIPPER
ID
FILENAME
drive (A, B, etc.)
LOAD
RATE
/* electronic rate file */
SHIPPER
ID
FILENAME
drivepath and filename
LOAD
REGION
/* region file, if Express saver
*/
SHIPPER
ID
FILENAME
drivepath and filename
TRANSMIT
SHIPPER
ID
[
ID
filename
. . . ]
CANCEL
Johnson, Steve, Nicholls, Peter, Howard, Scott, Kinyon, Robert, Skaistis, Jeff, Locker, Andy, Guzik, Chris
Patent | Priority | Assignee | Title |
10430753, | Mar 06 2013 | United States Postal Service | System and method for international merchandise return service |
10521755, | May 04 2015 | United States Postal Service | System and method for processing items for international distribution |
11281850, | Dec 28 2017 | A9 COM, INC | System and method for self-filing customs entry forms |
11288619, | May 04 2015 | United States Postal Service | System and method for processing items for international distribution |
7841516, | Dec 30 2005 | SAP SE | Delivery data objects in enterprise computing systems |
7970722, | Nov 08 1999 | International Business Machines Corporation | System, method and computer program product for a collaborative decision platform |
8005777, | Nov 08 1999 | International Business Machines Corporation | System, method and computer program product for a collaborative decision platform |
8160988, | Nov 08 1999 | International Business Machines Corporation | System, method and computer program product for a collaborative decision platform |
8584107, | Jul 07 2006 | United Parcel Service of America, Inc. | Compiled data for software applications |
8918341, | Mar 06 2013 | United States Postal Service | System and method for international merchandise return service |
Patent | Priority | Assignee | Title |
4511958, | Jan 30 1978 | ABB Industrie AG | Common bus access system using plural configuration tables for failure tolerant token passing among processors |
4713761, | Jul 18 1985 | PITNEY BOWES INC , WALTER H WHEELER, JR | System for centralized processing of accounting and payment functions |
4799156, | Oct 01 1986 | Strategic Processing Corporation | Interactive market management system |
4837701, | Dec 26 1985 | Pitney Bowes Inc.; PITNEY BOWES INC , WALTER H WHEELER, A CORP OF DE | Mail processing system with multiple work stations |
4862357, | Jan 28 1987 | SYSTEM ONE INFORMATION MANAGEMENT, L L C , A DELAWARE LIMITED LIABILITY COMPANY | Computer reservation system with means to rank travel itineraries chosen in terms of schedule/fare data |
4949272, | Dec 16 1988 | Pitney Bowes Inc.; Pitney Bowes Inc | Flexible billing rate for mail communication systems |
5008827, | Dec 16 1988 | Pitney Bowes Inc | Central postage data communication network |
5021953, | Jan 06 1988 | AMERICAN EXPRESS TRAVEL RELATED SERVICES COMPANY, INC | Trip planner optimizing travel itinerary selection conforming to individualized travel policies |
5038283, | Apr 13 1989 | Panduit Corp. | Shipping method |
5050078, | Oct 03 1989 | Pitney Bowes Inc.; Pitney Bowes Inc | Mail processing and accounting system with communication among processing units and data reformatting |
5068797, | Oct 03 1989 | Pitney Bowes Inc.; PITNEY BOWES INC , WORLD HEADQUARTERS, STAMFORD CT A CORP OF DE | Optimizing mail delivery systems by routing |
5072401, | Oct 03 1989 | Pitney Bowes Inc.; PITNEY BOWES INC WORLD HEADQUARTERS, STAMFORD, CT A CORP OF DE | Optimizing mail delivery systems by logistics planning |
5124926, | Mar 02 1990 | Pitney Bowes Inc. | Carrier management system having accounting registers |
5161109, | Dec 16 1988 | Pitney Bowes Inc | Up/down loading of databases |
5220501, | Dec 08 1989 | OFFICIAL PAYMENTS CORPORATION | Method and system for remote delivery of retail banking services |
5253342, | Jan 18 1989 | International Business Machines Corporation | Intermachine communication services |
5262939, | Jul 03 1990 | Alcatel Satmam | System for processing parcel shipping |
5293310, | May 22 1992 | Pitney Bowes Inc.; Pitney Bowes Inc | Flexible method for applying customized rating adjustments to transaction charges |
5325527, | Jan 19 1993 | Canon Kabushiki Kaisha | Client/server communication system utilizing a self-generating nodal network |
5337246, | May 22 1992 | Pitney Bowes Inc. | Flexible apparatus and method for applying customized rating adjustments to transaction charges |
5363121, | Jun 29 1990 | International Business Machines Corporation | Multiple protocol communication interface for distributed transaction processing |
5493491, | Jan 10 1992 | GILLETTE COMPANY, THE | Method of ordering, shipping and merchandizing goods and shipping/display assembly therefor |
5684965, | Oct 22 1992 | Liberty Peak Ventures, LLC | Automated billing consolidation system and method |
5694551, | May 20 1993 | Moore Business Forms, Inc. | Computer integration network for channeling customer orders through a centralized computer to various suppliers |
5778348, | Dec 24 1991 | Pitney Bowes Inc. | Remote activation of rating capabilities in a computerized parcel manifest system |
5802293, | Jun 28 1993 | DOW BENELUX N V | Integrated plant environment utilizing an advanced program-to-program server enabling communications between programs running in different computing environments |
5832511, | Jun 11 1992 | SOFTWARE RESTORE SOLUTIONS LLC | Workgroup network manager for controlling the operation of workstations within the computer network |
5852809, | Sep 11 1992 | MemoryLink, Inc. | System and method for routing data and communications |
5971592, | Mar 08 1993 | Integrated reusable pallet having data collection devices and method for using shipping conveyances | |
6006199, | Dec 31 1991 | International Business Machines Corporation | Method and system for automated payment within a computer integrated manufacturing system |
6115713, | Jan 30 1990 | Johnson Controls Technology Company | Networked facilities management system |
6161122, | Dec 10 1992 | HANGER SOLUTIONS, LLC | Method and apparatus for interactively providing information at multiple sites |
6199100, | Jul 15 1988 | International Business Machines Corp. | Interactive computer network and method of operation |
6202054, | Nov 16 1992 | OFFICIAL PAYMENTS CORPORATION | Method and system for remote delivery of retail banking services |
EP343933, | |||
EP464766, | |||
EP484875, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
May 20 1999 | United Parcel Service of America, Inc. | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Date | Maintenance Schedule |
Sep 29 2012 | 4 years fee payment window open |
Mar 29 2013 | 6 months grace period start (w surcharge) |
Sep 29 2013 | patent expiry (for year 4) |
Sep 29 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
Sep 29 2016 | 8 years fee payment window open |
Mar 29 2017 | 6 months grace period start (w surcharge) |
Sep 29 2017 | patent expiry (for year 8) |
Sep 29 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
Sep 29 2020 | 12 years fee payment window open |
Mar 29 2021 | 6 months grace period start (w surcharge) |
Sep 29 2021 | patent expiry (for year 12) |
Sep 29 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |