WO2011020191A1

WO2011020191A1 - Method and apparatus for gps-assisted transport load matching

Info

Publication number: WO2011020191A1
Application number: PCT/CA2010/001278
Authority: WO
Inventors: Brock Eidem; Earl Eidem; Charles Harvey
Original assignee: Qa Technologies, Ltd
Priority date: 2009-08-21
Filing date: 2010-08-20
Publication date: 2011-02-24

Abstract

Software and a computer-assisted method for the location of available transport unit to transport loads between locations. A unit locations database contains periodically updated unit locations and load parameters for at least one truck or other transportation unit. Users can search this database using at least one search parameter to locate available trucks were transportation units. A unit location tracking device transmits the real time or periodically updated location of transport units back to the central database for logging and subsequent searching.

Description

METHOD AND APPARATUS FOR GPS-ASSISTED TRANSPORT LOAD MATCHING This invention is in the field of transport logistics, and more specifically relates to a system and method for the conduct of load matching based upon the acquisition and realtime updating of the GPS locations and load status of transportation units in the field.

BACKGROUND

With increased globalization in the economy there continues to be rapid growth in the transportation industry, as it is constantly necessary to transport goods and resources between jurisdictions and locations. Insofar however as the transportation of products between origin and destination results in line haul activity from the perspective of the transportation companies to ensure that as few empty back hauls as possible take place, and from the perspective of the purchaser of transportation services to the extent that transportation vendors looking to fill otherwise empty backhaul capacity can most easily be identified, better rates can theoretically be obtained. A key issue facing shippers relying on the trucking industry, as well as companies in the trucking industry themselves, is the need to be able to locate within a particular jurisdiction available companies or trucks who are capable of transporting certain loads. Different types of load matching services exist, through whom a shipper can try to locate a truck capable of carrying a load within certain parameters. One of the primary limitations to the use of these load matching services is that they typically firstly requires third-party intervention i.e. the shipper phones the load matching company who in turn locates a truck and makes the connection, so an added layer of administration and cost is included in the transaction. In addition the use of third-party communication such as this draws out the process such that it is more difficult to on a rapid or "just-in-time" fashion conduct such load matching.

One of the other problems that either a shipper who is directly conducting load matching by contacting their preferred shipping providers, or even a load matching company providing load matching services to shippers and trucking companies, which limits the timeliness and availability of such service is the currency of the capacity and loading availability information which is available to the people or the tools which are conducting the load matching. For example it may be the case that by the time a shipper reads about the availability of a particular truck in a particular transport route and makes contact to make a booking that the truck or resource has already been booked otherwise and that the available information simply has not yet been updated. In many cases the availability of these particular transport routes or particular capacities is updated manually by employees of the trucking company themselves and on that basis there is a significant limitation to the currency of the information. If it was possible to provide load matching information that was more "real-time" it is believed that a tool incorporating that type of information would be of great utility in load matching services and even in minimizing the amount of wasted resources by shippers, truckers and load matching services were providers which is spent making multiple calls to try and make transport bookings with providers who have already had their capacity absorbed were booked by other purchasers. A system that provided for relatively realtime load matching capability and capacity information would be desirable. Another benefit of this type of a system or approach would be the environmental advantage, namely that less empty miles would be driven by the transport units in question which would result in less inefficient greenhouse gas emissions.

SUMMARY OF THE INVENTION

In one aspect, a system for locating available transport units to transport loads between locations is provided. The system comprises: a server having an interface connected to a data network; a unit location tracking device associated with a transport unit and operative to: capture a geographical location of the transport unit and transmit the geographical location of the transport unit to the server; and transmit at least one load parameters to the server, a unit location database operatively connected to the server, the unit location database having at least one computer readable memory containing information including: a plurality of unit identifiers, each unit identifier identifying a specific transport unit and associated with a unit location identifier identifying the location of the specific transport unit and at least one load parameter indicating the suitability of the specific transport unit for a transport job, and at least one client computer operative to access the server through the interface and query a suitable transport unit based on geographical location. The server updates the information in the database in response to receiving a transmittal from a unit location tracking device.

In another aspect, a method for locating available transport units to transport loads between locations is provided. The method comprises: receiving a geographical location from a unit tracking device associated with a transport unit; receiving at least one load parameters from a unit tracking device associated with the transport unit; updating information in a database using the geographical location and the at least one load parameter from the unit tracking device; and allowing the database to be queried for suitable transport unit based on geographical location. In another aspect, a memory for storing data for access by an application program being executed on a data processing system is provided. The memory comprises: a data structure stored in the memory, said data structure including information resident in a database used by the application program and including: a unit identifier identifying a specific transport unit; a unit location identifier associated with the unit identifier and identifying the location of the specific transport unit; and at least one load parameter associated with the unit identifier and indicating the suitability of the specific transport unit for a transport job.

In another aspect, a unit location tracking device is provided. The unit location tracking device comprises: at least one computer readable memory containing program instructions; a GPS receiver operative to obtain geographical information; a network interface connection; a human interface for inputting load parameters; and at least one processing unit in response to executing the program instructions operative to: automatically capture geographical location information using the GPS receiver; receive at least one load parameter input from the human interface; and transmit the geographical location information and the at least one load parameter to a database for storage over the network interface connection.

DESCRIPTION OF THE DRAWINGS

While the invention is claimed in the concluding portions hereof, preferred embodiments are provided in the accompanying detailed description which may be best understood in conjunction with the accompanying diagrams where like parts in each of the several diagrams are labeled with like numbers, and where: Fig. 1 is an architectural drawing showing one embodiment of the location database of the present invention; Fig. 2 is a sample of one embodiment of the data which might be contained within the unit location database;

Fig. 3 is a sample of an alternate dataset which might be contained within a unit location database in accordance with the present invention;

Fig. 4 is a conceptual diagram of one embodiment of the system of the present invention;

Fig. 5 is a screenshot of one embodiment of the user interface of the website system of the present invention wherein the user is entering search parameters for use in the execution of a load matching query against The unit location database;

Fig. 6 is a screenshot of one embodiment of a result set, displaying the results of the load matching query being entered by the user in the embodiment of Figure 5; Fig. 7 is a flow chart showing one embodiment of a method for the recordal of a unit location to the location database in accordance with the present invention, where the recordal is manually triggered; Fig. 8 is a flow chart showing another embodiment of a method for the recordal of a unit location to the location database in accordance with the present invention, where the recordal is periodically updated;

Fig. 9 is a flow chart demonstrating the steps of a load matching query in accordance with one embodiment of the present invention.

Fig. 10 is a schematic diagram of one embodiment of a unit tracking device in accordance with the present invention; Fig. 11 is a perspective diagram of a retrofitted personal electronic device containing the unit tracking software of the present invention;

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS The following narrative is intended to generally speaking described the operation of the selected illustrative embodiments of the present invention, for the purpose of outlining or enabling its operation to those skilled in the art.

Terminology:

For the purposes of disclosing the invention it is desired to provide a brief glossary of terminology which is much as anything outlines or enables a description of the type of elements or parties that are involved in the transportation industry and who might use the system, apparatus or method of the present invention. Certain computer terminology is also included in this glossary:

"transport consumer" means a company or individual who has goods that they wish to have transported. For example a company with a warehouse with items to be transported would be a consumer, as would be a manufacturer or even a purchaser of products who is purchasing them FOB the factory or debarcation point. In any event, a transport consumer, as a party involved in transport transactions, is a company wishing to have a load transported. The consumer of transport services might also be a freight broker or other intermediary as freight brokers are contemplated to be one of the primary users of the system of the present invention. Freight brokers would use the system and method such as that disclosed herein to link available shipments with available transport capacity. "transport provider" means a company or entity who provides transportation services. For example a trucking company, railroad or the like. In certain circumstances the transport consumer might also be a transport provider— in the case of a company who for example manufactured or distributed products who had their own fleet of trucks. It might still be desirable in a larger implementation where the transport consumer was also the transport provider to use the system and method of the present invention for load matching purposes. "transport unit" means the actual trucks or other transportation units ~ railcars etc. ~ which are used by a particular transport provider to provide transport services to a transport consumer. In the case of a trucking company for example, as the transport provider, the transport units operated by the company would be trucks and/or trailers.

Prior art:

The tools that are presently available for load matching purposes to those in the transportation industry, both in terms of transportation providers as well as consumers of transportation services are limited. One of the primary limitations in the prior art is that the prior art systems which are available for the purposes of locating empty or available transportation units do not provide real-time availability information. There are website tools available which a freight forwarder or other transport consumer could use for load matching purposes, where for example a transport provider could for example manually enter the availability of their various transportation units, and transportation consumers could then enter as search parameters or even in review of a printed catalog of available transportation lanes etc. identify a particular transportation unit which would be available at the best cost or in the best scenario for transportation of a particular load. The availability of those transportation units can change based on either anticipated or unanticipated factors and in light of the fact that that availability information in the present websites or other printed or electronic systems is all manually entered, it will not be up to date. On that basis parties may endeavor to match a load based on inaccurate information and time and resources will be wasted, and the most ideal transportation matches may not be located.

Providing a load matching database which contains location information as well as potentially other load parameters with respect to one or more transport unit 5s, wherein the location information and/or others of the load parameters in question could be updated on a periodic or relatively real-time basis, would represent a significant enhancement over the present state of the art. Method overview;

Generally speaking the method of the present invention involves capturing in a real-time fashion locationally associated transportation capacity data to a location database such that the user of the system searching that database could locate available transportation capacity based upon the real-time location of the transportation unit in question as well as other potential load or load parameters which might be associated with that transportation unit or the location in question. Geographic unit locations corresponding to at least one transport unit would be captured and recorded to a unit location database, each transport unit and the unit location thereof corresponding to a unit identifier used to identify that information within the database. In certain embodiments of the method of the present invention, in addition to the unit locations, additional load parameters could also be stored to the unit location database along with the unit locations corresponding to the unit identifiers of their related transport units.

Computer software would be used to execute searches of the unit location database and to determine available transport capacity in geographic proximity to a desired location. In addition to geographic proximity to a desired location from which a load was available for transport, additional search query parameters could be used which would compare the load parameters stored within the unit location database, and embodiments of the database where that was the case, to those additional query parameters and allow for refinement of the query search results.

Unit locations of the various transport units would be captured at the transport units by either a unit location tracking device or unit location tracking software installed on a preexisting hardware device at the transport unit, and that unit location information would then be transmitted via a data network for recordal to the unit location database.

There really are two different types of data transactions involved in the practice of the present invention. The first type of data transaction which we will discuss in further detail is the capture of the locationally associated transportation capacity data to the location database in association with a particular transportation unit, and the second type of a data transaction is a searching or extraction transaction where a user could run a search against the location database to identify based either on a particular geographical proximity to the real-time location of a particular transportation unit, and/or one or more other additional load or load parameters entered in that search, to identify with the most geographical and time relevant accuracy available transportation units who could provide transportation services for a particular load or a particular transport consumer. For the purpose of initially sketching out the overall behavior of the system and method of the present invention, we provide the following, in advance of outlining in further detail individual elements of the invention. At the heart of the system and method of the present invention is a location database 1 in which locationally associated transportation capacity data can be stored with respect to at least one transport unit 5. The locationally associated transportation capacity data which is anticipated to be stored with respect to said at least one transport unit 5 comprises at its base the actual geographic location 3 of that unit either at the present time or at a predetermined or preset future time - it is primarily anticipated that this locational awareness will be provided by automated or semiautomated GPS capture in the transport unit 5 itself. The actual location 3 of the transport unit 5 would be saved in the location database 1 in association with a unit identifier 2, so that the particular location or locations 3 in question could be associated with a particular transport unit 5, and particularly in embodiments of the invention where the transport units 5 of more than one transport provider were tracked in the same location database 1 the unit identifiers 2 would become even more important. In addition to a unit identifier 2 and geographically associated transportation capacity data comprising at least a geographical location 3 in respect of each transport unit 5 being tracked by the system 12 or in the location database 1, location database 1 might also contain additional load or load parameters 4 with respect to the particular transport unit 5 and its status. For example, it could be that a parameter 4 which would be stored in the location database in association with a particular transport unit 5 might include a "loaded/unloaded" status flag, either a fixed or dynamic indication of the type of trailer which that transport unit 5 might currently be pulling or have available, other specific equipment parameters such as the availability of particular weight pulling capacity, electrical requirements etc. which might be relevant for the purpose of selection of a particular transport unit 5 for a particular transportation job, or any number of other equipment based or other types of status or load parameters 4 which could be used either for the purpose of refining a search or making a final vendor/customer selection.

Either based on the manual triggering of a submission of a location packet comprising a geographical location along with a unit identifier and possibly one or more other load parameters 4, or based upon a periodic automated update location packet containing the same types of information in an embodiment where the location was being automatically updated in the location database with respect to a transportation unit from time to time, the geographic location as well as other parameters with respect to a particular available transportation unit would be stored to the location database. A website system 12 or other software system would then be provided which would allow for users to search the location database 1 based on numerous parameters including geographical proximity of a particular transport unit 5 to a particular location where a load might exist that needed to be hauled. In addition to assessing geographical proximity of the search, the search could also be refined using the other load parameters 4 which might be stored in the location database with respect to a particular transport unit 5. By allowing for automated or manual ongoing real-time updates to the location database 1, the results of the searches exercised or performed against the location database 1 would be more time relevant to the user in terms of identifying the best possible transport capacity with respect to a load that they wish to arrange for the transport of. As transport units 5 become unavailable because they pickup additional or new loads, the update of the location database 1 in that respect would take them out of available inventory, so to speak, and as new transport units 5 became available with transport capacity in particular locations those would be added to the inventory available for search purposes in the location database 1.

In addition to the concept of the location database 1 itself, the invention includes a hosting environment in which the location database 1 would be hosted and which was capable of receiving location transmission packets from one or more transport unit 5s. This is again contemplated to possibly be a website system 12 or website interface but could also be any other type of computer and communications interface capable of receiving data packets transmitted from transport units 5 in the field.

Each transport unit 5 is anticipated to be equipped either with a purpose built unit location tracking device 6, which would be a hardware device capable of assembling a location packet for transmission to the location database 1 of the present invention, which location packet would contain the geographic location of the transport unit 5 in question, along with a unit identifier 2 and or any other load parameters 4 which were desired to be transmitted or updated.

Having reviewed briefly the general concept of the present invention will now go on to discuss in further detail certain aspects of the invention which will help to better understand the full scope and intention hereof.

Unit Location database:

Referring to Figure 1 , there is shown a location database 1. The specific data structure of the location database 1 could vary, and various types of configurations will be obvious to one skilled in the art of relational database creation, but for the purposes of demonstration of the concept of the present invention, the embodiment of the location database 1 shown in Figure 1 shows a designation of three different types of data that it is anticipated would be stored in certain embodiments of the location database 1.

There is shown a database key, namely a unit identifier 2 corresponding to each transport unit 5 in respect of which the system is being operated. A unit identifier 2 would correlate location data 3 or other information within the location database 1 with a particular transport unit 5. The second key piece of data or information which it is anticipated would be stored within the location database 1 with respect to a transportation unit 5 is actual location data 3. The location data 3 is a geographic location which might either be correlated to a particular GIS or mapping system or it could be a latitude and longitude location etc. The location data 3 with respect to a particular transport unit 5 which would be stored within the location database 1 would be used for searching on the basis of geographic proximity.

The particular data format of the location of a particular transport unit 5 could vary based upon the type of mapping and GIS components used within the remainder of the system of the present invention and will be understood that any particular type of a format of the location data 3 which could be stored within the location database 1 and used in this fashion is contemplated within the scope hereof. Figure 2 demonstrates one example of the data which might be maintained within a unit location database 1 such as disclosed so far, containing unit identifiers 2 and unit locations 3 with respect to the transport units 5 of a single vendor. In this particular case the sample dataset contained within this Figure includes a unit number 2 for a plurality of transport units 5, and the geographic coordinate 3 related to their locations. In this particular case for demonstration purposes the nature of the unit locations 3 which are stored in the database 1 are longitude and latitude coordinates. These coordinates could be used by a mapping application to plot the availability of a particular transport unit 5 and proximity to a particular longitude and latitude and to determine the best available transport units 5 on this basis. As outlined elsewhere herein the nature or type of geographic coordinates could vary dependent upon the nature of the mapping components used for the generation of the proximity searches and proximity searching component of the method of the present invention. For example if a particular type of a proximity search engine required a particular type of geographic coordinates to be stored that might be the type of coordinates which would be stored in the unit location database 1 for use in accordance with the particular embodiment of the invention, whereas if another type of a proximity search engine which might be chosen by either the user or by the programmer at the time of rendering of the system of the present invention uses a different type of coordinates or made different types of proximity searching possible based upon the type of coordinates which were stored, the types of coordinates could be varied.

The final item which is demonstrated in the embodiment of the location database 1 of Figure 1 are other load parameters 4. In addition to storing a geographic location 3 with respect to a transport unit 5, other load parameters 4 may be stored with respect to that unit within the location database 1 [and correlated with the corresponding unit identifier 2], so that those additional load parameters 4 with respect to a particular transport unit 5 could be used in searching the location database 1. At a basic level the data which is contained within the location database 1 with respect to each transport unit 5 tracked therein is the information which would be required to quickly identify the geographic location 3 of particular available transport units 5 who could take loads for transportation. Figure 3 is intended to demonstrate an alternate sampling of data which might be contained within one unit location database 1 in accordance with the present invention. This particular data sample is intended to be useful in demonstrating some of the more elaborate embodiments or searches which could be conducted in accordance with the method of the present invention.

Firstly, the data in this particular set of information corresponds to transport units 5 of more than one vendor. The unit identifier 2 which is included within that table is actually shown as a two-part unit identifier 2 in which both the vendor and then the individual unit number are identified. In the actual electronic format of this information obviously this may be appended together or in some other way stored but generally speaking this information would still form the database key whereby each transport unit 5 which was being tracked within the system of the present invention would have its own unit identifier 2 corresponding thereto.

In addition to the unit identifier 2 the next item which is shown in this Figure is the unit location 3 of each transport unit 5 therein. In this particular case rather than longer to and latitude which were shown in Figure 2, the unit locations 3 which are being stored are basically towns or cities, since in many applications and iterations of the system and method of the present invention to simply store the town or city rather than a more precise geographic coordinate be sufficiently granular for these purposes. It is contemplated that the GIS or mapping software or proximity searching algorithm which would be used in conjunction with this type of the unit location 3 would be able to calculate at a city or town level the proximity of the transport units 5 in question to a desired city or town. Necessary modifications to the remainder of the invention to practice it in this way will be considered within the scope hereof.

Also included in this table in addition to the unit location 3 are three examples of load parameters 4 which could be used to further refine searches of the unit location database 1 in seeking to identify available transport capacity. There is shown a loaded flag, which would be a dynamic load parameter 4 which could either be updated by the setting of the user input on the unit location tracking hardware or software, or otherwise through the website system of the present invention. There is also shown a route endpoint 4, which might represent the destination of the transport unit 5 in question to pick up its next booked load and would signify to the searcher of the database the general direction in which that particular transport unit 5 is headed. Finally, there is also shown a trailer type 4-if a particular user conducting a search of the database 1 need to find a particular type of a truck and trailer combination they could use this type of a load parameter 4 to further refine their searching of the database to yield only the results they need.

Some or all of the unit identifier 2 could also be used as a restricting query parameter-for examples certain searchers of the database 1 may have a vendor preference and on that basis they could use the vendor code has another parameter of their query to narrow down or re-rank their search results. As discussed above, the specific format and structure of the location database 1 and the environment or tools used to create and administer that database 1 are all contemplated within the scope of the present invention insofar as the specific types of tools or data structures which could be used will be obvious to one skilled in the art of database design.

It is also contemplated that portions of the location database 1 might in certain implementations be segregated either in separate data structures, such that for example rather than having a single data structure 1 which contained all of the unit identifiers 2, location data 3 and load parameters 4, separate databases could contain each and be linked in a typical relational fashion, or it may even be the case that the location database 1 of the present invention as outlined herein might be segregated in multiple parts on multiple database servers.

Any embodiments of software and hardware which would provide a data structure which was capable of efficient capture of the location data 3 and other load parameters 4 as outlined elsewhere herein and allowing for search of that data in accordance with the searching aspect of the present invention, are contemplated within the scope of the present invention. Unit identifiers:

As outlined above, the first piece of information which would be stored and structured within the location database 1 is a unit identifier 2 in respect of each transport unit 5 in respect of which information is to be captured or maintained within the location database 1. The unit identifier 2 might be for example the unit number assigned by a transport vendor to a particular transport unit 5, or some other manually assigned identifier which could be used to distinguish for the purposes both of relational database configuration as well as for the purposes of display to the user a differentiation between transport units 5.

In a circumstance where the unit identifier 2 was really transparent to the user and was maintained "under the hood" by the remainder of the present invention, a logical appearance to the unit identifier 2 might not in that circumstance be necessary and any matter of random generated, time stamped or other database keys could be used as unit identifiers 2 as well. The use of a central key in a relational database is obvious to those skilled in the art of database design and on that basis any modification to this general rationale or approach, as well as any modification to the methodology used to actually create or assign those unit identifiers 2 are contemplated within the scope of the present invention.

It is specifically contemplated that the system of the present invention would be used to aggregate transport availability information with respect to transport units 5 of more than one transport operator. On that basis one part of the unit identifier 2 may also be to identify the actual vendor or owner or operator of that unit so that multiple units owned by different vendors could share similar unit identifiers 2 without breaching the key restrictions on the database. Addition of more user information or a more elaborate unit identifier scheme to the database 1 to allow for more sophisticated user display or reporting features or to allow for larger groups of vendors or customers to use the system and database of the present invention are all contemplated within the scope hereof.

Unit locations:

Beyond the unit identifier 2 which is used in the location database 1 in respect of each transport unit 5, the other primary piece of information which is necessary to be stored within the location database 1 with respect to each transport unit 5 is information corresponding to the unit location 3. The actual geographic location of the transport unit 5 is necessary for determining load matching in accordance with the remainder of the method of the present invention.

The unit location 3 stored within the database 1 will take the form of a electronically formatted set of mapping coordinates which could be used for the purpose of determining and/or displaying a map with the particular geographic location 3 of the transport unit 5 in question, or also for the purpose of determining distances etc. in a more elaborate load matching application in accordance with the present invention.

Both the type of coordinates which are captured within the database as well as the method of their storage will be dictated to a degree by the type of location hardware used on the transport units 5 i.e. GPS coordinates, or some other mapping system, as well as to a degree by the type of mapping software components used in the remainder of the system 12 of the present invention to conduct geographical proximity searches. Many different types of data formats for the capture and storage of geographic locations or coordinates such as this are available and all such types of coordinates and methods of storage or formats of storage are contemplated within the scope of the present invention.

The system 12 of the present invention would need to include a module or the necessary instructions to allow for the capture of unit location updates when received from various transportation units 5 in the field, and the logging of those unit locations 3 into the unit location database 1. The type of software which would be used for the capture and cataloging of these unit locations 3 into the database 1 might be modified depending upon the type of location capture hardware which was being used on the transport units 5 or other parts of the network infrastructure within the system and apparatus of the present invention and again all such necessary modifications to accomplish the objective of capturing unit locations 3 to the database 1 upon receipt of a transmission thereof from the hardware located within the transportation units 5 themselves is contemplated within the scope of the present invention.

Load parameters:

The third type of data which it is intended to capture and store within the location database 1 are load parameters 4. Load parameters 4 are any other search characteristics or search parameters other than the physical unit location, which might be used to refine or properly identify the suitability of a particular available transport unit 5 for a particular transport job. For example, if a particular transport unit 5 has a higher or lower than usual pulling power, specific special equipment or electrical or the like, those types of information could be stored so that for example someone searching the location database 1 for a particular available transportation unit 5 could limit their search to units 5 which had the necessary pulling power or the like, or otherwise satisfied their needs.

It is specifically contemplated that both static and dynamic load parameters 4 could be stored within the unit location database 1 with respect to a transport unit 5. What is meant by static load parameters 4 would be load parameters 4 which did not change over time such as fixed load weights or capabilities etc. Dynamic load parameters 4 could be load parameters 4 which changed from time to time and which would be desired to update on a real-time basis. For example, dynamic load parameters 4 might include loaded or unloaded status of the transport unit 5 in question, limitations on the length of a trip which could be accepted by the transport unit 5 [for example if they were headed towards picking up another load the endpoint of the available or unloaded status of the unit could also be another dynamic load parameter 4 which was useful for storage to the database 1 for use in data extraction or selection transactions there from]. It will be understood that all types of dynamic or static load parameters 4 which would allow for the more precise identification of available load capacities on various transport units 5 tracked within the website system 12 of the present invention are contemplated within the scope of the present invention.

The simplest embodiments of the location database 1 and remainder of the method and apparatus of the present invention are contemplated to store only basic load parameters 4 such as for example an indication of whether or not the transport unit 5 in question is loaded and unavailable, or unloaded and available, at a particular time. It will be understood however that more elaborate types of load parameters 4 could be also stored within the structure of the location database 1 and that on some level the addition of more load parameters 4 to the information available for people searching the location database

1 will enhance the depth of the results and the search interface. Any type of data which can either be mechanically captured from the transport unit 5 by the location capture hardware 6 and transmitted to the location database 1 , or which could be statically programmed to the location database 1 with respect to a particular unit identifier, are all contemplated to be types of load parameters 4 which could be used in this way.

Some of the other load parameters numeral for which are contemplated might include jurisdiction limitations, where a transport unit 5 was not able to travel within particular jurisdictions or was limited to a particular jurisdiction, so that that type of a limitation to be included in a search. Also in the case of less than Ml load [LTL] freight some of the load parameters 4 which might be calculated or captured could include the percentage of availability of a trailer which was available.

In a further aspect, the system may allow for the creation of different user profiles or different load profiles with respect to an individual transport unit 5, so that the operator could basically switch a number of load parameters to a predetermined set of values by the selection of a particular profile. Addition of this type of a concept and ability to the software of the present invention will be something which can be accomplished by one skilled in the art of software design and as such all such necessary attendant modifications to the concept are contemplated within the scope of the present invention as well.

System architecture: In one embodiment, the present invention comprises a system for GPS assisted transport load matching. The system comprises a unit location database within which a unit location is stored in respect of at least one transport unit. In certain embodiments at least one additional load parameter beyond the unit location is stored in the unit location database in respect of the at least one transport unit. Load parameters and unit locations are stored within the unit location database in association with a unit identifier, which beyond corresponding to the transport unit in question is effectively the database key.

In addition to the unit location database, which is hosted on a computer capable of receiving the transmissions of unit locations and are with respect to the at least one transport unit via a data network, there is provided in each at least one transport unit a unit location tracking device or software which is capable of capturing either by GPS or some other locationally aware network or methodology the geographic location of that corresponding transport unit and transmitting the geographic location of that transport unit in addition to additional load parameters were desired, in association with the unit identifier or other identification information corresponding to a unit identifier within the unit location database, via a data network back to the unit location database for recordal.

The system also comprises a website system or other computer software via which a user can conduct a search of the unit location database to identify transport units which are in unit locations geographically proximate to a desired location, and/or which may also correspond to additional load parameters which are desired. Unit locations could be recorded to the unit location database either on demand or at such a time as they were triggered by the operator of the transport unit, or they could be automatically or periodically updated by the unit location tracking hardware or software within the unit without the need for operator intervention.

Referring to Figure 4, there is a demonstration of one embodiment of the system of the present invention. The system which is shown that Figure includes a number of different components which are demonstrated for a general conceptual understanding of the system architecture and the practice of the method of the present invention. Firstly there are shown two different communication networks in that Figure. There is shown a GPS satellite array or network 9 which is used by hardware within various transport units 5 identify or capture the geographic locations of those units 5, and there is secondly a data network 11 by which the transport units 5 transmitter unit locations for recordal to the location database 1 as well as by which in the embodiment shown users of user computers 20 can access the website system 12 which is shown for the purpose of executing searches against the location database 1. A wireless network tower 10 is shown operatively connected to the Internet or TCP/IP cloud shown at 11 and by which the various transport units 5 and their related hardware would communicate with the unit location database 1. In addition to showing the GPS network 9 and the wireless and data networks 10 and 11, there are shown in this particular case three transport units 5. Each of those transport units 5 as outlined in the general terminology and definitions above represents a truck capable of carrying a load of some kind. Different types of transport units 5 including railcars, shipping containers etc. could also be contemplated within the scope of the present invention.

Each of the transport units 5 is equipped with either unit location tracking hardware device or unit location tracking software hosted within a pre-existing electronic device [not shown], and those devices are capable of capturing from the GPS network 9 the location of the transport unit 5 and transmitting that unit location for recordal in the unit location database 1 via the network 11.

Also shown in this particular Figure are two user computers 20 which would be the interface by which users would search the unit location database 1 four available transport units 5 close to a desired geographic location which may or may not satisfy other additional load parameters as well. The details of the website system 12 and the user computers 20 and their interaction is outlined in further below in the following section.

Website system: The unit location database 1 will be connected to a software system whereby users, which might either be transport customers or transport vendors, could execute search transactions against the unit location database 1 for the purpose of locating available transportation capacity for load matching purposes. A number of different types of computer software systems can be contemplated which would accomplish this objective, both in terms of desktop computer software with a networked database connection for search purposes, or an Internet website or client/server based software system which is more likely than not the preferred means of delivery of the system and method of the present invention.

Figure 4 includes an architectural drawing of one embodiment of the website system 12 in accordance with the present invention, wherein the user can execute a load matching search transaction against the unit location database 1.as will be immediately apparent to anyone skilled in the art of network infrastructure and software design, there are virtually endless ways of configuring different hardware and software combinations to render or practice the method of the present invention and as such the outline of the hardware configuration here is not intended to provide any restriction on the scope of the allowable subject matter of the present invention insofar as any such modification to the design of the infrastructure of such a system 12 does not depart from the overall scope or intention of the present invention and its use in the provision of real-time updated and geographically proximate load matching searches. Referring to the embodiment of the load matching website system demonstrated in Figure 2, there is shown a typical infrastructure or website environment which will be understood to those skilled in the art of Web infrastructure design. There are firstly shown a plurality of client computers 20 each of which would be equipped with a browser capable of accessing content served from the website system 12 of the present invention as well as from other websites or servers connected to the Internet. The network connection of those client computers 22 the website system 12 of the present invention and elsewhere is demonstrated by the TCP/IP cloud shown at 11.

Within the software system 12 there is shown a content server 13 which includes a content store 15 and which would be responsible for serving templates and content related to searches and other interactions of users and their computers 20 with the website 12. The web serving software components of the server 13 are shown at 22.

The user computers 20 would browse to the website 12 and would interact by serving of content from the servers 13. For example a search form could be presented at the user computer 20 by the server 13, through which the user of the computer 20 could interact with the searching tool of the present invention by providing particular search parameters for use in the execution of a load matching search against the unit location database 1 , and reviewing search results etc. The software within the server 13 would be capable of accessing for searching purposes the unit location database 1. The unit location database 1 could be hosted on the server 13 or on another server which was operatively connected via a computer network to the server 13. In this particular case the unit location database 1 and a related database administration software components are shown within the same server 13 but it will be understood that distribution of the unit location database and related database administration software components 1 21 or more additional servers which were operatively connected to the Web server 13 of the website system 12 of this Figure are all contemplated within the scope of the present invention and do not depart from the intent hereof.

As outlined above, in addition to a website system 12, the software system 12 might also alternatively be a desktop or locally installed server-based software application which could by way of the network connection on the Internet or otherwise access the unit location database 1 for the execution of queries captured from users.

The system 12 where it was a website or client/server-based system might also be optimized for delivery to mobile devices rather than to desktop computers— cosmetic adjustments to allow for delivery of the application in that fashion would be obvious to one skilled in the art of website or software interface design and all such modifications are contemplated within the scope of the present invention. The software components contained within or operatively connected to the Web server 13 would include mapping components which were capable of rendering queries and results about available transport units 5 within geographic proximity of the desired location. What would be required in order for this to work properly with the ability for the mapping components to parse user input about a desired location at which their load was available for pickup, as well as to interface with or parse unit locations 3 contained within the unit location database 1 and then use that information in the creation of a geographic proximity search result. Dependent upon the user's desire if they were to specify one or more load parameter query limitations in the entry of their search to the website 12, those additional load parameters numeral for or query limitations could be used or matched against the load parameters 4 stored within the database 1 with respect to the transport units 5 cataloged therein.

Location recordal transactions:

There are two different primary types of data processing transactions which will rely upon the unit location database 1 in the practice of the invention. The first data processing or handling transaction, which we'll described in further detail, is a location recordal transactions, wherein a unit location 3 will be captured at a transport unit 5 and transmitted for recordal in the unit location database I in respect of that particular transport unit 5. There are two different types of data capture workflows with respect to the capture of the unit locations of a transport unit 5, which are demonstrated in Figures 7 and 8. The two different types of data captures which are contemplated are either the preparation or transmission of a location update from the transport unit 5 in question on demand, or in the second circumstance where the transport location update is provided to the location database on a periodic but automated basis.

Referring first to Figure 7 there is shown a flow chart for an "on-demand" location recordal transaction, whereby the unit location 3 would be transmitted from whatever unit location tracking device 6 or software 8 was being used within a transportation unit 5 upon being triggered to do so by the operator or in some manual fashion.

In this type of the data recordal transaction, it is basically the case that either by user intervention or operator triggering, updated unit location 3 data would be transmitted for recordal to the unit location database 1 with respect to a particular transport unit. Shown at Step 7-1 of this Figure is the operator triggering of this unit location 3 update to the database. At the time of triggering of the database update, the up-to-date location of the transport unit 5 in question is acquired by the unit location tracking hardware or software and its GPS or other GIS interface. This is shown at Step 7-2. Shown next at 7-3 is the assembly of a transmission packet 30 by the unit location tracking hardware or software 6 or 8 for transmission to be recorded in the unit location database 1. The transmission packet 30 could be a data file or data packet of many different formats or types dependent upon the nature of the data network being used for communication as well is even perhaps being dependent upon the nature of the GIS interface from which unit location 3 data was being captured. The packet 30 would need to at its base include information which could be parsed by the software administering the database 1 into a relevant geographical location coordinate as well as a unit identifier 2 with some kind which would either correspond directly to the unit identifiers 2 already used within the database 1 or could be cross-referenced to another table or data source within or accessible to the database 1 upon receipt of the packet 30.

The transmission packet 30 is shown being transmitted to the database at 7-4 in this Figure, and finally atStep 7-5 the packet 30 is parsed out into unit location 3 data as well as necessary unit identifier 2 data for recordal to the database 1. Each time a transmission packet 30 such as this corresponding to a particular unit identifier 2 were received by record to the database 1 , the currency of the contents of the database 1 for load matching purposes and searching purposes will be refreshed, yielding a database of significant additional utility over those available in the prior art.

In certain cases, as will be outlined with respect to the following Figure as an alternate embodiment, additional load parameters 4 would also be capable of being stored within the unit location database 1 , and in those cases those additional load parameters 4 could either be statically programmed into the database 1 with respect to a particular unit identifier 2, or could be captured at the transport unit 5 and encoded within the transmission packet 30 for transmission to the database 1 and eventual recordal to the database with respect to that particular transport unit 5.

Referring next to Figure 8 there is shown an alternate flow chart of a location recordal transaction in which automated or periodic location updates are being provided to the database 1 without the need for user triggering or intervention. It will be understood that the nature of a periodic update could either be such that it would be triggered on a time basis or there could be other events or conditions based upon which the unit location tracking hardware or software could automatically triggered the submission of a unit location 3 update to the database 1. Shown first at Step 8-1 is the detection of a trigger condition. If it is determined by the software in question that it is the appropriate time to trigger the submission of a unit location 3 update, then the remainder of this flowchart would be triggered.

Upon determination of the existence of a trigger condition resulting in the need to prepare a unit location 3 update for transmission to the database 1 the unit location tracking hardware or software would again acquire GPS location for the transport unit— the acquisition of the geographic location of the transport unit 5 is shown at Step 8-2. As outlined above in certain embodiments including that one shown in this Figure additional load parameters 4 could also be stored within the database 1 with respect to at least one of the transport units 5 in question. The load parameters 4 could either be static load parameters which were hardcoded or stored within the database 1, or could be dynamic load parameters 4 which changed and which would be captured or generated at the time of generation of the remainder of the location update for the database 1. In this case, shown at Step 8-3, dynamic load parameters would be acquired by the unit location tracking hardware or software and would be incorporated into the transmission packet 30 as it was assembled, 8-4, for transmission and recordal to the database 1.

The transmission packet which as outlined above would be a data transmission of an indeterminate type or format so long as it included unit identifier 2, unit location 3 and/or load parameters numeral for information, would be transmitted via the data network, shown at Step 8-5, to the unit location database 1 or two the hardware hosting that database, where the transmission packet 30 would be parsed out into the information contained therein and recorded to the database 1, shown at 8-6.

It will be understood that variations on these general types of data recordal routines would be obvious to one skilled in the art both of data acquisition in circumstances such as this as well as in terms of computer programming and the any modifications to these general routines which resulted in the same end objective of capturing and recording a GPS or other GIS coordinate for at least one transport unit 5 to a unit location database 1 in accordance with the remainder of the system and method outlined herein will be within the scope of the present invention.

Location search transactions:

The transaction which is at the heart of the present invention is a location search transaction, which effectively comprises the execution of a query against the unit location database 1 based upon geographical proximity of available transport units 5 to a desired originating transport location and/or other load parameters 4.

Referring to Figure 9 there is demonstrated one embodiment of a load matching query workflow against the database 1. There is shown first at Step 9-1 the user data inputs, where the user enters the terms of their query 31 for execution against the unit location database 1. In the instance where the user interaction with the system is by way of a website system 12, this data entry might take place by way of a web form or the like. Where the software being used for searching the database 1 was not part of a website there could be an alternate interface.

Once the terms of the query 30 have been entered, which would typically be to specify a geographic location and proximity to which it was desired to locate available transport capacity and/or in embodiments where additional load parameters numeral for or permitted within the database 1 additional load parameters numeral for query restrictions could also be selected,, a query would be executed against the database 1, to return a result set 32. This is shown at 9-2.

Finally, the results set 32 would be served or displayed to the user at their computer 20 or display. This is shown at 9-3. Additional user flexibility could be provided by allowing the user during the display of the results set 32 to re-rank or otherwise analyze the information displayed within the results set.

User interface:

Figures 5 and 6 are two samples of webpages which could be used in some embodiment of the website system 12 of the present invention, Figure 5 being a web form in which a user is asked to select or enter their preferences for the execution of a search against the unit location database 1 , and Figure 6 being a sample of a results screen, using the query parameters selected in the form demonstrated in Figure 5, run against the sample data set shown in Figure 3.

Based upon the vendor preference expressed by the user in the web form shown in Figure 5, and the approximate similarity in geographic difference between Chicago and Louisville with Indianapolis Indiana, the results in Figure 6 are shown for demonstrative purposes. It will be understood that many types of far more elaborate input and output routines can be contemplated that these two snapshots are merely shown for the purpose of demonstrating the general concept which is intended here.

Transport capacity searching software:

In addition to the website system 12 and related computer software components outlined above, the method of the present invention, which comprises searching a unit location database 1 which is updated in real time for transport units 5 corresponding to a series of search query parameters including at least geographic proximity to a particular location as well as perhaps at least one additional load parameter, could be accomplished using a freestanding computer software package rather than a website system 12. A computer program could be provided for installation on the local desktop computer or in a local client/server environment which could either access or remotely hosted unit location database 1 to execute queries their own, or could on the hardware on which the software was hosted also host the unit location database 1 and receive the transmissions of unit locations 3 from at least one transport unit 5 for recordal to that database 1.

Desktop or client/server computer software package which will accomplish these objectives and carry out the method of the present invention are all contemplated within the scope hereof regardless of method modifications which may be made that would be obvious to one skilled in the art of computer or database programming.

As well, a standalone computer software package that either hosted its own unit location database 1, including whatever necessary software components were required for the receipt and recordal of unit locations 3 to that database, or a computer software package which would remotely connect via a computer network to a remotely hosted unit location database 1 for the execution of queries in furtherance of the method of the present invention are all contemplated within the scope of the present invention.

Unit location tracking device:

As outlined elsewhere herein one of the key elements of the present invention is the fact that by including unit location information 3 which is relatively up to date in a real-time fashion within the database 1, using the system of the present invention to view or extract unit location information or otherwise support load matching decisions will represent a significant enhancement or improvement over the current state-of-the-art in this area. In order to provide up to date unit location information 3 and/or load parameters 4 within the unit location database 1 corresponding to various transport units 5 being tracked therein it will be necessary to either provide purpose built hardware within the transport unit 5, or it is also contemplated that in certain applications a software update or addition to a pre-existing piece of hardware could be used.

In one embodiment of the present invention it is contemplated that a purpose-specific unit location tracking device 6 would be provided within each transport unit 5, or at least within some transport units 5 within the system, which was capable of capturing in an automated and real-time fashion the geographic location or unit location 3 of the transport unit 5 and transmitting that information potentially along with other load parameters 4 back to the remainder of the system 12 for cataloging into the unit location database 1 and use in load matching applications therein.

Referring to Figure 10 there is shown a simplified schematic diagram of one embodiment of a unit location tracking device 6 in accordance with the present invention. The general concept of the design of this device 6 is that it is a transmit capable GPS device which is capable of capturing and transmitting the geographic location or GPS coordinates of the device 6 when triggered to do so.

In this embodiment, in addition to a standard CPU 16 and related circuitry, the unit location tracking device 6 comprises a powered electronic device with a GPS receiving radio 17 and the necessary other chipset and electronic instructions to capture or render a geographic location of the device using the GPS satellite network. For the sake of completeness many standard circuits or components and electronic device are also shown here including the ROM, RAM, CPU clock etc.

Insofar as the method requires the ability for the unit location tracking device 6 to transmit either upon demand or periodically a location of the device 6 and the related transport unit 5, it is necessary for that device to have at least one way connectivity to a data network 11 by which data can be transmitted for eventual cataloging to the location database in question. It is contemplated that in certain circumstances it may be the case that the satellite equipment contained within the device 6, used for the capture of GPS information, rather than being a receiver alone could be a transceiver and could allow for the transmission of burst data packets back on a satellite network. It is likely however that the actual data transmission could more cost-effectively be accomplished using a terrestrial data network. It will however be understood that any type of a data network which allowed for transmission of a data packet from the unit location tracking device 6 which packet would contain in some way the unit identifier 2 associate with that transport unit 5, location data 3 and possibly additional load parameters 4, which packet or transmission could eventually be parsed for cataloging into the location database 1 upon arrival at the location database 1 and remainder of the system 12 of the present invention, are contemplated within the scope hereof.

In the case of a wireless telephone modem or in other applications various network protocols could be used for communication between the unit location tracking devices 6 and the remainder of the system 12 - what is shown in these Figures is a TCP/IP connection but it will be contemplated that in other implementations of the system and method of the present invention other open or proprietary communication protocols or networks could also be used without departing from the intention or scope of the proposed invention.

Beyond the ability to capture a geographic unit location 3 and transmit that back to the remainder of the system 12, the unit location tracking device 6 may also require a human interface of some kind, whether that be a display and keyboard or even something as simple in a very basic implementation is switches or buttons the status of which the device would be capable of communicating basic load parameters 4 back to the system 12 along with the geographic location 3 of the transport unit 5 in the same data packet, so that the real-time unit location information 3 which is stored within the database 1 includes up-to-date load parameters 4. The load parameters 4 as discussed elsewhere herein could be an indication of whether the transport unit 5 was loaded or unloaded, or whether there were other particular limitations or capabilities to that particular transport unit 5 which might change during movement toward during transport such that they would be something you would want to update on ongoing basis for display to users of the remainder of the website system 12 of the method of the present invention in transport or load matching applications. As outlined above, static load parameters 4 could be stored within the database 1 with respect to a particular transport unit 5, such as for example the weight of a load which could be transported, available special characteristics of the transport unit 5, or even particular licensing limitations on the transport unit 5 which would limit or expand the scope of types of loads which could be transported by that transport unit 5. Dynamic load parameters 4 are the ones which are contemplated here for which a human interface might be necessary on the unit location tracking device 6. Dynamic load parameters 4 as outlined elsewhere herein are load parameters 4 which could change and could does not be statically programmed into the database 1 with respect to the applicable transport unit 5. In a most basic embodiment of the hardware for example it could be the case that the unit location tracking device 6 included a switch which could be switched by the operator of the transport unit 5 between a loaded and unloaded position so that that information could be communicated back with data packets to the website system 12 of the present invention for incorporation in the remainder of the information stored within the unit location database 1 with respect to that particular transport unit 5, and then both static and dynamic load parameters 4 which have been updated by the operator of the transport unit 5 a real-time basis could be incorporated into various search transactions upon the database 1. Dependent upon the type of hardware which was being used for the unit location tracking device 6 it may also be the case that rather than the more basic embodiment including simply a couple of indicator switches or buttons for the capture or update of basic dynamic load parameters 4, the unit location tracking device 6 might alternatively contain for example user display and keyboard or other standard electronic human interface device, along with the necessary software within the remainder of the unit location tracking device 62 drive and obtain data from same, and that that type of the human interface device 19 is also contemplated within the scope of the present invention. In the embodiment shown in Figures 5 and 6, human interface device 19 is a simple switch which can be activated in one way or the other to indicate the loaded or unloaded status of the transport unit 5 in question as a dynamic load parameter 4 for communication back to the system 12 of the present invention along with location updates on a regular basis.

The unit location tracking device 6 could either be connected to power within the transport unit 5, or could be battery powered.

Design of GPS location capture equipment will be known to those skilled in the art and the design of the device capable of capturing a GPS location and transmitting it via a computer network to a remote location for capture or logging regardless of the specific implementation of the device is all contemplated within the scope of the present invention.

Retrofit device software: It would also be possible to modify another hardware device which was already being used in other related GPS associated transport logistics or maintenance applications to support the method of the present invention. If for example some type of GPS location tracking device was already being installed in the transport unit 5 in question, which was capable already of capturing a GPS location and or transmitting that back to a central station, the modification of that hardware device to be used in the practice of the present invention might simply comprise a modification to the software or the firmware contained within that device to allow for the capture of location data and creation of location data packets for transmission and logging back to the location database 1 in association with the remainder of the present invention.

In certain cases there is already GPS aware logistics or tracking hardware being installed in many transportation units and simply modifying the hardware or its software to also accomplish the necessary steps for the practice of the method of the present invention in addition to its other pre-existing purposes will be a simple way of adding this capability to pre-existing hardware configurations.

Beyond a purpose built unit location tracking device 6 such as is described above, there is another means that is contemplated of providing the necessary data capture and transmission capability at the transport unit 5. Specifically rather than providing a purpose built unit location tracking device 6, it is contemplated that a software component or add-on could be created which could be used or installed in a pre-existing personal electronic device, such as a PDA or cell phone, provided that the device was capable of capturing locational information and had the necessary processor power and transmission capability to generate a location data packet and transmit same for logging to the location database

Referring to Figure 11 there is shown a PDA device 7 which is one type of a device which is now available in the marketplace which may have the necessary hardware capabilities to capture locational information with respect to a transport unit 5 and transmit that for logging to the location database. Any type of a PDA, cell phone or other electronic device which was capable of capturing location information and assembling and transmitting it back to the remainder of the system 12 of the present invention will be understood to be contemplated within the scope of the present invention.

In addition to GPS awareness or another method of capturing automatically coordinates or location which could be compiled or transmitted back to the location database 1, the device 7 would also need to be capable of transmission of data to a network through which data packets could eventually be converted or transmitted back to the location database 1 or the remainder of the system 12 of the present invention. It is again specifically contemplated that in the context of a PDA or cell phone device 7 which had a pre-existing network data modem or other similar connection it would be simple for the device with proper software to transmit a data packet over that network 11 for capture or logging to the location database 1. The primary component which is required or contemplated to be added to the device 7 in this context is a software component which would be capable of causing the capture of location data by the PDA or other device 7, and the subsequent assembly of a packet or transmission over a data network 11 for logging to the location database 1 in respect of the transport unit 5 to which that device 7 was associated. Creation of software which would allow for the use of a PDA device, cell phone, Blackberry TM device etc. as the unit location tracking device 6 in the remainder of the method of the present invention, to either upon triggering or in a periodic update fashion capture the current geographic location of the device 6 and its associated transport unit 5, along with transmitting any other load parameters 4 or updates which might be required, for cataloging back into the location database 1 of the present invention are all contemplated within the scope hereof.

The creation of a software unit tracking component for use with a smart phone, laptop computer or other electronic device which might already exist are being used on the transport unit 5 is contemplated to be the primary means of rapid and broad deployment of the method of the present invention. Many smart phones or other electronic devices are already available which have a GPS chipset and which allow for them to obtain a GPS location of the device and the incorporation or carrying of the device on the transport unit 5 will accomplish the one objective of being able to ascertain a geographic location. Most of these devices already also have a computer network interface which allows for Internet access or the like I which data transmissions could be made to the database of the present invention for recordal. As well, a laptop computer or a smart phone with a browser or other software kernel in it will allow for the deployment of a software unit location tracking component which would easily allow for a very comfortable or sophisticated user interface allowing for the setting of many dynamic load parameters 4 as well as perhaps other components of a load management software or systems.

It is explicitly contemplated that beyond the provision of a basic unit tracking hardware device 6, development of unit tracking software 8 such as this for use on software, laptop or other portable electronic device 7 is explicitly contemplated within the scope of the present invention. That software 8 might either comprise a website interface, or other browser-based system whereby the user could interact with the system via an Internet browser on their laptop or other portable electronic device, or could alternately comprise locally installed software which would simply communicate by the network in question.

The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous changes and modifications will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, all such suitable changes or modifications in structure or operation which may be resorted to are intended to fall within the scope of the claimed invention.

Claims

1. A system for locating available transport units to transport loads between locations, the system comprising:

a server having an interface connected to a data network;

a unit location tracking device associated with a transport unit and operative to: capture a geographical location of the transport unit and transmit the geographical location of the transport unit to the server; and transmit at least one load parameters to the server,

a unit location database operatively connected to the server, the unit location database having at least one computer readable memory containing information including:

a plurality of unit identifiers, each unit identifier identifying a specific transport unit and associated with a unit location identifier identifying the location of the specific transport unit and at least one load parameter indicating the suitability of the specific transport unit for a transport job, and

at least one client computer operative to access the server through the interface and query a suitable transport unit based on geographical location,

wherein the server updates the information in the database in response to receiving a transmittal from a unit location tracking device.

2. The system of 1 wherein the unit location tracking device captures the location of the transport unit using a GPS receiver.

3. The system of 1 wherein the unit tracking device transmits the at least one load parameter and a unit identifier identifying the transport unit to the server in conjunction with the geographical location.

4. The system of 1 wherein the interface is a website.

5. The system of claim 1 wherein the transmittal of the geographical location is manually triggered by a user of the transport unit.

6. The system of claim 1 wherein the transmittal of the geographical location is automatically triggered on a periodic basis.

7. The system of claim 1 wherein the transmittal of the geographical location is automatically triggered by the occurrence of an event.

8. The system of claim 1 wherein the tracking device is one of: a PDA; and a cellular telephone.

9. A method for locating available transport units to transport loads between locations, the method comprising:

receiving a geographical location from a unit tracking device associated with a transport unit;

receiving at least one load parameters from a unit tracking device associated with the transport unit;

updating information in a database using the geographical location and the at least one load parameter from the unit tracking device; and

allowing the database to be queried for suitable transport unit based on geographical location.

10. The method of 9 wherein the geographical location and the at least one load parameter is received simultaneously.

11. The method of claim 9 wherein the transmittal of the geographical location is manually triggered by a user of the transport unit.

12. The method of claim 9 wherein the transmittal of the geographical location is automatically triggered on a periodic basis.

13. The method of claim 9 wherein the transmittal of the geographical location is automatically triggered by the occurrence of an event.

14. The method of claim 9 wherein the tracking device is one of: a PDA; and a cellular telephone.

15. The method of claim 9 wherein the load parameter includes both static load parameters and dynamic load parameters.

16. The method of claim 15 wherein the static load parameters include a load weight.

17. The method of claim 15 wherein the dynamic load parameters include at least one of: an indication of the loaded status of the specific transport unit; and limitations on the length of the trip that can be accepted by the specific transport unit.

18. A memory for storing data for access by an application program being executed on a data processing system, comprising:

a data structure stored in the memory, said data structure including information resident in a database used by the application program and including:

a unit identifier identifying a specific transport unit;

a unit location identifier associated with the unit identifier and identifying the location of the specific transport unit; and

at least one load parameter associated with the unit identifier and indicating the suitability of the specific transport unit for a transport job.

19. The memory of claim 18 wherein the unit identifier is a unit number assigned by a transport vendor to the specific transport unit.

20. The memory of claim 18 wherein the unit identifier comprises an identification of the vendor.

21. The memory of claim 18 wherein the unit location identifier indicates a geographical location.

22. The memory of claim 18 wherein the unit location identifier indicates mapping coordinates to allow the location of the specific transport unit to be displayed on a map.

23. The memory of claim 18 wherein the load parameter includes an indication in of at least one of: the specific transport unit is loaded and unavailable; the specific transport unit is unloaded and available; and the amount of load space available on the specific transport unit.

24. The memory of claim 18 wherein the load parameter includes at least one of: a pulling power of the specific transport unit; and special equipment of the specific transport unit.

25. The memory of claim 18 wherein the load parameter includes both static load parameters and dynamic load parameters.

26. The memory of claim 25 wherein the static load parameters include a load weight.

27. The memory of claim 25 wherein the dynamic load parameters include at least one of: an indication of the loaded status of the specific transport unit; and limitations on the length of the trip that can be accepted by the specific transport unit.

28. A unit location tracking device comprising:

at least one computer readable memory containing program instructions;

a GPS receiver operative to obtain geographical information;

a network interface connection;

a human interface for inputting load parameters; and

at least one processing unit in response to executing the program instructions operative to:

automatically capture geographical location information using the GPS receiver;

receive at least one load parameter input from the human interface; and transmit the geographical location information and the at least one load parameter to a database for storage over the network interface connection.