Distributed vehicle maintenance system and method

Abstract

 A system and method is provided for distributing vehicle maintenance data 405. The system includes at least one module 102 configured with self-locating means 201, local processing means 205, memory means 204 and communicating means 207 for attachment to a vehicle 101 and remote processing means 801 configured with communication means 811. Said self-locating 201 means acquires vehicle location data 413, 414 at time intervals 154, 416. Said memory means 204 stores threshold data 403 and said acquired data 413, 414. Said local processing means 205 processes said acquired data 413, 414 into cumulative data 405 and compares (601, 604, 607) said cumulative data 405 to said threshold data 403 according to comparison parameters. Upon said data comparison returning a match, said local processing means 205 instructs said communication means 207 to broadcast said cumulative data 405 to said communication means 811 of said remote processing means 801.

Description

Field of the Invention

[0001] The present invention relates to a system and method for distributing vehicle maintenance data. More particularly, the present invention relates to collecting vehicle maintenance data and distributing said data to remote vehicle service providers.

Background of the invention

[0002] Systems are known with which to report the accurate location, operational parameters or a combination thereof of a vehicle to its user or to a remote monitoring station.

[0003] A proportion of such vehicle-based systems are further known, which make use of the satellite-based Global Positioning System to determine said accurate location at any precise time. Accurate vehicle location is useful in such applications as facilitating vehicle navigation throughout a journey, vehicle stopping and retrieving when taken without consent or simply tracking for delivery time estimation and, more recently, matching vehicle location to proximate services required by its user with making use of geo-fencing parameters.

[0004] The data distribution functionality of such systems is usually restricted to broadcasting GPS location data expressed as latitudinal and longitudinal co-ordinates, or other location data such as cell location in a mobile phone network, to a remote processing unit such as a network server, which is then processed for correlation with map data in order to output and send back the relevant information, whether it be street names or service provider names and addresses.

[0005] For instance, in the case of a remote monitoring station tracking a stolen vehicle or a delivery vehicle, a user at said monitoring station sends a processing command or simply a text-based communication to said vehicle-based system, whereby said GPS co-ordinates or cell location are sent back for mapping in response. In the case of location matching applications, a vehicle user enters journey or services parameters with activating keys of a vehicle-mounted keypad or user interface, whereby GPS co-ordinates or cell location are sent back to a network server for mapping, matching and broadcasting results back to said user.

[0006] In the context of the above prior art, a problem exists in that many vehicle users fail to regularly maintain their vehicle in optimum working order with timely mechanical maintenance, opting instead for punctual, as-needed maintenance, for instance as a result of uncertainty as to what frequency should said maintenance take place.

[0007] Indeed, whereas the above applications may be useful in locating a vehicle service provider in close vicinity or specialising in the vehicle make or model itself, they rely upon vehicle user-input at the time of the decision to carry out vehicle maintenance, such as search parameters for maintenance providers. Such systems therefore require the vehicle user to remain aware of vehicle service intervals and requirements throughout the useful life of the vehicle, whether such intervals are based upon the total distance covered by the vehicle, the total running time of its mechanical components or a combination thereof, which is a difficult and time-consuming task. A user may for example travel few miles in a given period but spend most of said period in urban traffic, whereby maintenance should take place based upon cumulative running time of the vehicle engine in that period rather than total distance travelled, but said user opting instead to maintain the vehicle at mileage intervals, such that engine wear is compounded by lack of timely maintenance.

[0008] It is known to provide a unit to connect to an odometer of the vehicle to monitor the mileage of the vehicle to indicate when a service is due, for example such a unit is supplied by the car manufacturer BMW. However a problem with this type of unit is that the unit gives an unreliable reading as to when a maintenance of the vehicle is due because it depends on distance travelled only and does not take account of when the odometer is not working properly, either due to a fault or deliberately tampered with. Additionally the odometer does not take account of when a vehicle has its engine running and stationary or other parameters, for example the average speed the vehicle was travelled. A more sophisticated solution is disclosed in Canadian patent publication number CA2359887 by 'Road Inc' wherein vehicle maintenance-related services are provided from a server over a wide area network, such as the Internet. A server that is accessible over the wide area network through a wireless communication link is provided. An apparatus is provided in a vehicle to collect, over a data bus in the vehicle, data relating to an operation of the vehicle. The data received from the data bus is then communicated to the server over the wireless communication link. Based on the data received at the server, the maintenance-related services is then initiated. The operation data of the vehicle can be collected from various subsystems of the vehicle. A problem with the Road Inc. solution is that it is reliant on the various subsystems of the vehicle to gather data, which are not accurate. Additionally the Road Inc solution is difficult to install as a data bus must be provided to connect to each sub-system in the vehicle in order to gather data, which is technically difficult to achieve

[0009] Moreover, a second problem exists in that vehicle service providers remain unaware of many variables, such as required maintenance points, stock of parts and staffing levels until vehicle users have contacted them to arrange vehicle maintenance and have been queried about their driving habits to determine maintenance points and parts. It is therefore difficult for said vehicle service providers to forecast any of the above variables with accuracy, thus providing their services economically and profitably, which detriments the user with, for instance, vehicle immobilisation for unnecessary lengths of time whilst maintenance is carried out (e.g. if awaiting parts).

Object of the Invention

[0010] A vehicle maintenance system and method is therefore required, which distributes vehicle maintenance data to vehicle maintenance professionals in advance of maintenance thresholds in order to regularly maintain said vehicle in optimum working order with timely mechanical servicing, such that said servicing is carried out more economically for both the user and the service provider.

Summary of the Invention

[0011] According to an aspect of the present invention, as set out in the appended claims, a system for distributing vehicle maintenance data is provided, which includes at least one module configured with self-locating means, local processing means, memory means and communicating means for attachment to a vehicle and remote processing means configured with communication means, wherein said self-locating means acquires vehicle location data at time intervals; said memory means stores instructions, threshold data and said acquired data; said local processing means is configured by said instructions to process said acquired data into cumulative data and compare said cumulative data to said threshold data according to comparison parameters; whereby upon said data comparison returning a match, said local processing means instructs said communication means to broadcast said cumulative data to said communication means of said remote processing means.

[0012] According to another aspect of the present invention, a method of distributing vehicle maintenance data is provided, said method comprising the steps of acquiring vehicle location data at time intervals with self-locating means in at least one module configured with self-locating means, local processing means, memory means and communicating means attached to a vehicle; storing instructions, threshold data and said acquired data in said memory means; configuring said processing means with said instructions to process said acquired data into cumulative data; comparing said cumulative data to said threshold data according to comparison parameters and upon said data comparison returning a match, instructing said communication means to broadcast said cumulative data to communicating means of remote processing means.

[0013] According to another aspect of the present invention, a computer system programmed to execute stored instructions is provided such that in response to said stored instructions said system is configured to acquire vehicle location data at time intervals from self-locating means; store threshold data and said acquired data in memory means; process said acquired data into cumulative data; compare said cumulative data to said threshold data according to comparison parameters and, upon said data comparison returning a match, instruct communication means to broadcast said cumulative data to communicating means of a remote terminal.

[0014] According to another aspect of the present invention, a computer-readable memory system having a plurality of data fields stored therein representing a data structure, wherein said data structure includes vehicle location data at time intervals, cumulative data and threshold data and further having instructions configured to process said vehicle location data at time intervals into said cumulative data; compare said cumulative data to said threshold data according to parameters and broadcast said cumulative data to a remote terminal upon said data comparison returning a match.

[0015] According to an aspect of the present invention, a module for attachment to a vehicle for distributing vehicle maintenance data is provided, which includes self-locating means, local processing means, memory means and communicating means, wherein said self-locating means acquires vehicle location data at time intervals; said memory means stores instructions, threshold data and said acquired data; said local processing means is configured by said instructions to process said acquired data into cumulative data and compare said cumulative data to said threshold data according to comparison parameters; whereby upon said data comparison returning a match, said local processing means instructs said communication means to broadcast said cumulative data.

[0016] According to an aspect of the present invention, a kit of parts for distributing vehicle maintenance data is provided, said parts including at least one module configured with self-locating means, local processing means, memory means and communicating means for attachment to a vehicle and remote processing means configured with communication means, wherein said self-locating means acquires vehicle location data at time intervals; said memory means stores instructions, threshold data and said acquired data; said local processing means is configured by said instructions to process said acquired data into cumulative data and compare said cumulative data to said threshold data according to comparison parameters; whereby upon said data comparison returning a match, said local processing means instructs said communication means to broadcast said cumulative data to said communication means of said remote processing means.

[0017] It will be appreciated that the self-locating means acquires the data independent of vehicle operating characteristics. The invention does not rely on measuring parameters of the vehicle to acquire the data, which has the advantage that the data acquired is not reliant on the vehicle itself, which can be unreliable. The invention also provides the advantage of facilitating automated vehicle management which allows vehicle maintenance operators take full control of their customers maintenance requirements.

[0018] In a preferred embodiment of the present invention, said threshold data and cumulative data is a distance, which may be expressed in any unit of measure such as imperial miles or metric kilometers or sub-divisions thereof. In another preferred embodiment of the present invention, said module is further configured with sensor means for determining whether a vehicle engine is powered up or down, wherein said threshold data and cumulative data also includes engine running time, which may be expressed in any unit of measure of time such as a combination of days, hours, minutes and seconds.

[0019] In a preferred embodiment of the present invention, said memory means includes first non-volatile and second volatile random access memory, wherein said threshold data and cumulative is stored in first non-volatile RAM and acquired location data is stored in said second volatile RAM.

[0020] In a preferred embodiment of the present invention, said local processing means is further configured by said instructions to receive and process read requests from said remote processing means, whereby upon receiving a cumulative data read request from said remote processing means, said local processing means instructs said communication means to broadcast said cumulative data to said communication means of said remote processing means.

[0021] The self-locating means is preferably a Global Positioning System device receiving time and location data from orbiting satellites. Suitably the communication means is a modem configured to exchange data packets over a wireless network, such as the Global System for Mobile Communication ('GSM') or General Packet Radio Service ('GPRS') networks. In yet another preferred embodiment of the present invention, said cumulative data and read request are respectively communicated as text messages using Short Message Service ('SMS') protocol over said wireless network. Preferably, said remote processing means parse said text messages and store cumulative data therein in a database.

[0022] In yet another preferred embodiment of the present invention, said remote processing means are located at one or a plurality of vehicle maintenance providers. Preferably, said threshold data is updated when said vehicle is maintained by any of said vehicle maintenance providers.

Brief Description of the Drawings

[0023] The invention will be better understood upon consideration of the following detailed description and the accompanying drawings, in which:

Figure 1 shows a preferred embodiment of the present invention in an environment, including at least one vehicle to which a module is attached and at least one vehicle service provider equipped with a terminal;

Figure 2 shows the module of Figure 1 in further detail, including memory means;

Figure 4 details the processing steps according to which the module of Figures 1 and 2 operates, including a step of processing data at runtime;

Figure 4 illustrates the contents of the memory means shown in Figure 2 during the data processing step shown in Figure 3;

Figure 5 further details the data processing step of Figure 4, including a step of data comparison and a data broadcasting step;

Figure 6 further details the data comparing step of Figure 5;

Figure 7 further details the data broadcasting step of Figure 5;

Figure 8 provides an example of the terminal at the vehicle service provider shown in Figure 1, which includes processing means, memory means and communicating means;

Figure 9 details the processing steps according to which the terminal of Figures 1 and 8 operates, including a step of updating a database and a step of processing database data according to user input;

Figure 10 illustrates the contents of the memory means of the terminal of Figures 1, 8 and 9 according to the present invention, including an application and a database;

Figure 11 provides an example of the database shown in Figure 10;

Figure 12 shows a graphical user interface of the application shown in Figure 10;

Figure 13 further details the database updating step of Figure 9;

Figure 14 further details the database data processing step of Figure 9; and

Figure 15 shows the graphical user interface of Figure 12 upon performing either of the processing steps described in Figures 13 and 14.

Detailed Description of the Drawings

[0024] A preferred embodiment of the present invention is shown in an environment in Figure 1, which includes at least one vehicle 101, for instance a car, to which a module 102 is attached and at least one vehicle service provider 103 equipped with a terminal 104. Module 102 combines Global Positioning System (GPS) data processing functionality and wireless telecommunication emitting and receiving functionality, such as over a cellular telephone network configured according to the Global System for Mobile Communication ('GSM') or General Packet Radio Service ('GPRS') network industry standards. In yet another preferred embodiment of the present invention, said cumulative data and read request are respectively communicated as text messages using Short Message Service ('SMS') protocol. Module 102 receives GPS latitudinal data, longitudinal data and time data from GPS satellite 105 over wireless data transmission 106 by means of vehicle aerial 107, preferably every second. Module 102 receives or emits voice and/or text data encoded as a digital signal over wireless data transmission 108 by means of the same vehicle aerial 107 or another dedicated aerial, wherein said signal is relayed respectively to or from module 102 in vehicle 101 by the geographically-closest communication link relay 109 of a plurality thereof. Said text data is preferably encoded as a SMS message, although it will be readily understood by those skilled in the art that the present invention is not limited thereto.

[0025] The plurality of communication link relays allows said digital signal to be routed between module 102 and its intended recipient or from its remote emitter, in the example terminal 104 of vehicle service provider 103, by means of a remote gateway 110. Gateway 110 is for instance a communication network switch coupling digital signal traffic between wireless telecommunication networks, such as the network within which wireless data transmission 108 takes place, and a wide area network (WAN) 111, an example of which is the Internet. Said gateway 110 further provides protocol conversion if required, for instance if module 102 uses Wireless Application Protocol to distribute data to and optionally receive from terminal 104, which is itself only connected to the WAN 111.

[0026] The user of vehicle 101 preferably has the use of either a mobile communicating device 112 configured to at least receive text data encoded as a digital signal over a wireless data transmission 113, such as a mobile telephone, or a terminal 114 connected to said WAN 111 and configured with electronic mail receiving and emitting functionality, or both. Thus, the potential exists for data exchange between any of module 102, mobile communicating device 112 and terminals 104 and 113, by way of wireless data transmissions 108,113 and the Internet 111 interfaced by gateway 110.

[0027] In the example, many other vehicles shown as 115 are likewise respectively equipped with a module 102, whereby the potential exists for likewise data exchange between any of said many modules 102, terminal 104 and the respective wireless or WAN-connected communication devices (not shown) of said vehicles owners.

[0028] The module 102 is shown in Figure 2 in further detail. Module 102 includes self-locating means 201 in the form of a GPS receiver containing an analogue-to-digital converter 202, which receives analogue positional and time data through aerial 107 from satellite 105 and processes it into digital data, and a processor 203 for outputting said converted data into latitude (Xn), longitude (Yn) and elevation (Zn) integers and time data into clock-time data (Tn). In the preferred embodiment of the present invention, said elevation (Zn) data is not processed, because the data processing and module cost overheads required to do so are not offset by the gain in module output accuracy, given that the output variation between processing Xn, Yn data as opposed to Xn, Yn, Zn is minimum. In an alternative embodiment of the present invention depending upon the available processing capacity within module 102, however, said elevation (Zn) data may also be processed in order to further increase the accuracy of the output of module 102. Xn, Yn data is regularly output by receiver 201 at time Tn and stored in memory means 204, which includes non-volatile random-access memory (NVRAM) totalling 512 kilobytes in this embodiment. NVRAM 204 provides non-volatile storage for processing means 205, which is a Central Processing Unit (CPU) such as a general-purpose microprocessor, acting as the main controller of module 102.

[0029] Said GPS receiver 201, NVRAM 204 and CPU 205 are connected by a data input/output bus 206, over which they communicate and to which further components of module 102 are similarly linked in order to provide wireless communication functionality and receive user interrupts and configuration data. Accordingly, communication functionality is provided by a modem 207, which provides the interface to external communication systems, such as the GSM or GPRS cellular telephone network shown in Figure 1. A user interrupt may be received from data input interface 208, which is a switch. In this embodiment, a second interface 209 is provided as an industry-standard RS-232 data input port for attachment to an external data input device, wherefrom input data configuring or upgrading module 102 for use may be stored in NVRAM 204. Power may be provided to module 102 by an electrical converter 210 connected to the battery 211 of the vehicle or, alternatively, by an internal module battery 212 included as a redundant power source in the electrical circuit of module 102 in case of battery 211 failing.

[0030] The processing steps according to which module 102 operates are described in Figure 3. In order to distribute vehicle maintenance data to vehicle maintenance professionals in advance of maintenance thresholds, it is preferable to input threshold data in module 102, for instance at first when a vehicle is new and, subsequently, every time said vehicle is maintained.

[0031] Upon completing the assembly of the vehicle 101 at a manufacturing facility, module 102 is configured to power up at step 301 when battery 211 is first connected to the electrical circuit thereof, whereby NVRAM 204 is initialised at step 302. At said manufacturing facility still or, alternatively, upon a vehicle service provider 104 taking delivery of said new vehicle, the external data input device described in Figure 2 is connected thereafter to second interface 209, whereby instructions for CPU 205 and reference data for receiver 201 may be uploaded into NVRAM 204 at step 303. The processing of said CPU instructions starts at the next step 304 with first generating, then initialising a reference key in NVRAM 204 at steps 305, 306 respectively. In this embodiment, said reference key is a 3-bit key, but it will be understood by those skilled in the art that the present description is not limited thereto, as indeed even a 1-bit key or a key using much more than 3 bits may be usefully implemented instead. Moreover, in an alternative embodiment of the present invention, the referencing function of the above key is performed with several data accumulators instead.

[0032] The initialising of said reference key at said step 306 permits data input through interface 209, which is otherwise not permitted. Said instructions optionally allow receiver 201 to be calibrated for location and/or time accuracy at step 307. At step 308, maintenance threshold data Dα is input, preferably as a distance, for instance expressed in imperial miles or metric kilometres, whereby it is permanently stored in NVRAM 204. In another embodiment of the present invention, maintenance threshold data Tα is then input at step 309, preferably as a period of time, for instance expressed in days, hours, minutes or any combination thereof, whereby it is also permanently stored in NVRAM 204. Upon completing this threshold input, the external device may then be disconnected from interface 209 at the next step 310, whereby module 102 now operates at runtime at step 311, with processing location and time data according to the instructions loaded at step 303.

[0033] A question is asked at step 312, as to whether a user interrupt has been received from switch 208. If the question of step 312 is answered positively, such as when vehicle 101 is being maintained upon reaching or approaching said maintenance thresholds Dα and/or Tα and a vehicle service provider activates switch 208 as a maintenance point, control proceeds to step 306, whereby the reference key first generated at step 305 is again initialised and new maintenance threshold data Dα and/or Tα may thus be input as previously described. Alternatively, the question of step 312 is answered negatively and the runtime processing of step 311 continues.

[0034] The contents of NVRAM 204 are shown in Figure 4 upon starting the runtime step 311. Memory 204 first contains an application 401 embodying the set of CPU instructions previously described, thus which processes positional data, time data, distributed and distributable data. Preferably, application 401 is configured to process local data as detailed below, packet and broadcast said data or receive remote data with modem 207, wherein said distributed data is for instance encoded in a SMS text message. In order to identify the module 102 of vehicle 101 amongst the many modules 102 of vehicles 115, memory 204 also stores a unique device ID 402, which may for instance be a sequential integer ID or a vehicle-specific ID such as the registration number or VIN chassis number of vehicle 101.
Memory 204 next contains distance maintenance threshold data Dα 403 and, optionally, time maintenance threshold data Tα 404. Stored cumulative distance data D is shown at 405 and optional stored cumulative time data T is shown at 406. Calculated distance data Dn is shown at 407, which is processed from Xn, Yn data according to the present invention. Optional calculated time data Tn is shown at 408, which is processed from Tn data according to the present invention. The 3-bit reference key of steps 305, 306 is shown at 409 as three bits initialised at zero, which may be respectively set to one by application 401 upon data D 405 or optional data T 406 meeting parameters relative to Dα 403 or Tα 404 respectively, which will be further described herein. Memory 204 next contains at least one communication address 410 of a remote recipient, such as the phone number or address in WAN 111 of terminal 104 of service provider 103, in order for module 102 to distribute data thereto via modem 207. GPS reference data is shown at 411 and Xn, Yn, and Tn location data communicated by processor 203 over bus 206 is preferably stored in a portion of memory 204 configured as a First-In-First-Out (FIFO) buffer 412. Said location data is stored as a sequential collection of locations (Xn, Yn) 413, 414 sampled at respective, regular time intervals Tn 414, 415 which are preferably very short, such as one second in the example. For practical and costs purposes, the accuracy of said (Xn, Yn) data 413, 414 is two-times distance root mean square (2drms) plus or minus 5 meters.

[0035] The declared size of buffer 412 determines the amount of samples 413, 414 stored at any one time 414, 415 in memory 204, which may thus vary according to whether a larger or smaller amount of NVRAM is provided and/or coding or compiling optimisation reduces the physical size of application 401 and/or the GPS data requirements for distance calculation. In the embodiment, it is preferable to store FIFO buffer 412 in NVRAM 204 as opposed to a volatile random access memory, to ensure successive samples provide accurate location and time data without interruption, irrespective of whether vehicle 101 is under power or not when its location changes, for instance for vehicle security purposes or, optionally, to compare total distance travelled D 405 against total engine running time T 406.

[0036] The data processing step 311 is further detailed in Figure 5. Location and time data (Xn, Yn, Tn) 413 to 416 is regularly output by processor 203 at step 501 over bus 206 during runtime step 311, whereby it is queued in buffer 412 in memory 204 according to said one-second sampling interval at step 502. At step 503, application 401 fetches said location data (Xn, Yn) 413 and (Xn+1, Yn+1) 414 from said queue at times Tn 415 and Tn+1 416 respectively. A first question is asked at step 504, as to whether a difference exists between said selected sets of location data 413, 414, thus whether vehicle 101 has travelled in the sampling interval. If the question of step 504 is answered positively, application 401 calculates the distance Dn 407 travelled between said selected sets of location data 413, 414. Examples of distance calculation are provided below for descriptive purposes, but it will be readily understood by those skilled in the art that the present description is not limited thereto.

Where

[0037] The accuracy provided by the above calculation may be increased if CPU 205 can process cosine functions, whereby:

Where

[0038] The above calculation is described for distances in imperial miles, but coefficients may be appropriately substituted for distances in metric kilometres or any other measurement system and/or subdivisions thereof. Likewise, the calculation described is relatively simple and thus very economic in processor usage, but greater accuracy may be obtained without departing from the scope of the present invention and will be dependent upon the processing capacity of CPU 205, notably floating point mathematical accuracy, particularly double-precision floating point calculation. In particularly advantageous embodiment of the present invention, said distance Dn is adjusted for errors using GPS-based speed and heading filters, wherein said filters are Least Squares adjustment filters, for instance Kalman filters, which are known in the art of kinetic GPS data processing. Optionally, application 401 also calculates the time Tn 408 elapsed between said selected sets of location data 413, 414 based upon time data 415, 416 at said step 505.

[0039] At the next step 506, to which control also proceeds directly if question 504 is answered negatively, a second question is asked as to whether the vehicle engine is under power, in order to determine whether to update D 405 and optionally T 406. Question 506 is answered for instance with polling an industry standard engine sensor device returning a binary response of zero (engine off) or one (engine on). If the question of step 506 is answered positively, application 401 updates the cumulative distance D 405 at step 507 with adding the distance Dn 407 calculated at step 505 to it. Optionally, application 401 also updates the cumulative running time D 406 at said step 507 with adding the elapsed time Tn 408 calculated at said step 505.

[0040] At the next step 508, to which control also proceeds directly if question 506 is answered negatively, a third is asked as to whether a remote data request has been received by module 102. In the embodiment, it is possible for a user at terminal 104 of service provider 103 to poll module 102 for distance data D 405 and, optionally, time data T 406. Said poll is preferably, but not necessarily, a function call encoded as a SMS message which, when received by modem 207 and then processed by application 401, simply triggers the broadcasting function of said application 401 as will be further described below. If the question of step 508 is answered negatively, application 401 next compares the stored cumulative distance D 405, possibly updated according to step 507, with the stored maintenance threshold Dα 403 at step 509, in order to determine whether a maintenance broadcasting event is triggered, the parameters of which may vary and examples of which will be provided further herein. Optionally, application 401 also compares the stored cumulative time T 406, possibly updated according to step 507, with the stored maintenance threshold Tα 404 at said step 509 for the same purpose. A fourth and final question is thus asked at step 510, as to whether a maintenance broadcasting event is triggered by the comparison of step 509 which, if answered positively, triggers the broadcasting function of said application 401 at step 511, as would be the case if the previous question 508 was answered positively instead.

[0041] Alternatively, the question of step 510 is answered negatively and, in the absence of user interrupt of step 312, control returns to step 503.

[0042] The data comparing step 509 is further detailed in Figure 6. In the embodiment, it is preferred that module 102 broadcasts cumulative distance D 405 at set ratios of the distance maintenance threshold Dα 403, notably when said distance D 405 respectively reaches a third of threshold Dα 403, two thirds of threshold Dα 403 and said threshold Dα 403. At step 601, a first question is asked at to whether the value of cumulative distance D 405 exceeds a third of distance maintenance threshold Dα 403. If the question of step 601 is answered negatively, control proceeds to the question of step 510, which is answered negatively also. Alternatively, the question of step 601 is answered positively, whereby a second question is asked at step 602 as to whether the bit in reference key 409 corresponding to the condition asked in question 601 is set, in the example the first bit of said key. If the question of step 602 is answered negatively, application 401 sets said first bit to one at step 603 and control proceeds to step 610, wherein an event is declared which answers question 510 positively and triggers a broadcast. Upon the questions of steps 601, 602 being both answered positively, said first condition is ignored for the purpose of deciding whether to broadcast distance D 405, thus avoiding unnecessary, repeated duplication of said broadcast and control proceeds to the next step 604.

[0043] At step 604, a third question is asked at to whether the value of cumulative distance D 405 exceeds two-thirds of distance maintenance threshold Dα 403. If the question of step 604 is answered negatively, control proceeds to the question of step 510, which is answered negatively also. Alternatively, the question of step 604 is answered positively, whereby a fourth question is asked at step 605 as to whether the bit in reference key 409 corresponding to the condition asked in question 604 is set, in the example the second bit of said key. If the question of step 605 is answered negatively, application 401 sets said first bit to one at step 606 and control again proceeds to step 610, wherein an event is declared which answers question 510 positively and triggers a broadcast. Upon the questions of steps 601, 602, 604 and 605 being all answered positively, said first and second conditions are ignored for the purpose of deciding whether to broadcast distance D 405, thus avoiding unnecessary, repeated duplication of said broadcast and control proceeds to the next step 607. At step 607, a fifth question is asked at to whether the value of cumulative distance D 405 exceeds distance maintenance threshold Dα 403. If the question of step 607 is answered negatively, control proceeds to the question of step 510, which is answered negatively also. Alternatively, the question of step 607 is answered positively, whereby a sixth question is asked at step 608 as to whether the bit in reference key 409 corresponding to the condition asked in question 607 is set, in the example the third bit of said key. If the question of step 608 is answered negatively, application 401 sets said first bit to one at step 609 and control again proceeds to step 610, wherein an event is declared which answers question 510 positively and triggers a broadcast. Upon the questions of steps 601, 602, 604, 605, 607 and 608 being all answered positively, said first, second and third conditions are ignored for the purpose of deciding whether to broadcast distance D 405, thus avoiding unnecessary, repeated duplication of said broadcast.

[0044] In the embodiment, vehicle maintenance takes place shortly upon broadcasting that the third condition is met, whereby the reference key is reset and a new value for Dα 403 is input, such that the above algorithm may be recycled for the next optimum maintenance threshold. In an alternative embodiment using data accumulators as opposed to a reference bit key or in conjunction therewith, cumulative distance data 405 is accumulated in at least one data accumulator stored in NVRAM 204, which is compared to a distance broadcast threshold Dβ, for instance 2,000 miles or a metric equivalent, at step 601. Upon said accumulator data exceeding said broadcast threshold Dβ, control proceeds to step 610 and the accumulator data is reinitialised for further accumulation and comparison to threshold Dβ until such time as the condition is again met, and so on and so forth.

[0045] It will be understood by those skilled in the art that the above ratios are provided herein by way of example only, and that the present description is not limited thereto. Indeed, the reference key 409 may be implemented with more or less bits to accommodate respective number of differing ratios, such as successive quarters or tenths of said threshold Dα 403. Likewise, said comparison is limited to distance data for the purpose of not unnecessarily obscuring the present description, but it should be understood that it may instead or also incorporate comparison of running time data T 406 against respective threshold Tα 404 to optimise vehicle maintenance intervals. Broadcasting cumulative distance D 405 to vehicle service provider 103 according to the present invention allows said provider to initiate maintenance proceedings with the user of vehicle 101, removing the need for said user to remain aware of vehicle service intervals and requirements throughout the useful life of the vehicle. Moreover, broadcasting cumulative distance D 405 according to ratios of threshold Dα 403 to vehicle service provider 103 allows said provider to accurately forecast numerous variables, such as vehicle maintenance points based upon mileage, corresponding parts to order, required staffing levels and expected amount of business over given periods.

[0046] The data broadcasting step 511 is further detailed in Figure 7. Irrespective of whether a broadcasting event is declared as a result of step 610 or upon receiving a data request at step 508, application 401 first fetches relevant data from memory 204 at step 701. Preferably, emitting module identification data 402, distance maintenance threshold data Dα 403 and cumulative distance data D 405 are retrieved. Optionally, time maintenance threshold data Tα 404 and cumulative time data T 406 are retrieved also or instead. At step 702, application 401 outputs said retrieved data as formatted ASCII text, which it then encodes for broadcast at step 703 by way of packing said formatted ASCII text into communicable data packets, preferably but not necessarily as a SMS text message. At step 704, application 401 instructs modem 207 to dial phone number 410 and a question is asked at step 705 as to whether said modem 207 has successfully establishing a connection to the cellular telephone network. If the question of step 705 is answered negatively, a wait instruction elapses an arbitrary time period at step 706 before control returns to said question 705, until it is eventually answered positively, whereby said data packets are sent to the recipient over wireless data transmission 108, i.e. terminal 104 of vehicle service provider 103 at step 707. In the example, said data packets are relayed as a digital signal from module 102 in vehicle 101 by the geographically-closest communication link relay 109 of a plurality thereof. Said plurality of communication link relays allows said digital signal to be routed between module 102 and terminal 104 by means of remote gateway 110.

[0047] An example of the terminal 104 at the vehicle service provider 103 shown in Figure 1 is provided in Figure 8. Terminal 104 is a computer terminal configured with a data processing unit 801, data outputting means such as video display unit (VDU) 802, data inputting means such as a keyboard 803 and a pointing device (mouse) 804 and data inputting/outputting means such as WAN connection 805, magnetic data-carrying medium reader/writer 806 and optical data-carrying medium reader/writer 807. Within data processing unit 801, a central processing unit (CPU) 808, such as an Intel Pentium 4 manufactured by the Intel Corporation, provides task co-ordination and data processing functionality. Instructions and data for the CPU 808 are stored in main memory 809 and a hard disk storage unit 810 facilitates non-volatile storage of data and several software applications. A modem 811 provides a wired connection to the Internet 111. A universal serial bus (USB) input/output interface 812 facilitates connection to the keyboard and pointing device 803, 804. All of the above devices are connected to a data input/output bus 813, to which said magnetic data-carrying medium reader/writer 806 and optical data-carrying medium reader/writer 807 are also connected. A video adapter 814 receives CPU instructions over said bus 813 for outputting processed data to VDU 802.

[0048] In the embodiment, data processing unit 801 is of the type generally known as a compatible Personal Computer ('PC'), but may equally be any device configured with data inputting, processing and outputting means providing at least the functionality described above. Any such device may include, but is not limited to, an iMac® computer manufactured by the Apple® Corporation of Cupertino, California, USA; a Portable Digital Assistant (PDA) such as a Palm m505® manufactured by PalmOne® Inc. of Milpitas, California, USA; a Portable Digital Computer (PDC) such as an IPAQ® manufactured by the Hewlett-Packard® Company of Palo Alto, California, USA; or even a mobile phone such as a Nokia 9500 manufactured by the Nokia® Group in Finland, all of which are generally configured with processing means, output data display means, memory means, input means and wired or wireless network connectivity.

[0049] Processing steps are described in Figure 9 according to which terminal 104 operates. Terminal 104 is first switched on at step 901. At step 902, the operating system is loaded which provides said terminal 104 with basic functionality, such as initialisation of data input and/or output devices, data file browsing, keyboard and/or mouse input processing, video data outputting, network connectivity and network data processing. At step 903, an application is loaded into memory 809, which is a set of instructions for configuring CPU 808 to process data according to rules described hereafter. A database is next loaded at step 904, which organises application data referenced therein according to relational parameters.

[0050] A first question is asked at step 905, as to whether a broadcast has been received from a module 102, such as sent at vehicle 101 according to step 511. If the question of step 905 is answered positively, the application loaded at step 903 updates the database with the data received in said broadcast and notifies said update to the user of terminal 104 at step 906, for instance with generating a database record form summarising vehicle details and output to VDU 802, a user-selectable portion of which allows said user to notify the vehicle owner that maintenance is required. Control proceeds to the next step 907, as it would if the question of step 905 was answered negatively, whereby a second question asked as to whether user input has been received, for instance from keyboard 803 or mouse 804.

[0051] If the question of step 907 is answered negatively, control returns to step 905, whereby the next database update may then take place upon receiving another broadcast. Alternatively, the question of step 907 is answered positively and a third question is asked at to whether the user input corresponds to a request for a vehicle current distance D 405 or, optionally, current running time T 406. Such user input may for instance be provided as the selection a particular vehicle or a criteria-based selection thereof in the database or even with selecting a 'refresh' query instructing the application to poll every vehicle referenced therein, in the absence of any module-initiated broadcast.

[0052] If the question of step 908 is answered positively, the application loaded at step 903 polls one or a plurality of modules 102 for broadcasting back said requested data at step 909, as previously described in steps 508, 511 of Figure 5, according to whether said user has selected one vehicle 101 or a plurality of vehicles 101,115. In the embodiment, said application broadcasts said poll command sequentially for each vehicle if many were chosen, whereby a question is asked after each poll at step 910, as to whether another poll remains to be performed. If the question of step 910 is answered positively, control returns to step 909 whereby the next poll command is performed. Alternatively, question 910 is eventually answered negatively, whereby control returns to step 905. If the question of step 908 is answered negatively, however, control proceeds to step 911, wherein the application of step 903 processes database data according to user input and outputs said processed data to VDU 802. Such user input may for instance be provided as the initialising of a new database vehicle record when a new vehicle is sold, the selection of a 'forecast' query instructing the application to select every vehicle referenced in the database, the respective distance D 405 and/or threshold Dα of which matches forecasting parameters or, in accordance with the above description, the selection of a vehicle user notification command.

[0053] A question is therefore asked at step 912, as to whether said user input is a user notification command. If question 912 is answered affirmatively, control proceeds to step 909 such that a broadcast may be sent to said user, with retrieving said user contact details in said database and calling upon modem 811 to send a SMS text message requesting the arrangement of vehicle maintenance. In an alternative embodiment of the present invention, the application of step 903 is configured to send an electronic mail message to the electronic mail address of said user over the Internet, which is preferably also stored in said database. Alternatively, question 912 is answered negatively, whereby a final question is asked at step 913, as to whether said user input is an application close command. If the question of step 913 is answered negatively, control returns to step 905, whereby the next database update may then take place upon receiving another broadcast. Alternatively, the question of step 913 is answered positively and the application is closed and unloaded from memory 809 at step 914. Terminal 104 may thus be eventually switched off at step 915. It will be understood by those skilled in the art that the above-described types of user input are provided by way of example only and are not limited thereto.

[0054] The contents of the memory 809 of terminal 104 are shown in Figure 10 further to carrying out the database loading step 904 and whilst application closing step 914 is not selected, i.e. at application run time. Memory 809 first contains an operating system 1001 as loaded according to step 902, embodying the set of basic CPU instructions previously described in Figure 9. Memory 809 next contains a communications manager 1002 also loaded according to step 902, embodying the set of CPU instructions required to call upon the functionality of modem 811 and emit and receive network data. Memory 809 also contains an application 1003 as loaded according to step 903, embodying the set of CPU instructions according to which data broadcast by module 102 and referenced in database 1004 is processed. In a particular embodiment of the present invention, application 1003 is known as AutoCall© and manufactured and distributed by the present Assignee. Said data received from any module 102 at step 905 is shown at 1005 as incoming SMS text messages and at 1006 as parsed runtime data, which is the data extracted from message 1005 by application 1003 with which it updates database 1004 at step 906. Database data processed according to the user input of steps 908, 911, for instance according to the processing parameters declared in the various database queries described in Figure 9, is shown at 1007. Memory 809 also stores data broadcast by application 1003 as either module polls 1008 according to steps 908, 909, outgoing SMS text messages 1009 to vehicle users according to steps 912, 909 and in an alternative embodiment, electronic mail 1010 to vehicle users.

[0055] An example of the database 1004 is described in Figure 11. Database 1004 is shown in a table form, which references and organises stored and received vehicle data in relation to the unique module ID 402 of each module 102. Each of the plurality of vehicles 115 respectively configured with modules 102 is thus referenced in database 1004 as an individual record with a unique identifier in the [vehicle_ID] column 1101, in the example identifiers 402, 1102, 1103 and 1104. In order to facilitate the various aspects of vehicle maintenance, which may vary according to the make, model and usage history of any vehicle, it is preferable for database 1004 to reference said make, model, cumulative distance D 405, maintenance threshold distance Dα 403 and vehicle owner contact details in respective columns [make] 1105, [model] 1106, [cumul_ dist] 1107, [threshold_dist] 1108 and [contact] 1109. In an alternative embodiment, database 1004 also references cumulative running time T 406 and maintenance threshold time Tα 404 in respective columns [cumul_ time] 1110 and [threshold_time] 1111. Preferably, stored distance data and optional time data is formatted in respective columns 1107, 1108 and 1110, 1111 according to the format in which said data is stored and broadcast by module 102.

[0056] The graphical user interface (GUI) of application 1003 is shown in Figure 12 upon completing the database loading step 904 of Figure 9. GUI 1201 is output to VDU 802 by CPU 808 outputting data to video adapter 814. GUI 1201 first includes a device pointer 1202 having two-dimensional (x,y) screen co-ordinates, which the user of terminal 104 may translate by imparting a two-dimensional (x,y) motion to mouse 804, whereby said two-dimensional (x,y) motion input data is routed by OS 1001 to application 1003 for processing and then updating said screen co-ordinates if required. GUI 1202 is preferably subdivided into a variety of user-selectable menu commands, for instance on-screen graphical representations of the various queries described in Figure 9. Upon said user translating pointer 1202 over any of said menu commands and providing an interrupt, such as with effecting a mouse button click or a key stroke, application 1003 processes motion input data, correlates the position of said pointer with on-screen menu command positions, then processes database data according to the parameters of the selected query. In the example, a non-exhaustive variety of processing functions provided of application 1003 are represented in GUI 1201 as user-selectable menu commands 'Add Car' 1203, 'Query Car' 1204, 'Query All Cars' 1205, Forecast' 1206 and Notify' 1207. Processed data is thus output to VDU 802 according to step 911.

[0057] The database updating step 906 is further detailed in Figure 13. At step 1301, application 1003 parses an incoming broadcast 1005 to generate runtime data 1006, which it may process. The received unique ID 402 of the emitting module 102, cumulative distance D 405 and threshold distance Dα 403 are thus read and, optionally, the cumulative running time T 406 and the threshold distance Tα 404 are also read or read instead.

[0058] At the next step 1302, application 1003 matches the unique ID 402 of the emitting module 102 to its corresponding database record with looking up the [vehicle_ID] column 1101. Upon establishing said match, a first question is asked at step 1303, as to whether the value of the received cumulative distance D 405 exceeds the corresponding value stored in the column [cumul_dist] 1107. If the question of step 1303 is answered positively, application 1003 replaces the value stored in the column [cumul_ dist] 1107 with the value of said received cumulative distance D 405 at step 1304, such that the record of the vehicle in the database is updated. Alternatively, the question of step 1303 is answered negatively, whereby a second question is asked at step 1305 as to whether the value of the received threshold distance Dα 403 exceeds the corresponding value stored in the column [threshold_dist] 1108. If the question of step 1305 is answered positively, application 1003 replaces the value stored in the column [threshold_dist] 1108 with the value of said received threshold distance Dα 403 at step 1306, such that the record of the vehicle in the database is updated. For instance, question 1305 is answered positively after a vehicle has been maintained and a new Dα value has been input at step 308, thus avoiding the need for double data entry and the inherent risk of discrepancy between then two entries. Alternatively, the question of step 1305 is answered negatively whereby, in an alternative embodiment, a third question is asked at step 1307 as to whether the value of the received cumulative running time T 406 exceeds the corresponding value stored in the column [cumul_ time] 1110. If the question of step 1307 is answered positively, application 1003 replaces the value stored in the column [cumul_ time] 1110 with the value of said received cumulative running time T 406 at step 1308, such that the record of the vehicle in the database is updated. Alternatively, the question of step 1307 is answered negatively, whereby a fourth question is asked at step 1309 as to whether the value of the received maintenance threshold time Tα 404 exceeds the corresponding value stored in the column [threshold_time] 1111. If the question of step 1305 is answered positively, application 1003 replaces the value stored in the column [threshold_time] 1111 with the value of said received threshold running time Tα 404 at step 1310, such that the record of the vehicle in the database is updated. Again, question 1309 is answered positively after a vehicle has been maintained and a new Tα value has been input at step 309. Upon completing the above data updating, application 1003 generates a database record form at step 1311, which it populates with all or a relevant portion of the data relating to the matched unique ID 402 of the emitting module 102 and subsequently outputs to VDU 802 at the next step 1312, an example of which is described further below.

[0059] The database data processing step 911 is further detailed in Figure 14. At step 1401, a first question is asked as to whether the user input identifies a command to create a new record, such as when a new vehicle is sold. If the question of step 1401 is answered positively, application 1003 increments the database record count, wherein a new unique ID 402 is generated in the [vehicle_ID] column 1101 and keyboard input is read in order to update columns [make] 1105, [model] 1106, [threshold_dist] 1108 and [contact] 1109 at step 1402. In an alternative embodiment, keyboard input is read in order to update column [threshold_time] 1111. It is preferable for the user not to be allowed to input data to be referenced in columns [cumul_dist] 1107 and [cumul_time] 1110, as such data should only be generated by module 102 to circumvent any form of odometer tampering. According to the present invention, correlation between distance data broadcast by module 102 stored in database 1004 and actual odometer value in vehicle 101 is not required, as trials of the preferred embodiment have shown the error to be normally not greater than 1.52%, thus wherein module 102-generated distance data is in the order of 1.52% less than vehicle odometer data, i.e. 152 miles in every 10,000 miles, which is trivial. Control subsequently proceeds to step 912.

[0060] Alternatively, the question of step 1401 is answered negatively, whereby a second question is asked at step 1403, as to whether the user input identifies a command to process database data to retrieve records according to parameters, such as when a forecast database query is selected. If the question of step 1403 is answered positively, application 1003 processes said database data according to said parameters. In the example, application 1003 returns database records where the difference between cumulative distance D 405 and maintenance threshold distance Dα 403 represents a percent or less of said maintenance threshold distance Dα 403, i.e. when a vehicle will shortly require maintenance. It will be understood by those skilled in the art that this example is not limitative and may indeed be extended to the alternative running time-based embodiment herein described, or to many more parameters and/or subdivisions and/or combinations thereof. Again, control proceeds to step 912.

[0061] Alternatively, the question of step 1403 is answered negatively, whereby a third question is asked at step 1405, as to whether the user input identifies a command to notify a vehicle user that vehicle maintenance is required. If the question of step 1405 is answered negatively, user input is ignored and control again proceeds to step 912. Alternatively, the question of step 1405 is answered positively, whereby application 1003 processes said database data according to said parameters at step 1406. In the example, application 1003 looks up the [vehicle_ID] 1101 value of the user-selected database record and generates a message, preferably filling a pre-existing template with corresponding record data read from columns [make] 1105, [model] 1106, [cumul_dist] 1107 and [threshold_dist] 1108. Application 1003 then provides the data stored in the corresponding column [contact] 1109 to the communications manager 1002 with a command to broadcast the message according to steps 909, 910 at step 1407, whereby control proceeds to step 912.

[0062] The graphical user interface 1201 of application 1003 is shown in Figure 15 upon performing either of the processing steps 906, 911. In the example, the user of terminal 104 calls application 1003 to process database data according to a forecast query as described at steps 1403, 1404 with translating pointer 1202 over menu command 1206 and effecting a mouse click. Application 1003 thus processes database data according to step 911, whereby results are output to VDU 802 in GUI 1201 as a table 1501 of matching records. Each of said matching records is uniquely identified by its unique ID 402, 1102, 1104 in column [vehicle_ID] 1101. Moreover, the respective, relevant maintenance data of each of said matching records is output in columns [cumul_ dist] 1107 and [threshold_dist] 1108, such that the user of terminal 104 may prioritise vehicle user notification according to the variation between said cumulative and maintenance distances, if required. Application 1003 preferably outputs said table 1501 with a user-selectable Notify' menu command 1502 for each matching record, whereby the user of terminal 104 may translate device pointer 1202 over any such menu command 1502 and provide an interrupt as previously described, in order to answer the question of step 1405 positively. In the example the module 102 having a unique device ID 1103 in column [vehicle_ID] 1101 broadcasts an update to terminal 104 according to step 511, for instance having met the distance comparison condition asked at question 604. Accordingly, application 1003 receives and processes said update according to steps 905, 906, whereby a database record form is generated at step 1311, populated with the unique ID 1103 of the emitting module 102 in column [vehicle_ID] 1101 and maintenance data of the vehicle in columns [cumul_ dist] 1107 and [threshold_dist] 1108. Said form is subsequently output as form 1503 within GUI 1201 to VDU 802 at the next step 1312. Preferably, said form is a pop-up form or window (if OS 1001 supports multiple windowed tasks) to focus the attention of the terminal user upon the event. Preferably still, application 1003 configures form 1503 with user-selectable 'Notify' menu commands 1504 and 'Cancel' 1505, whereby the user of terminal 104 may translate device pointer 1202 over menu command 1504 and provide an interrupt as previously described, in order to answer the question of step 1405 positively. In the example, the user translates device pointer 1202 over menu command 1505 and provides an interrupt as previously described in order to answer the question of step 1405 negatively, as the vehicle does not yet require maintenance.

[0063] It will be appreciated that the operation of the invention is not limited to GPS systems, other positioning systems can be used, for example GNSS and Galileo are systems which can be used to implement the present invention. Furthermore the invention can be carried out using any self locating system, for example technology used in Mobile phone telecommunication technology. Additionally the invention should not be limited to vehicles per se as the invention can be incorporate into mobile machinery or equipment which require maintenance.

[0064] It will also be appreciated that some aspects of the present invention can be used to assist in customer retention, mileage certification for use in example determining business miles travelled, insurance purposes, NCT or MOT testing purposes. The data gathered can be used for forecasting when a parts replacement is due in a vehicle.

[0065] The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

[0066] The embodiments in the invention described with reference to the drawings may comprise a computer apparatus and/or processes performed in a computer apparatus. However, the invention also extends to computer programs, particularly computer programs stored on or in a carrier adapted to bring the invention into practice. The program may be in the form of source code, object code, or a code intermediate source and object code, such as in partially compiled form or in any other form suitable for use in the implementation of the method according to the invention. The carrier may comprise a storage medium such as ROM, e.g. CD ROM, or magnetic recording medium, e.g. a floppy disk or hard disk. The carrier may be an electrical or optical signal which may be transmitted via an electrical or an optical cable or by radio or other means.

[0067] The invention is not limited to the embodiments hereinbefore described but may be varied in both construction and detail.

Claims

1. A system for distributing vehicle maintenance data, comprising at least one module configured with self-locating means, local processing means, memory means and communicating means for attachment to a vehicle and remote processing means configured with communication means, wherein
said self-locating means acquires vehicle location data at time intervals;
said memory means stores instructions, threshold data and said acquired data;
said local processing means is configured by said instructions to process said acquired data into cumulative data and compare said cumulative data to said threshold data according to comparison parameters; whereby
upon said data comparison returning a match, said local processing means instructs said communication means to broadcast said cumulative data to said communication means of said remote processing means.

2. A system according to claim 1, wherein said threshold data and cumulative data is a distance, which may be expressed in any unit of measure such as imperial miles or metric kilometers or sub-divisions thereof.

3. A system according to claim 2, wherein said module is further configured with sensor means for determining whether a vehicle engine is powered up or down, said threshold data and cumulative data also include engine running time, which may be expressed in any unit of measure of time such as a combination of days, hours and minutes.

4. A system according to any of claims 1 to 3, wherein said local processing means is further configured by said instructions to receive and process read requests from said remote processing means, whereby upon receiving a cumulative data read request from said remote processing means, said local processing means instructs said communication means to broadcast said cumulative data to said communication means of said remote processing means.

5. A system according to any of claims 1 to 4, wherein said self-locating means is a Global Positioning Apparatus device receiving time and location data from orbiting satellites.

6. A system according to any of claims 1 to 5, wherein said communication means is a modem configured to exchange data packets over a wireless network, for instance configured according to the Global System for Mobile Communications ('GSM') or General Packet Radio Service ('GPRS') network industry standards.

7. A system according to claim 6, wherein said cumulative data and read request are respectively communicated as text messages using Short Message Service ('SMS') protocol over said wireless network.

8. A system according to claim 7, wherein said remote processing means parse said text messages and store cumulative data therein in a database.

9. A system according to claim 8, wherein said remote processing means is located at one or a plurality of vehicle maintenance providers.

10. A system according to claim 9, wherein said threshold data is updated when said vehicle is maintained by any of said vehicle maintenance providers.

11. A method of distributing vehicle maintenance data, said method comprising the steps of
acquiring vehicle location data at time intervals with self-locating means in at least one module configured with self-locating means, local processing means, memory means and communicating means attached to a vehicle;
storing instructions, threshold data and said acquired data in said memory means;
configuring said processing means with said instructions to process said acquired data into cumulative data;
comparing said cumulative data to said threshold data according to comparison parameters; and
upon said data comparison returning a match, instructing said communication means to broadcast said cumulative data to communicating means of remote processing means.

12. A method according to claim 11, wherein said threshold data and cumulative data is a distance, which may be expressed in any unit of measure such as imperial miles or metric kilometers or sub-divisions thereof.

13. A method according to claim 12, wherein said module is further configured with sensor means and said method includes the further step of determining whether a vehicle engine is powered up or down, whereby said threshold data and cumulative data also include engine running time, which may be expressed in any unit of measure of time such as a combination of days, hours, minutes and seconds.

14. A method according to any of claims 11 to 13, wherein said method includes the further steps of receiving and processing read requests from said remote processing means, whereby upon receiving a cumulative data read request from said remote processing means, said cumulative data is broadcast to said communicating means of said remote processing means.

15. A method according to any of claims 11 to 14, wherein said self-locating means is a Global Positioning Method device receiving time and location data from orbiting satellites.

16. A method according to any of claims 11 to 15, wherein said communication means is a modem configured to exchange data packets over a wireless network, , for instance configured according to the Global System for Mobile Communications ('GSM) or General Packet Radio Service ('GPRS') network industry standards.

17. A method according to claim 16, wherein said cumulative data and read request are respectively communicated as text messages request are respectively communicated as text messages using Short Message Service ('SMS') protocol over said wireless network.

18. A method according to claim 17, wherein said method includes the further steps of parsing said text messages and storing cumulative data therein in a database at said remote processing means.

19. A method according to claim 18, wherein said remote processing means is located at one or a plurality of vehicle maintenance providers.

20. A method according to claim 19, wherein said method includes the further step of updating said threshold data when said vehicle is maintained by any of said vehicle maintenance providers.

21. A computer system programmed to execute stored instructions such that in response to said stored instructions said system is configured to:

acquire vehicle location data at time intervals from self-locating means;

store threshold data and said acquired data in memory means;

process said acquired data into cumulative data;

compare said cumulative data to said threshold data according to comparison parameters; and

upon said data comparison returning a match, instruct communication means to broadcast said cumulative data to communicating means of a remote terminal.

22. A computer-readable memory system having a plurality of data fields stored therein representing a data structure, wherein said data structure includes vehicle location data at time intervals, cumulative data and threshold data and further having instructions configured to:

process said vehicle location data at time intervals into said cumulative data;

compare said cumulative data to said threshold data according to parameters; and

broadcast said cumulative data to a remote terminal upon said data comparison returning a match.

23. A module for attachment to a vehicle for distributing vehicle maintenance data, comprising self-locating means, local processing means, memory means and communicating means, wherein
said self-locating means acquires vehicle location data at time intervals;
said memory means stores instructions, threshold data and said acquired data;
said local processing means is configured by said instructions to process said acquired data into cumulative data and compare said cumulative data to said threshold data according to comparison parameters; whereby
upon said data comparison returning a match, said local processing means instructs said communication means to broadcast said cumulative data.

24. A kit of parts for distributing vehicle maintenance data, said parts including at least one module configured with self-locating means, local processing means, memory means and communicating means for attachment to a vehicle and remote processing means configured with communication means, wherein
said self-locating means acquires vehicle location data at time intervals;
said memory means stores instructions, threshold data and said acquired data;
said local processing means is configured by said instructions to process said acquired data into cumulative data and compare said cumulative data to said threshold data according to comparison parameters; whereby
upon said data comparison returning a match, said local processing means instructs said communication means to broadcast said cumulative data to said communication means of said remote processing means.

Drawing