GB2333867A

GB2333867A - Carrier manager interface utilizing an OCX control

Info

Publication number: GB2333867A
Application number: GB9821215A
Authority: GB
Inventors: Glen A Boucher; Terri A Carroll; Jacques E Hasbani; Kenneth Karbowski; Junior John Mattioli; Angela M Njo; Stephen C Nunnally
Original assignee: Pitney Bowes Inc
Current assignee: Pitney Bowes Inc
Priority date: 1997-10-01
Filing date: 1998-09-30
Publication date: 1999-08-04
Anticipated expiration: 2018-09-30
Also published as: GB9821215D0; GB2333867B; CA2248419A1

Abstract

The present invention is a method and system of utilizing an OCX and object oriented programming to share data between applications operating under differing operating system environments. The method links a first client application (104) with a second client application (114), through a carrier manager module (102) which could comprise an OCX environment, by initiating (310) the first client application and transmitting a query from the first client application to the carrier manager module. The second client application is subsequently initiated (312) and a query is transmitted from the second client application to the carrier manager module. A running object table is created (316) within the carrier manager module (102). The carrier manager module, the query from the first client application, and the query from the second client application are registered (318, 320, 322) within the running object table, each as a separate object Once registered, the objects can be evaluated by comparing (324) a pre-determined subset of a select object with one or more subsets comprising another object. Once a comparison has been made, the method then performs a linking of the objects to create (326) a new object; and, if a match does not exist, then the system queries subsequent objects until a match is made. After the evaluation has been made, then the method performs a linking of the first client application with the second client application by creating a fourth object that comprises the new object and linking commands for linking the first client application with the second client application.

Description

CARRIER MANAGER INTERFACE UTILIZING AN OCX CONTROL This invention relates to a carrier manager interface utilising an OCX control.

In this specification, the term " OCX is used, which is explained as follows. OLE and Active X controls, which are supported by Microsoft Corp., are representative of an object oriented programming environment. The general environment is labelled in the programming art as "OCX". The OCX control environment allows for late binding of function calls, remote execution in a distributed or networked environment, and interface with the Internet or World Wide Web. The OCX acts as an exchange facility to facilitate object oriented linking of diverse applications. Linking is accomplished by initiating a query at an application.

The OCX control environment creates (or simply maintains as the case may be) a running object table for managing the objects to be created by the data link with the client applications. The method to be described hereinbelow then advances to where the OCX registers its ability to control the linked applications by creating a discrete object within the running object table that is representative of the control.

Reference is made to United Kingdom Patent Application ~~~~~~ (Agent's reference P1303), entitled A METHOD AND SYSTEM FOR ACCESSING CARRIER DATA, United Kingdom Patent Application ~~~~~~~ (Agent's reference P1303), entitled A METHOD AND SYSTEM FOR CHANGING RATING DATA VIA INTERNET OR MODEM IN A CARRIER MANAGEMENT SYSTEM, United Kingdom Patent Application , (Agent's reference P1303), entitled A METHOD AND SYSTEM OF IMPLEMENTING A CARRIER MANAGER LIBRARIAN, and United Kingdom Patent Application ~~~~~~ (Agent's reference P1303), entitled A METHOD AND SYSTEM OF IMPLEMENTING A CARRIER MANAGER REGISTRY, all filed on even date herewith.

The related, commonly assigned, applications cited hereinabove, as well as the present application, are directed toward methods and systems for efficiently handling logistics applications. More particularly, the present application is directed toward a method and system for rating charges to be applied to parcels, letters, or similar items to be transported by a carrier as selected from among a set of carriers.

The ability of shippers to get parcels from the loading dock to the final destination in shorter time spans and at less cost has increased in recent years.

The growth of the overnight carriers, and the consistency of the two and three day delivery carriers has created vast fleets of transport vehicles representing each of the many transportation modes. These, in turn, benefit from efficient manifesting and logistical accounting.

Carriers are companies that provide services to their clients for facilitating the transport of letters, parcels, bulk goods, or anything that can be shipped by public, common, or specialized transport means. There is a great variety in the types and scope of services that can be provided by the individual carrier.

The growth of shipping demand has fueled the drive for efficiencies that each of the carriers has been developing. Technological advances and better methods of doing business have in turn spurred greater demand for carrier services. The net result is that the volume of parcels being shipped has continued to spiral upward.

Systems and methods have been proposed to more efficiently handle the increased volume of parcels and the proliferation of carrier services that are available.

Carriers have introduced systems and methods that are targeted to that carrier only. Shippers have looked for systems that provide them with a means to rate or service shop. The object of all of these systems has been to get a parcel on from point A to point B, efficiently.

Carrier Management Systems such as that described in U.S. Patent Number 5,040,132, SYSTEM FOR PREPARING SHIPPING DOCUMENTS, issued August 13, 1991 to Schuricht et al., are well known to the art. One such system is the E900 Carrier Management System, developed and marketed by the present applicants. The E900 generally includes as peripheral elements: a microprocessor; keyboard; monitor; platform scale; printer; and possibly a scanner. The E900 system automatically prepares documents for shipping articles to any desired number of different receivers by any selected carrier or mode.

The ability of carriers to respond to shipper needs is based on the carrier's capacity. Carrier capacity is the space that is available at any given time in the vehicle representing the carrier's mode of transport.

For every shipment that leaves the dock of a shipper bound for a particular destination, a carrier makes available a mode of transportation. Each mode of transportation has its unique vehicle for transport: freight cars via rail; containers via ship; cubic inches via truck; etc. This capacity must be rated in some manner according to the rating data developed and promulgated by each of the carriers.

Each carrier has its own rate structure for service charges. Typically, rate structures are complex and involve a variety of factors; these factors may include: distance from origin to destination; weight rating; dimensional rating; service rating; and mode of transport. Thus, the business rules for rating items to be transported varies greatly from carrier to carrier.

Rating calculations may shift over time depending upon shifts in the business or carrier climate. Accordingly, it is desirable to provide a mechanism for updating how carrier rates are calculated.

The efficiency of rating techniques has been enhanced by methods such as is taught in U.S. Patent No.

5,293,310 for a FLEXIBLE METHOD FOR APPLYING CUSTOMIZED RATING ADJUSTMENTS TO TRANSACTION CHARGES, issued March 8, 1994 to Carroll et al. and assigned to the assignee of the present claimed invention. Carroll et al. discloses a method for automatically applying customized rating adjustments to transaction charges. Charges are determined by partitioning a class of transactions into cells in accordance with pre-determined criteria, determining base rates for the resulting cells, and applying customized rates to certain cells before transmitting the combined rate data to a shipping system data center. U.S. Patent No. 5,337,246 for a FLEXIBLE APPARATUS AND METHOD FOR APPLYING CUSTOMIZED RATING ADJUSTMENTS TO TRANSACTION CHARGES, issued August 9, 1994 to Carroll et al. discloses an alternative method of automatically applying customized rating adjustments to transaction charges.

The prior art works well in embedded systems or in an intranet environment where the systems administrator or systems user has some measure of control over the operating system platforms that are storing data, applying rating charges, and storing the data within a data center. However, the advancement of data processing systems and the ability of varying logistics services applications to require data sharing for the purposes of optimizing logistics operations has created a definitive need for systems of varying architecture, and with varying operating systems, to be able to share data within a common environment. Thus, there is a need for a logistics/shipping system capable of managing diverse applications within a common environment for optimal service. Additionally, a method of employing the rating functionality of one application within the functionality of another application is required.

As the capabilities of data processing systems has grown, so too have the requirements that are tasked to these systems. Greater speed has given rise to more detail oriented applications, greater memory capability has made memory intensive applications more attractive, and detailed applications have lead to more wide-spread use of previously inaccessible data processing abilities.

With the spiraling growth in data processing ability, there has grown a need for more efficient ways of programming that promote speed as well as flexibility.

Flexibility, in particular, allows applications that have been designed in varied programming languages, or operating on different platforms to be able to communicate without extensive system or file modification.

Once such means of promoting flexibility within a data processing system is in the use of "object-oriented" design (OOD). Object oriented programming languages are useful in removing some of the restrictions that have hampered application design due to the inflexibility of traditional programming languages.

OOD utilizes a basic element or construct known as the "object.," which combines both a data structure and an intended behavior characteristic within the single element. Thus, software applications become an organized collection of discrete objects in which data is held or moved based on the intended behavior of an object which is inherently unique. Each object knows how to perform some activity. Objects can be specific or conceptual.

But, to be of value to a particular application, objects must be able to be referenced.

Referencing is accomplished through indexing, addressing, or through value assignment which can be placed in a table for use as required. Objects can also be arranged by classification. Classification is based on groupings of objects based upon properties or characteristics important to an application or requirement. Each class describes a potentially infinite set of objects that comprise that class.

OOD is known in the software arts and specific discussion of application design based upon OOD is not required for a thorough understanding of the applicant's claimed invention. The use of object oriented design, together with the use of an OCX to facilitate object oriented linking of diverse applications, is a distinct benefit when employed within data processing systems such as logistics systems with rating applications. Therefore, it is an object of the present invention to provide for an object oriented method and system, utilizing an OCX, of interfacing between logistics applications that are based on differing program languages or exist on differing operating system platforms.

The present claimed invention is a method and system of utilizing an OCX and object oriented programming to share data between applications operating under differing operating system environments.

The method of the present invention links a first client application with a second client application, through a carrier manager module which could comprise an OCX environment, by initiating the first client application and transmitting a query from the first client application to the carrier manager module. The second client application is subsequently initiated and a query is transmitted from the second client application to the carrier manager module.

A running object table is created within the carrier manager module, and the carrier manager module is registered in the running object table as a first object.

The query from the first client application is registered within the running object table as a second object; and, the query from the second client application is registered within the running object table as a third object.

Once registered, the objects can be evaluated by comparing a pre-determined subset of the second object with one or more subsets comprising the third object.

Once a comparison has been made, the method then performs a linking of the second object with the third object to create a new object if the pre-determined subset of the second object matches a subset of the third object; and, if a match does not exist, then the system querys subsequent objects until a match is made.

After the evaluation has been made, then the method performs a linking of the first client application with the second client application by creating a fourth object that comprises the new object and linking commands for linking the first client application with the second client application.

The linking process comprises the further steps of utilizing the fourth object as a means of identifying a link between the first client application and the second client application wherein the fourth object eliminates the need to compare the pre-determined subset with the one or more subsets comprising the third object, for initiating subsequent software application links.

Additionally, the first client application can access a data set of the second client application by requesting the data set through the carrier manager module. The data set could be a set of instructions for applying rates to parcels to determine shipping charges for those parcels.

Additionally, the proposed method involves the possible step of accessing a data set of the first client application by the second client application, or the request path could be reversed or flow both ways, by requesting the data set through the carrier manager module. Or, the method could involve the step of accessing a data set of the carrier manager module by either the first or the second client application by requesting the data set through the carrier manager module.

For a better understanding of the invention and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings, in which: FIG. 1 is a block diagram of a typical logistics or shipping system as described within related applications as listed hereinabove.

FIG. 2 is block diagram of a data processing system which is of an architecture that is suitable for implementing the claimed invention FIG. 3 is a flowchart of the method of linking two or more client applications through the use of an OCX control to manage a running object table.

FIG. 4 is diagram of a representative shipping system utilizing the method of FIG. 3 within the environment of FIG. 2.

Turning to FIG. 1 there is shown system 100 which is typical of logistics or shipping applications that can employ rating schemes to determine carrier charges based upon input from more than one input application.

The heart of the system is run-time loadable carrier manager module 102 which is comprised of a rating engine for performing at least some of the rating related tasks.

Carrier manager module 100 interfaces with first client application 104 which is configured to perform various shipping related tasks. The carrier manager module is further configured to access entries in system registry 108.

System registry 108 is responsible for run-time loading one of a plurality of carrier rate modules 110 as well as for registering all modules available to the carrier manager module 100. The carrier rating modules 110 are loaded into the executable space of first client application 104, thereby avoiding the use of resource intensive inter-process communication (IPC) mechanisms (IPC mechanisms would include "named pipes," etc.).

Each carrier rating module 110 includes program instructions to access carrier rate data 112 and rate items using business rules encapsulated therein together with rate data associated with a particular carrier.

After loading a carrier rating module 110, the carrier manager module 102 provides an entry point in the carrier rate module 110 to the first client application 104. In this manner, first client application 104 can invoke the instructions in the carrier rate module 110 to rate an item (such as a particular parcel or a particular service) for the carrier associated with the selected rate module 110. Additionally, first client application 104 includes prior carrier rating routines of its own for rating items based on carrier rate data 106.

Carrier manager module 102 can also be loaded by a second client application 114, together with its additional rate data 116, for utilizing the carrier rating functionality of the carrier rating modules 110 as is described hereinabove in connection with the first client application 104. Thus, the isolated carrier rating modules 110, under control of carrier manager module 102 are arranged to provide carrier rating functionality for a plurality of client applications 104, 114, or possible others, as may be required by the system user or designer.

In some system configurations, the revision level of the first client application 104 may be such that they were developed prior to the design of the system architecture described herein. For example, first client application 104 may be a shipping application for rating parcels shipped by express carriers. When the carrier manager system 100 architecture is designed, it would be a relatively uncomplicated task to upgrade first client application 104 to access carrier management module 102 for the carrier rating functions in the new carrier rating modules 110. In the instant example, new carrier rate modules 110 may contain Less Than Truckload (LTL) rating routines for shipping items by truck. Thus, to add trucking functionality to first client application 104's legacy of functions, it is a relatively straightforward process to call the new carrier management module 102 to load the carrier rate modules 110 applicable to LTL rating activities.

First client application 104 still includes the prior carrier rating routines of its own for rating items based on carrier rate data 106 for carriers not supported by carrier rating modules 110. In the example, the shipping application still contains routines for rating parcels for supported carriers; however, it is difficult to extract the carrier rating routines from first client application 104 for creating a new carrier rating module 110. Systems that rely upon legacy data tend to break down if large scale modifications are made thereto because the data becomes incompatible with the new application that seeks to employ it. Replacing carrier rating routines within a new carrier manager architecture could lead at least to compatibility problems, or at worst to system breakdown.

Keeping the carrier rating routines in the first client application 104, instead of in the carrier rating modules 110, means that rating functionality for those carriers is not available to second client application 114. In the example, second client application 114 may be a load planning application. In the configuration shown in FIG. 1, load planning application (in this case second client application 114) only has access to the LTL rating routines of carrier rating modules 110 and not to the rating routines embedded in the legacy shipping application (in this case first client application 104).

Thus, it is desirable to make the carrier rating functionality of first client application 104 available to second client application 114 without having to make extensive modifications to first client application 104.

First client application 104, however, may be implemented in a programming language or operating system environment in which it very difficult (i.e. task intensive) to receive requests directly from second client application 114 for the purposes of rating.

A method of employing the rating functionality of one application within the functionality of another is shown in FIG. 2.

Turning to FIG. 2, there is shown a block diagram of data processing system 200 which is of an architecture that is suitable for implementing the claimed invention.

Data processing system 200 comprises bus 202, or a similar communications means, for communicating information, and a processor 204 operatively coupled with bus 202 for processing data. Data processing system 200 also includes a main memory 206, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 202 for storing data and instructions to be executed by processor 204. Main memory 206 also may be used for storing temporary variables or other immediate data during execution of instructions by processor 204. Data processing system 200 further comprises a read only memory (ROM) 208 or other static storage device coupled to bus 202 for storing static data and instructions for processor 204. Storage device 210, such as a magnetic disk or optical disk, is provided and coupled to bus 202 for storing data and instructions. Common examples of data processing system 200 may include: personal computers (PCs); work stations, mini-computers; servers; mainframes; and certain LANs or WANs.

Data processing system 200 may be coupled via bus 202 to a display 212, such as a cathode ray tube (CRT), for displaying information to a system user. An input device 214 such as a keyboard, including alphanumeric and/or other keys, is coupled to bus 202 for communicating information and command selections to processor 204. Another type of user input device is cursor control 216, such as a mouse or trackball, or cursor direction keys for communicating direction information and command selections to processor 204 and for controlling cursor movement on display 212.

According to one embodiment of the invention, rating items for carriers is provided by data processing system 200 in response to processor 204 executing one or more sequences of one or more instructions contained in main memory 206. Such instructions may be read into main memory 206 from another computer readable medium, such as storage device 210. Execution of the sequences of instructions contained in main memory 206 causes processor 204 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in memory 206. In alternative embodiments, hard-wired circuitry may be used in place of, or in combination with, software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The data processing system 200 may be operated by a user, for example, sitting at a desk with a keyboard as an input device 214, a mouse as a cursor device 216, and a monitor as a display device 212. The user types commands through the keyboard or "clicks" with the mouse on icons displayed on the monitor to execute instructions that cause the data processing system 200 to rate an item. The results of the item rating may be displayed to the user on the monitor or saved to a file in storage device 210 for use by other programs (i.e. an application for printing a bill of lading, printing permits, or applying postage).

The term "computer readable medium" as used herein refers to any medium that participates in providing instructions to processor 204 for execution. Such a medium may take many forms, including but not limited to: non-volatile media such as optical or magnetic disks; volatile media such as dynamic memory; and/or transmission media such as coaxial cables, copper wire, or fiber optic cable. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer readable media include: a floppy disk; a flexible disk; hard disk; magnetic tape; CD-ROM; DVD; or any medium form from which a computer can read.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 204 for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A second modem, resident at data processing system 200, can receive the instructions on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector coupled to bus 202 can receive the data carried in the infrared signal and place the data on bus 202 for further transport. Bus 202 carries the data to main memory 206, from which processor 204 retrieves and executes the instructions. The instructions received by main memory 206 may optionally be stored on storage device 210 either before or after execution by processor 204.

Data processing system 200 also includes a communication device 218 coupled to bus 202.

Communication interface 218 provides a two-way data communication coupling to a network link 220 that is connected to a local network 222. For example, communication interface 218 may be an integrated services digital network (ISDN) card or a modem to provide a data communications connection to a corresponding type of telephone line. As another example, communication interface 218 may be a local area network (LAN) card to provide a data communications connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 218 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

Network link 220 typically provides data communications through one or more networks to other data devices. For example, network link 220 may provide a connection through local network 222 to a host computer 224 or to data equipment operated by an Internet Service Provider (ISP) 226. ISP 226, in turn, provides data communication services through the world-wide packet data communication network, commonly referred to as the "Internet" 228. Local network 222 and Internet 228 both use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 220 and through communication interface 218, which carry the digital data to and from data processing system 200, are exemplary forms of carrier waves transporting the information.

Data processing system 200 can send messages and receive data, including program code, through the network(s), network link 220, and communication interface 218. In the Internet example, a server 230 might transmit a requested code for an application program through Internet 228, ISP 226, local network 222, and communication interface 218. In accordance with the invention, one such downloaded application provides for rating items for carriers.

The received code may be executed by processor 204 as it is received, and/or stored in storage device 210, or other non-volatile storage for later execution. In this manner, data processing system 200 may obtain application code in the form of a carrier wave.

Turning to FIG. 3, there is shown a flowchart of the method of applying object oriented design to the linking of the first and second client applications within a system such as that disclosed by FIGs. 1 and 2; and, it should be noted that the method can be expanded to include additional client applications.

The flowchart begins at step 310. At step 310, a client application such as a shipping system is TM initiated. Shipping systems, such as the Ascent system available from Pitney Bowes Inc. of Stamford, Connecticut, typically handle a number of different actions which include: the ability to maintain customer accounts; the maintenance of carrier data over a broad range of services or whipping classes; the ability to receive data input from one or more sources (such as a barcode scanner, a weighing scale, or a keyboard); the ability to store data in the accounts or files for which the data is descriptive; and, the ability to rate parcels, or other items. At a time either essentially simultaneous to, or subsequent to, the initialization of the first client application, a second client application is initiated at step 312. The second client application could be another shipping application, or an application such as load planning or export planning software (such TM TM as Export Manager or LoadPlanner , each available from Pitney Bowes Inc. of Stamford, Connecticut) which would benefit greatly from the ability to interface with the first client application.

Each of the initiated applications, or subsequent initiated applications, if any, transmit a link to an OCX so as to let the carrier manager program module register the presence of the active client application at step 314. Dynamic linking a module involves loading at runtime the module into the executable space of an executing process, e.g. a portion of virtual memory allocated by the operating system for executing a process such as the first or second client applications. Common examples of these modules include dynamic link library (DLL) modules, shared libraries, and OLEa and ActiveXw controls supported by Microsoft Corp. OLE and ActiveX controls, sometimes called "OCX", allow for late binding of function calls, remote execution in a distributed or networked environment, and interfacing with the Internet or World Wide Web.

From step 314, the method advances to step 316 where the OCX control environment (hereinafter referred to as simply "OCX") creates (or simply maintains as the case may be) a running object table for managing the objects to be created by the data link with the client applications. The method then advances to step 318 where the OCX registers its ability to control the linked applications by creating a discrete object within the running object table that is representative of the control. From step 318, the method advances to steps 320 and 322 essentially simultaneously, or in subsequence if initialization of the client applicati to the second client application. Both step 320 and step 322 advance to step 324, where the system, under control of the OCX, compares and/or reads the objects stored in the running object table. The objects can be further read at subset level so as to identify particular requirements embedded within the object. If a particular activity is sought by the first client application (i.e. the application requests a link to, or data from, the second client application), then the system identifies a predetermined subset of the first object and comparing the pre-determined subset with one or more subsets comprising the second object or subsequent objects.

The method advances from step 324 to step 326. At step 326, the system creates a new object by linking the identified first object with a second object to create a new object if the pre-determined subset of the first object matches a subset of the second object; and if the match does not exist, then querying subsequent objects until a match is made. The method then advances from step 326 to step 328 by utilizing the newly created object as a means of identifying a link between the first client application and the second client application wherein the newly created object eliminates the need to compare the pre-determined subset with one or more other subsets comprising the second object for subsequent software application links. Once linked in this manner, the first client application can perform services, such as rating, while utilizing the rating modules of the second client application to which it would otherwise not be linked.

Though initially slow in relative terms, the result of the object creation is thus extremely efficient because it reduces the need to retrain the system each time the client applications need to link with each other for the exchange of data or resident services.

FIG. 4 is a diagram of the linking taking place within specific example of a shipping system utilizing the method of FIG. 3 within the system of FIG. 2.

Turning to FIG. 4, there is shown system 400 comprising: a first client application 412 such as a Windows-based shipping application (such as Ascent); a second client application 414, which may be C++ based, such as load planning or export planning software (such as Export Manager or LoadPlanner); a shipping application database which may be co-located with an LTL database; an OCX control; a common data linking library; LTL files; and LTL data.

Windows-based shipping application 412 is initiated and then seeks to link with the overall system 400 by accessing OCX 410. At a time either essentially simultaneous to, or subsequent to, the initialization of the shipping application, the second client application 414, which for purposes of this system is C++ based, is initiated and then seeks to link with the overall system 400 by accessing OCX 410.

Each of the initiated applications, or subsequent initiated applications, if any, transmit a link to the OCX 410 so as to let the overall system 400 register the presence of the active client applications.

Once linked to the OCX 410, the OCX creates (or simply maintains as the case may be) a running object table for managing the objects to be created by the data link with the client applications 412 and 414. The OCX registers its ability to control the linked applications by creating a discrete object within the running object table that is representative of the control.

The OCX registers the query from the first client application 412 as an object within the running object table. The query may simply be a request for a link to some application or to the system manager OCX 410. The system performs the same task with respect to the second client application 414. The system, under control of the OCX 410, compares and/or reads the objects stored in the running object table. The objects can be further read at subset level so as to identify particular requirements embedded within the object. If a particular activity is sought by the first client application 412 (i.e. the application requests a link to, or data from, the second client application), then the system 400 through the OCX identifies a pre-determined subset of the first object and compares the pre-determined subset with one or more subsets comprising the second object or subsequent objects.

The system 400 creates a new object by linking the identified first object with a second object to create a new object if the pre-determined subset of the first object matches a subset of the second object; and, if the match does not exist, then querying subsequent objects until a match is made. The system then utilizes the newly created object as a means of identifying a link between the first client application 412 and the second client application 414 wherein the newly created object eliminates the need to compare the pre-determined subset with one or more other subsets comprising the second object for subsequent software application links. Once linked in this manner, the first client application 412 can perform services, such as rating, while utilizing the rating modules of the second client application 414 to which it would otherwise not be linked.

Data for system 400 is generated or stored in several forms, these forms may be as co-located databases, or may be dependent upon certain applications or controls. The exchange of data between certain modules or databases can be performed by dynamic linking. Dynamic linking a module involves loading at run-time the module into the executable space of an executing process, e.g. a portion of virtual memory allocated by the operating system for executing a process such as client application 412 or 414. Common examples of these modules include dynamic link library (DLL) modules 420 which are interfaced to the OCX 410. Additionally, specific carrier rating modules, such as the one or more LTL files 410n can be interfaced to one or more LTL data files 424n to pass data the OCX 410 for specific rating requirements.

Each of the applications as well, can draw on databases for storing data intrinsic to the application functions.

In that way, the shipping application 412 can interface with its resident database 416 which may be further linked, or co-located with an LTL setup database 418 that can be interoperatively connected to the LTL Files 410n.

Claims

Claims: 1. In a carrier management system, a method of linking a first client application with a second client application through a carrier manager module, comprising the steps of: (a) initiating a first client application and transmitting a first query from said first client application to said carrier manager module; (b) initiating a second client application and transmitting a second query from said second client application to said carrier manager module; (c) creating a running object table within said carrier manager module; (d) registering said carrier manager within said running object table as a first object; (e) registering said first query within said running object table as a second object; and, registering said second query within said running object table as a third object; (f) comparing a pre-determined subset of said second object and comparing said pre-determined subset with one or more subsets comprising said third object; (g) linking said second object with said third object to create a new object if said pre-determined subset of said second object matches a subset of said third object; and if said match does not exist, then querying subsequent objects until a match is made; and (h) linking said first client application with said second client application by creating a fourth object that comprises: (i) said new object; and (ii) linking commands for linking said first client application with said second client application.
2. The method of claim 1, wherein said linking comprises the further steps of: (a) utilizing said fourth object as a means of identifying a link between said first client application and said second client application wherein said fourth object eliminates the need to compare said pre-determined subset with one or more subsets comprising said third object for subsequent software application links; and (b) accessing a data set of said second client application by said first client application by requesting said data set through said carrier manager module.
3. The method of claim 1 or 2, wherein said carrier manager module further comprises an OCX environment.
4. The method of claim 2 or 3 as appended to claim 2, wherein said data set is a set of instructions for applying rates to parcels to determine shipping charges for said parcels.
5. The method of any preceding claim, comprising the further step of accessing a data set of said first client application by said second client application by requesting said data set through said carrier manager module.
6. The method of any preceding claim, comprising the further step of accessing a data set of said carrier manager module by said first client application by requesting said data set through said carrier manager module.
7. The method of any preceding claim, comprising the further step of accessing a data set of said carrier manager module by said second client application by requesting said data set through said carrier manager module.
8. A method of interfacing a first software application comprising a first operating system platform with a second software application comprising a second operating system platform, in a data processing system, comprising the steps of: (a) creating a running object table within an OCX control environment; (b) registering said OCX control within said running object table; (c) linking said first software application with said second software application via said OCX control wherein said linking further comprises the steps of: (i) registering a first query from said first software application within said running object table to create a first object; (ii) registering a second query from said second software application within said running object table to create a second object; (iii) identifying a pre-determined subset of said first object and comparing said pre-determined subset with one or more subsets comprising said second object; (iv) linking said first object with said second object to create a third object if said pre-determined subset of said first object matches a subset of said second object; and if said match does not exist, then querying subsequent objects until a match is made; and (d) utilizing said third object as a means of identifying a link between said first software application and said second software application wherein said third object eliminates the need to compare said pre-determined subset with one or more subsets comprising said second object for subsequent software application links.
9. The method of claim 8, wherein said first software application interfaces with a third software application, or a subsequent software application, and comprising the further steps of: (a) registering a third query from said third software application, or registering a subsequent query from said subsequent application, within said running object table to create a fourth object or a subsequent object; (b) identifying a pre-determined subset of said first object and comparing said pre-determined subset with one or more subsets comprising said fourth object or said subsequent object; (c) linking said first object with said fourth object or said subsequent object to create a fifth object if said pre-determined subset of said first object matches a subset of said fourth object or of said subsequent object; and if said match does not exist, then querying subsequent objects until a match is made; and (d) utilizing said fifth object as a means of identifying a link between said first software application and said third software application wherein said fifth object eliminates the need to compare said pre-determined subset with one or more subsets comprising said fourth object for subsequent software application links.
10. The method of claim 8 or 9, wherein said running object table comprises a plurality of objects and wherein each of said plurality of objects contains data identifying one or more links.
11. The method of claim 8, 9 or 10 wherein each application interfacing with said data processing system has an identifying object within said running object table and wherein each application has one or more corresponding objects wherein each of said one or more corresponding objects is representative of said each application and at least one other application.
12. A data processing system for interfacing a first software application comprising a first operating system platform with a second software application comprising a second operating system platform, comprising: (a) operating system means for creating a running object table within an OCX control environment; (b) first registration means for registering said OCX control within said running object table; (c) second registration means for registering a first query from said first software application within said running object table to create a first object, and further for registering a second query from said second software application within said running object table to create a second object; (d) first identification means for identifying a pre-determined subset of said first object and comparing said pre-determined subset with one or more subsets comprising said second object; (e) data processing means for linking said first object with said second object to create a third object if said pre-determined subset of said first object matches a subset of said second object; (f) second identification means for identifying a link between said first software application and said second software application by locating the presence of said third object and wherein said third object eliminates the need to compare said pre-determined subset with one or more subsets comprising said second object for subsequent software application links; and (g) communication means for exchanging data between said first software application and said second software application while utilizing said link.
13. The system of claim 12, wherein said first registration means and said second registration means are co-located.
14. The system of claim 12 or 13, wherein said first identification means and said second identification means are co-located.
15. The system of claim 12, 13 or 14, wherein said communication means comprises a commercial telephone exchange.
16. The system of claim 12, wherein said communication means comprises a direct link between said first software application and said second software application within a common system that comprises co-located components.
17. The system of claim 16, wherein said co-located components comprise: (a) said first software application; (b) said second software application; (c) a first database for supporting said first software application; (d) a second database for supporting said second software application; and (e) a set of modules for performing a specific task wherein said task is controlled by said first and/or said second software application.
18. The system of claim 17, wherein said common system is a carrier manager module further comprising: (a) said OCX control environment; and (b) a bus means for linking said co-located components.
19. The system of claim 17 or 18, wherein said specific task is the application of rating to one or more parcels.
20. A method of linking first and second client applications through a carrier manager module, substantially as hereinbefore described with reference to the accompanying drawings.
21. A data processing system substantially as hereinbefore described with reference to the accompanying drawings.