Patent Application
20080064420
The accompanying drawings, which are incorporated into and form a part of the specification, illustrate several embodiments of the present invention and, together with the description, serve to explain the principles of the invention.
The drawings are only for the purpose of illustrating a preferred embodiment of the invention and are not to be construed as limiting the invention. In the drawings:
The process begins when a customer sends a forward message 30 targeted to a driver in an associated truck 18. This forward message is sent 30 from the customer's computer 10 using a QTracs Host System, or the like, to a NMC 12. Once NMC 12 receives the forward message 32, it performs two operations: First is to make a copy of the forward message and route 34 it to DN 20, and, second is to route this message to the driver's truck via a message path 36 such as a satellite or CDMA network. Although a satellite system is shown and described, this disclosure is meant to include all communication systems such as, but not limited to, terrestrial CDMA systems or water communication systems.
The Driver Notification Application containing a similar message sent via the QTracs Host System, or the like, delivered to the driver's mobile phone 26 is the new feature in this application. Once the message is routed via message path 36 to a satellite or CMDA to the DN application 20, it is there where the present embodiment differentiates from the prior art. The functionality provided by DN application 20 allows drivers to be located away from their trucks, 18 but still be notified that important messages are awaiting them at the truck 18.
In order for a driver to be enabled for the DN 20 functionality, an end-user representing the driver's company must provision the driver via a web-based application 38 over the internet (DN Portal), or the like. The end-user provides all of the necessary details required so that messages originating from the customer dispatch system or computer 10 can be sent to the driver's phone 26 via short message service (SMS). These details are stored in a relational database 28 for future reference. One of the attributes that can be stored in the database 28 that is associated to a driver is the unique identifier of the mobile unit that resides in the driver's truck 18. This attribute is contained with every message that is sent to the DN 20 application and as such can be cross-referenced to the driver's phone number. This optional mapping allows end users flexibility when setting up their dispatch systems, giving them the choice to embed the driver phone number in the message or providing the unique identifier to driver phone number mapping using the web interface. Once the provisioning process has been completed, the driver is enabled to use the functionality provided. In addition, a customer must specify a SMS policy which specifies what the contents of the SMS message will be for all drivers, a specified number of identified driver's or a single driver. As an example, the customer may choose a custom message (i.e. “You have a Load Assignment waiting at the truck”) or a specified number of characters from the actual macro message originally sent by the dispatch software. The number of characters is configurable via the DN Portal.
Once a forward message is routed to the DN 20 application, DN 20 application can perform the following steps to successfully route the message to a driver's phone:
If the phone number is found 56 and extracted properly 58, the phone number found in the message is then checked 60 to have a match in the relational database 28. If there is a match and the driver is enabled 62, the process of sending the SMS message continues. If there is a match but the driver has been flagged as disabled 64, the process continues to audit messaging event 48 and terminates 50. If the phone number is not found in the message 64, a unique identifier from the proprietary protocol is extracted from the message received. This unique identifier is then looked up in the relational database 28 to see if there is a match to a driver's phone number 66. If the phone number is matched or found in the database 68 and the driver is enabled 62, the process continues, otherwise the process terminates 50 as previously described.
Once it is determined affirmatively that the driver is enabled 70, the customers SMS policy is identified 72. Depending on the customer's choice of SMS Policy the original contents of the message may be massaged 74 in order to provide as much relevant information onto the driver's phone 26 as required. If the SMS Policy is set to send a certain amount of characters of the actual message, extraneous white-space characters are removed and the message may be shortened to fit the length specified. If the SMS Policy is set to a custom message, that custom message is retrieved from the relational database. The custom message is configurable and is drafted by the customer via the DN Portal.
Once the message to be sent has been identified, the message is then sent over the internet 76 to an SMS aggregator 22. SMS aggregator 22 provides SMS connectivity to most major wireless carriers 24 around the world. SMS aggregator 22 then routes the message 40 to the target phone 26 where the driver receives the message 42. In this manner, a similar message is sent over the vehicle messaging system, such as OmniTRACS®, and is also sent to the driver's mobile phone, providing additional assurance that the message has been received.
Although the invention has been described in detail with particular reference to these preferred embodiments, other embodiments can achieve the same results. Variations and modifications of the present invention will be obvious to those skilled in the art and it is intended to cover in the appended claims all such modifications and equivalents. The entire disclosures of all references, applications, patents, and publications cited above, are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60843340 | Sep 2006 | US |
