Method for determining preferred conditions for wireless programming of mobile devices

[0001] 1. Field of the Invention

[0002] The invention relates to wireless programming of mobile devices.

[0003] 2. Related Art

[0004] Using wireless communication, mobile devices can communicate with an application server while continuing to move about. This allows the application server to provide information about the mobile devices to a customer, and to provide information from the customer to the mobile devices, all without any substantial need for restricting the mobility of those mobile devices. For example, one known application includes a system that tracks locations of such mobile devices and reports those locations to the customer.

[0005] In known applications, each mobile device periodically provides application information to the application server (such as, for a tracking application, the location of the mobile device) along with information identifying the specific mobile device (such as a unique identifier or electronic serial number). The choice of particular information, and the frequency of its delivery, provided by the mobile device might vary substantially depending on the nature of the application. Known systems include a processing element in the mobile device, which under the control of program and data memory, can perform tasks required by any specific application for which appropriate instructions have been recorded in that memory.

[0006] One known problem is that of altering the instructions or parameters re-corded in the memory of the mobile device. This is desirable from time to time, such as to update the instructions in the mobile device with new features or to update the instructions in the mobile device with new instructions with corrections to known bugs. Because it is generally desirable, for ease of administration and for consistency, for substantially all mobile devices to operate using the same instructions and parameters, desired times for updates to the instructions or parameters in the mobile device might be frequent. Physically replacing the memory, or physically traveling to the mobile device to program the memory, are untenably costly. Accordingly, known systems attempt to record instructions in the memory by sending information embodying those instructions using wireless communication. While known techniques generally achieve the goal of downloading new program information to the mobile device, they are subject to several drawbacks.

[0007] First, because it can take a substantial amount of time to download a new program for the mobile device, it is generally necessary to agree with a customer associated with the mobile device on a scheduled time for performing wireless programming. Otherwise, the mobile device might be busy, might not be in an area with good wireless reception, or might be used for normal operation during the time needed for wireless programming. This drawback is exacerbated by the time, effort, and expense of contacting the customer, agreeing on a wireless programming schedule, and assuring that the mobile devices (if there are many, and there often are) are in fact ready for wireless programming at the scheduled times.

[0008] Second, also because it can take a substantial amount of time to download a new program for the mobile device, it is generally necessary for the mobile device to be quiescent for the entire time needed for performing wireless programming. Otherwise, the downloaded program for the mobile device might fail to be received and injected into the mobile device's memory properly, thus causing either (1) the mobile device to work improperly after wireless programming, (2) the mobile device to require on-site programming to repair the improper download, or both.

[0009] Accordingly, it would be advantageous to provide an improved technique for scheduling and performing wireless programming.

[0010] The invention provides a method and system capable of automatically scheduling times for wireless programming of selected mobile devices, and automatically performing wireless programming of those mobile devices at the scheduled times. A server device examines a history of a selected target mobile device (or a selected substitute for the target mobile device, such as a similar device, another device in a related pool of such devices, another device used by the same owner, or another device used in the same industry or for the same purpose), and in response to that history, predicts a “good” set of times for programming the mobile device. The server device confirms that the mobile device is ready for wireless programming at the predicted time, buffers the programming download at the mobile device, and directs the mobile device to inject the programming download into its program memory. The programming download might include new operating system firmware or software, new application software, new data, or a diagnostic program for collecting information; there is no particular requirement that the programming download is persistently retained at the client after its purpose is served. In preferred embodiments, the server device is capable of optionally informing a customer associated with the mobile device before or after performing automated wireless programming (or both).

[0014] Inventions described herein can be used in conjunction with technology de-scribed in the following documents:

• • [0015] U.S. patent application Ser. No. 09/698,888 (Express Mail Mailing No. EL 487 707 095 US), filed Oct. 27, 2000, in the name of Kulbir SANDHU and Rodric FAN, titled “System and Method for Just-in-time Vehicle Maintenance”, and ap-plications claiming priority therefrom.

[0016] These documents are hereby incorporated by reference as if fully set forth herein, and are sometimes referred to herein as the “incorporated disclosures”.

[0017] In the description herein, a preferred embodiment of the invention is de-scribed, including preferred process steps and data structures. Those skilled in the art would realize, after perusal of this application, that embodiments of the invention might be implemented using a variety of other techniques not specifically described, without undue experimentation or further invention, and that such other techniques would be within the scope and spirit of the invention.

Lexicography

[0018] The following terms relate or refer to aspects of the invention or its embodiments. The general meaning of each of these terms is intended to be illustrative and in no way limiting.

[0019] activity information—In general, this refers to information regarding the recent operation of the mobile device, such as for example historical or operational data regarding the position and status of the mobile device and its associated vehicle. Although the invention is described with regard to wireless programming of mobile bile devices that are disposed in vehicles, there is no particular requirement that mobile devices are so limited. Moreover, there is no particular requirement that activity information must refer to the target device; it might refer to a selected substitute for the target mobile device, such as a similar device, another device in a related pool of such devices, another device used by the same owner, or another device used in the same industry or for the same purpose.

[0020] buffer and inject (for control information)—In general, this refers to the mo-bile device receiving control information from the server device, temporarily storing that control information in a buffer, and then moving that control information from the buffer to its program and data memory. In a preferred embodiment, the control information is buffered while it is being received, then injected into the program and data memory in an atomic operation. However, there is no particular requirement for using a separate buffer, and in alternative embodiments, wireless programming can include direct transfer into a control memory for the mobile device.

[0021] control information—In general, this refers to programming instructions (such as for example firmware or applications for use by the mobile device), data for use with those programming instructions, or other information (such as for example operational parameters) for use by the mobile device. As noted herein, the concept of “control information” is broad, and is intended to include at least the following: firmware program instructions, firmware parameter values, operating system program instructions, operating system parameter values, application program instructions, application parameter values, commands or requests to be received and acted upon by a program at the mobile device, tests to be performed at or by the mobile device, and the like.

[0022] customer—In general, this refers to an individual or other entity associated with the mobile device and responsible for (or using) the vehicle in which the mobile device is disposed. In a preferred embodiment, the customer generally includes a dispatch operator or other person responsible for directing the mobile device's ve-hide to a selected location (such as a parking garage) at selected times. However, in alternative embodiments, the customer might have a different relationship with the vehicle or the mobile device, such as a fleet operator or a vehicle lessor.

[0023] download—In general, this refers to a process of sending control information from the server device to the mobile device. In a preferred embodiment, the download operation might include feedback from the mobile device back to the server device, as for example in communication protocols where the receiver sends acknowledgement messages (or other responsive messages) from time to time.

[0024] mobile device—In general, this refers to a device logically and possibly physically remote from the programming server. Although there might be many such mobile devices, they are generally referred to one at a time below, except where that might be confusing. As described below, in a preferred embodiment, the mo-bile device is associated with a vehicle and might be located within a wide range of possible locations. In those cases when a specific mobile device is selected for wireless programming, that one mobile device is sometimes referred to herein as the target device. There is no particular requirement for any predefined association between the mobile device and the vehicle. The mobile device might be manufactured with the vehicle, factory-installed in the vehicle, dealer-installed in the vehicle, installed in the vehicle as an after-market product, or simply carried in the vehicle without being attached thereto (such as for example in a glove box or trunk, or on a passenger seat).

[0025] (server) administrator—In general, this refers to an individual or other entity responsible for administering, scheduling, and performing wireless programming of the mobile device. There is no particular requirement that the server administrator is a single person; in some embodiments the server administrator might include multiple persons with the authority to act individually or collectively.

[0026] server device—In general, this refers to a device logically and possibly physically remote from the mobile device(s) and/or the server administrator. As described below, in a preferred embodiment, the server device is associated with a programming administrator. There is no particular requirement that the server device is a single hardware “device.” In some embodiments, the server device might include multiple devices operating cooperatively (such as when networked) or might include a portion of one or more devices.

[0027] (wireless) programming—In general, this refers to sending control information from the server device to the mobile device. Wireless programming is also known as OTAP (over-the-air programming). As noted below, there is no particular requirement for the invention that “wireless” programming is actually wireless.

[0028] The scope and spirit of the invention is not limited to any of these definitions, or to specific examples mentioned therein, but is intended to include the most general concepts embodied by these and other terms.

System Elements

[0029] FIG. 1 shows a block diagram of a system including wireless programming of mobile devices.

[0030] A system 100 includes a customer portion 120, a server portion 140, and a (wireless) communication link 180.

Customer Portion

[0031] The customer portion 120 refers generally to those aspects of the system 100 that are logically under control of, or otherwise associated with, a customer or other user. The customer might be an individual, a company, or another entity. In a preferred embodiment, where the customer is a company, the customer might include more than one person who interacts with the system 100 from time to time, such as both a driver of a vehicle carrying the mobile device and a dispatcher at a central station with whom the driver interacts.

[0032] In a preferred embodiment as described herein, the vehicle includes an automobile or truck. However, in alternative embodiments, the vehicle might be differ-ent, such as an airplane or other aircraft, boat or other marine vessel, railroad car, or other type of vehicle. There is also no particular requirement that all “vehicles” must be the same type; thus, a first vehicle might be a truck while a second vehicle (associated with the same customer) might be a hovercraft.

[0033] The customer portion 120 includes a customer 122 or other user and a mo-bile device 124. The mobile device 124 is preferably disposed in a mobile housing 126, such as a vehicle. (The vehicle might of course be any type of vehicle: a truck, an auto-mobile, a bicycle, a motorcycle, a scooter or skateboard, or any other type of wheeled vehicle, a boat or canoe or submarine or other marine vessel, a train, an airplane or helicopter or other aircraft, a sled, an elevator, or any other type of vehicle.) However, the concept of the invention is general enough to include systems 100 in which the mobile housing 126 is a hand-carried device, such as a pager, a PDA (personal digital assistant) or other handheld computer, a notebook or laptop computer, a telephone, a watch, a location or condition sensor, a biometric sensing or reporting device, a pacemaker, a telemetry device, or a remote homing device.

[0034] In a preferred embodiment, the mobile device 124 includes a transceiver 128, having an antenna, a receiver, and a transmitter. However, the concept of the invention is general enough to include systems 120 in which the mobile device 124 makes use of an attached transceiver, such as a cellular or satellite telephone, a radio transceiver, a microwave transceiver, a wireline modem, or any other device capable of communication with the server portion 140, on behalf of the mobile device 124, using the communication link 180.

[0035] In a preferred embodiment, the mobile device 124 includes a controller 130, having a processing element 132, program and data memory 134, and buffer memory 136.

[0036] The mobile device 124 operates under control of the processing element 132, which itself operates under control of selected control information 138, including instructions and selectable parameters, disposed in the memory 134.

[0037] The buffer memory 136 is coupled to the transceiver 128 and to the memory 134, and is disposed for receiving at least a portion of the control information 138 from the server portion 140 of the system 100 and for injecting that control information 138 into the memory 134.

Server Portion

[0038] The server portion 140 refers generally to those aspects of the system 100 that are logically under control of, or otherwise associated with, an administrator or other operator for updating the control information 138 at the mobile device 124. The administrator might be an individual, a company, or another entity. In a preferred embodiment, where the administrator is a company, the administrator might include more than one per-son who interacts with the system 100 from time to time, such as both an engineer who might alter the control information and a service administrator who might communicate with the customer about updating the control information 138.

[0039] The server portion 140 includes a server administrator 142 and an update server 144.

[0040] The update server 144 formulates data for sending by a transceiver 148, the transceiver 148 having an antenna, a receiver, and a transmitter. However, the concept of the invention is general enough to include systems 120 in which the update server 144 formulates data for sending by a detachable transceiver, such as a cellular or satellite telephone, a radio transceiver, a wireless or wireline modem, or any other device capable of communication with the server portion 140 using the communication link 180.

[0041] The update server 144 includes a controller 150, having a processing element 152, and program and data memory 154.

[0042] The update server 144 operates under control of the processing element 152, which itself operates under control instructions 156 (and selectable parameters) disposed in the memory 154. The instructions 156 include an update module 158 and a pre-diction module 160. The update module 158 is disposed for sending the updated control information 168 from the memory 154 to the transceiver 148, to send that updated control information 168 using the wireless communication link 180 to the mobile device 124.

[0043] The prediction module 160 is coupled to an activity database 162, including a set of activity records 164 relating to activity information about the mobile device 124. In a preferred embodiment, the activity records 164 are constructed from activity information received from the mobile device 124 from time to time, when the mobile device 124 reports its status and that of its associated vehicle 126. The prediction module 160 is disposed for reviewing the activity records 164 and for constructing a proposed schedule 166 for wireless programming of the mobile device 124.

[0044] Although in a preferred embodiment, the prediction module 160 determines the proposed schedule 166 for wireless programming of the mobile device 124, it is also possible that the update server 144 might, at the selected time for wireless programming, contact the mobile device 124 to determine if the mobile device 124 is in fact ready for wireless programming at that time. For example, the update server 144 might query the mobile device 124 for the latter's latest activity information and the latter's non-historical (that is, very recent) information regarding connection speed, communication protocol, location, and the like.

Wireless Communication Link

[0045] The wireless communication link 180 includes a communication network having at least one wireless communication path between the customer portion 120 and the server portion 140. In a preferred embodiment, the wireless communication path includes a wireless cellular or satellite telephone connection, such as might be available from a voice cellular or satellite telephone provider (in combination with a voice/data modem, to transmit data other than voice) or such as might be available from a data cel-lular provider or satellite data link.

[0046] Those skilled in the art will recognize, after perusal of this application, that the invention has no particular limitation to only wireless communication. The invention can be used with wireline communication, or with communication using a communication network that includes both wireless and wireline communication paths (and does not force communication to use either one). Although a preferred embodiment of the invention uses wireless communication, due to the mobile nature of the mobile devices to be programmed and their likely lack of connectivity using only wireline communication paths, there is no particular limitation of the nature of the invention to wireless only.

Method of Operation

[0047] FIG. 2 shows a process flow diagram of a method including wireless programming of mobile devices.

[0048] A method 200 is performed by the system 100. Although the method 200 is described serially, the flow points and steps of the method 200 can be performed by separate elements in conjunction or in parallel, whether asynchronously or synchronously, in a pipelined manner, or otherwise. There is no particular requirement that the method 200 must be performed in the same order in which this description lists flow points or steps, except where explicitly so indicated.

[0049] At a flow point 210, the update server 144 is ready to update mobile de-vices 124 with new control information 168.

[0050] At a step 211, the server administrator 142 issues a command to the update server 144 to update mobile devices 124 with updated control information 168. The command might be an explicit command, or might be an update to the activity database 162, indicating that updated control information 168 is available, which the update server 144 can send to mobile devices 124.

[0051] At a step 212, the update server 144 determines to which mobile devices 124 to send the updated control information 168. To perform this step, the update server 144 performs the following sub-steps:

[0052] At a sub-step 212a, the update server 144 identifies what application features or application programs are dependent, at least in part, on the updated control information 168. In a preferred embodiment, the update server 144 finds this information in the activity database 162. A result of this sub-step is a list of application features or application programs.

[0053] At a sub-step 212b, the update server 144 identifies which mobile devices 124 have the application features or application programs identified in the sub-step 212a. In a preferred embodiment, the update server 144 finds this information in the activity database 162. A result of this sub-step is a list of mobile devices 124.

[0054] Those skilled in the art will recognize, after perusal of this application, that the list of mobile devices 124 identified by this sub-step will typically include many, if not all, of the mobile devices 124 assigned to a particular customer 122. In a preferred embodiment, the update server 144 records its identification of these customers 122, so as to inform them of the updated control information 168. In preferred embodiments, the update server 144 might (responsive to commands from its operator) select groups of mobile devices 124 for wireless programming in response to groupings of those mobile devices 124: those in a selected geographic area or near a selected geographic location, those associated with a selected customer or a selected class of customers (such as a “premium” customer or a “discount” customer), and the like. Those skilled in the art will recognize, after perusal of this application, that grouping of mobile devices 124 to be selected for wireless programming can be quite flexible, and thus be made in response to many other factors not explicitly recited herein.

[0055] At a flow point 220, the update server 144 has identified which target mo-bile devices 124 to send the updated control information 168.

[0056] At a step 221, the update server 144 identifies what technical conditions are desired when sending the updated control information 168 to mobile devices 124. In a preferred embodiment, the update server 144 finds this information in the activity data-base 162, as placed there by the server administrator 142 or another entity, or queries the device using the communication link 180 to obtain status information or technical information about the mobile device 124. (It might occur that the mobile device 124 itself has the most current information about its status or its technical elements than is available in the activity database 162, possibly because the mobile device 124 has been updated in the field, or possibly because the activity database 162 is not current, or possibly because that information in the activity database 162 is not available at the time when this step is per-formed.)

[0057] In a preferred embodiment, these technical conditions might include

• • [0058] a choice of locating or positioning technique used to determine a location for the target mobile device 124 (GPS is preferred, but alternatives include TDOA, AOA, AGPS, or some other technique);
  • [0059] a minimum value of signal strength received by the target mobile device 124;
  • [0060] a minimum amount of idle time to be used by the process of updating the control information 138 at the target mobile device 124; and
  • [0061] any financial or administrative constraints on the process of updating the control information 138 at the target mobile device 124 (such as for example a maximum wireless communication charge).

[0062] As part of this step, the update server 144 identifies what transmission technique, including (if more than one is available) a transmission protocol and (if more than one is available) a communication path, is desired when sending the updated control information 168 to mobile devices 124.

[0063] In a preferred embodiment, the transmission technique might be selected in response to conditions such as

• • [0064] administrative requirements, such as minimized cost or maximized reliability within a selected period of time, or such as security of transmission, and the like;
  • [0065] characteristics of the updated control information 168, such as its length, its sensitivity to error, and the like;
  • [0066] suitability or quality of the transmission technique for wireless programming, whether in general or for the particular selected updated control information 168;
  • [0067] signal strength or other characteristics of the signal, such as possibly noise or other interference, the spectrum for noise or other interference, and whether such noise or other interference is bursty or random, and the like.

[0068] At a flow point 230, the update server 144 has identified what technical conditions are desired when sending the updated control information 168 to mobile de-vices 124.

[0069] At a step 231, the update server 144 determines, for each target mobile de-vice 124, a prediction of future occurrence of all, or a minimum set of, such conditions, including analysis of that prediction regarding to what extent those conditions are satisfied, and which times would provide the best predicted probability of a successful wireless programming operation. A preferred method of performing this step is described with reference to FIG. 3.

[0070] At a step 232, the update server 144 determines in what order to update the target mobile devices 124. There is no particular requirement that the update server 144 choose any particular order. However, in a preferred embodiment, the update server 144 might select the order to update the target mobile devices 124 in response to one or more of, or some combination of, these factors:

• • [0071] a probability of success for the wireless programming operation, so that for example the target mobile devices 124 are selected to maximize a number of successfully completed wireless programming operations during a selected time duration;
  • [0072] a time order of the earliest available window for the wireless programming operation, so that for example the target mobile devices 124 are selected to minimize an expected amount of time between scheduling and actual performance of the wireless programming operation;
  • [0073] an amount of data to be sent during the wireless programming operation, so that for example a relatively larger number of target mobile devices 124 might have their wireless programming operation performed first if that wireless programming operation is relatively quick;
  • [0074] a cost of the wireless programming operation, so that for example a total cost of wireless programming is substantially minimized; and
  • [0075] a request by the customer associated with the target mobile devices 124, so that for example perceived responsiveness to the customer request is optimized;

[0076] Those of ordinary skill would recognize, after perusal of this application, that the operation of scheduling for any particular target mobile device 124, and the operation of actually performing wireless programming for that particular target mobile device 124, need not be the same order. Moreover, those of ordinary skill would recognize, after perusal of this application, that the operation of sending the updated control information 168 to the target mobile device 124, and the operation of injecting and executing that updated control information 168, also need not be the same order.

[0077] The next step is optional, and may be omitted in a preferred embodiment.

[0078] At an (optional) step 233, the update server 144 presents its update schedule to the server administrator 142 and requests approval. If the server administrator 142 approves, the method 200 proceeds with the next step. If the server administrator 142 disapproves, the method 200 returns to the flow point 230 to determine a revised schedule.

[0079] If the update server 144 is unable to find an acceptable schedule, it presents a signal to the administrator 142 and receives a suggested schedule from the administrator 142. In a preferred embodiment, the administrator 142 will likely contact the customer 122 and negotiate an acceptable schedule.

[0080] In alternative embodiments, the contact with the customer 122 may be automatically generated and performed, such as for example by sending a pre-formatted email message. The pre-formatted email message may query the customer 122 for times when the desired conditions would be present, and allow the customer to reply using a machine-readable format. Instead of an email message, a link to a web site using an HTTP “post” technique may be used. If automatic contact is unsuccessful, the administrator 142 may then contact the customer 122 and negotiate an acceptable schedule.

[0081] The next step is optional, and may be omitted in a preferred embodiment.

[0082] At an (optional) step 234, the update server 144 presents its update schedule to the customer 122 and requests approval. If the customer 122 approves, the method 200 proceeds with the next step. If the customer 122 disapproves, the method 200 returns to the flow point 230 to determine a revised schedule.

[0083] If the update server is unable to find an acceptable schedule (that is, one that is acceptable to both the server portion 140 and optionally to the customer 122), it presents a signal to the administrator 142 and receives a suggested schedule from the administrator 142. In a preferred embodiment, the administrator 142 will likely contact the customer 122 and negotiate an acceptable schedule.

[0084] At a flow point 240, the update server 144 is ready to perform wireless programming using the schedule.

[0085] At a step 241, the update server 144 selects an individual mobile device 124 (for which it has been predicted that the desired conditions are present) and determines if that mobile device 124 is ready to receive new control information 168. In a preferred embodiment, the update server 144 contacts the mobile device 124, queries the latter's state, and compares that state against its set of desired conditions. If a minimum set of desired conditions is not met, the update server 144 concludes that the mobile device 124 is not ready, and the mobile device 124 is rescheduled for another time (at other steps in the method 200).

[0086] At a step 242, the update server 144 directs the mobile device 124 to adjust its parameters (if required) to optimize receipt of updated control information 168. If the parameters for the mobile device 124 are already optimized, there is no particular requirement to adjust them. In a preferred embodiment, these parameters might include

• • [0087] a control parameter for power management, such as a power management timer (sometimes called a “sleep time”) for the mobile device 124 to remain powered-up but inactive.

[0088] At a step 243, the update server 144 sends new control information 168 to the mobile device 124. The mobile device 124 receives the new control information 168 and records it in its buffer memory 136. As part of this step, the update server 144 waits for the mobile device 124 to acknowledge successful receipt of the new control information 168. If successful receipt is not acknowledged on a first try, this step is repeated until the new control information 168 is successfully received. Although not described in detail herein, it would be clear to those skilled in the art, after perusal of this application, to include a retry-count or timeout provision so that this step is not repeated continually for too long.

[0089] At a step 244, the update server 144 directs the mobile device 124 to inject the new control information 168 from its buffer memory 136 into its program and data memory 134. As part of this step, the update server 144 waits for the mobile device 124 to acknowledge success. If success is not acknowledged on a first try, this step is repeated until the new control information 168 is successfully injected from the buffer memory 136 into the program and data memory 134. Although not described in detail herein, it would be clear to those skilled in the art, after perusal of this application, to include a retry-count or timeout provision so that this step is not repeated continually for too long.

[0090] At a step 245, the update server 144 directs the mobile device 124 to report its status. As part of this step, the update server 144 waits for the mobile device 124 to report a quiescent status. If the mobile device 124 does not report a quiescent status on the first try, this step is repeated until the mobile device 124 reports successfully.

[0091] If the update server 144 is unable to cause the mobile device 124 to report successfully, it returns to the flow point 240 and re-attempts the wireless programming operation.

[0092] If the update server 144 is unable to successfully perform the wireless programming operation after multiple tries, it presents a signal to the administrator 142 and waits for the administrator 142 to reset the mobile device 124 by another means. In a preferred embodiment, the administrator 142 will likely contact the customer 122 and cause the mobile device 124 to be reset in person.

[0093] The next step is optional, and may be omitted in a preferred embodiment.

[0094] At an (optional) step 246, the update server 144 presents a signal to the customer 122 to the effect that it was successful at wireless programming of the mobile device 124.

[0095] At a flow point 250, the update server 144 has completed wireless programming of the selected mobile device 124. In a preferred embodiment, the update server 144 repeats the steps of the method 200 with regard to each mobile device 124 to be programmed.

[0096] In a preferred embodiment, the update server 144 batches multiple mobile devices 124 for concurrent scheduling and wireless programming.

[0097] For example, in a preferred embodiment, the update server 144 collects all mobile devices 124 associated with a single customer 122 for concurrent scheduling, so that the customer 122 can approve or reject the proposed schedules in a single message (or a relatively small number of messages).

[0098] Similarly, in a preferred embodiment, the update server 144 collects all mobile de-vices 124 associated with a single customer 122 for concurrent wireless programming, so that the mobile devices 124 can be programmed in a group substantially in parallel.

[0099] For example, the update server 144 can initiate programming for a first selected mobile device 124 in the group, then for a second selected mobile device 124 shortly thereafter (perhaps 30 seconds later), and so on, so that programming for the entire group can be performed in less time than if the mobile devices 124 were individually programmed serially. Thus, if it takes 10 minutes to program an individual mobile device 124, a set of 60 such mobile devices 124 could be programmed in about 40 minutes (30 minutes delay from start of the first mobile device 124 to start of the last mobile device 124, plus 10 minutes programming time for the last mobile device 124), rather than in about 10 hours (10 minutes each times 60 separate mobile devices 124).

Method of Scheduling Preferred Times

[0100] FIG. 3 shows a process flow diagram of a method including prediction of preferred times for wireless programming of mobile devices.

[0101] A method 300 is performed by the prediction module 160. Although the method 300 is described serially, the flow points and steps of the method 300 can be per-formed by separate elements in conjunction or in parallel, whether asynchronously or synchronously, in a pipelined manner, or otherwise. There is no particular requirement that the method 300 must be performed in the same order in which this description lists flow points or steps, except where explicitly so indicated.

[0102] At a flow point 310, the prediction module 160 is ready to schedule a set of preferred times for wireless programming of the selected target mobile device 124.

[0103] At a step 311, the prediction module 160 (working with the recent records from the activity database 162) selects those records that refer to the target mobile device 124.

[0104] At a step 312, the prediction module 160 (working with a result of the previous step) selects those records that refer to a “stopped” condition. In a preferred embodiment, it is desirable that the vehicle 126 is stopped, that is, not moving or operating. In a preferred embodiment, “stopped” generally refers to a relatively continuous time duration, such when the vehicle 126 is actually parked. Although a parked vehicle 126 is preferred, there is no particular requirement therefor; the invention includes those embodiments in which the vehicle 126 is considered stopped in a number of other conditions, such as if it is parked with the motor running, stopped and idling, stopped at a traffic light or stop sign, and the like. In alterative embodiments, it may be acceptable for the vehicle 126 (or other package in which the mobile device 124 is disposed or deployed) to be in a differently defined state, such as “idle”, “off”, “quiescent”, or even to be in a relatively active state that does not interfere with wireless programming, such as if the mobile device 124 is merely running diagnostics.

[0105] At a step 313, the prediction module 160 (working with a result of the previous step) applies business rules to de-select unlikely records. In a preferred embodiment, the business rules are designed to discard those activity records 164 corresponding to cases unlikely (for business reasons) to be “true” quiescent states of the vehicle 126. For example, the business rules might include the following

[0106] Only include those activity records 164 corresponding to times outside normal business hours (such as for example, 9:00 a.m. to 5:00 p.m.).

[0107] Only include those activity records 164 corresponding to locations at or near the parking facility where the vehicle 126 is parked overnight.

[0108] Exclude those activity records 164 corresponding to locations outside the normal operational area of the vehicle 126.

[0109] Those skilled in the art would recognize, after perusal of this application, that this set of business rules is only exemplary. There is no particular requirement that the invention is limited to this exemplary set.

[0110] At a step 314, the prediction module 160 (working with a result of the previous step) applies technical rules to de-select unacceptable records. In a preferred embodiment, the technical rules are designed to discard those activity records 164 corresponding to cases unlikely (for technical reasons) to be “true” quiescent states of the vehicle 126. For example, the business rules might include the following

[0111] Require a “stopped” time of at least 30 minutes.

[0112] Require a minimum signal strength, for the entire “stopped” time, of at least 30 db (decibels) more than the minimum programming signal strength.

[0113] Those skilled in the art would recognize, after perusal of this application, that this set of technical rules is only exemplary. There is no particular requirement that the invention is limited to this exemplary set.

[0114] At a step 315, the prediction module 160 (working with a result of the previous step) applies a goodness-of-match technique to select records that are sufficiently similar.

[0115] To perform this step, the prediction module 160 performs the following sub-steps.

[0116] At a sub-step 315a, the prediction module 160 wraps the time associated with each activity record 164 to a 24-hour periodic time window.

[0117] At a sub-step 315b, the prediction module 160 (working with a result of the previous sub-step) associates those activity records 164 having similar time values (that is, time values within an error parameter e_t). In a preferred embodiment, the parameter e_t is selected to be less than about 15 minutes.

[0118] At a sub-step 315c, the prediction module 160 (working with a result of the previous sub-step) selects those activity records 164 that meet the technical requirements noted with regard to the step 314 (minimum stop time, minimum signal strength).

[0119] At a sub-step 315d, the prediction module 160 (working with a result of the previous sub-step) selects those activity records 164 that have a similar location (that is, location within an error parameter e_s). In a preferred embodiment, the parameter e_s is measured using a rectilinear distance (that is, a maximum of north-south distance and east-west distance) and is selected to be less than about 1 city block.

[0120] At a sub-step 315e, the prediction module 160 (working with a result of the previous sub-step) selects those activity records 164 that have a similarity count (that is, a number of records that are similar for a selected time window within the 24-hour time period) that is similar enough for prediction (that is, greater than a selected threshold parameter T). In a preferred embodiment, the threshold parameter T is selected to be greater than about 50% of the time.

[0121] At a step 316, the prediction module 160 (working with a result of the previous step) selects a best choice from among those available choices of sets of time windows.

[0122] To perform this step, the prediction module 160 performs the following sub-steps.

[0123] At a sub-step 316a, the prediction module 160 calculates a quality-of-choice value in response to selected business and technical parameters. In a preferred embodiment, these business and technical parameters include

[0124] A length of the stop time associated with the activity records 164 (a longer stop time is better).

[0125] A time of day for the activity records 164 (a time of day after business hours is better).

[0126] An off-peak or on-peak value associated with the time of day (off-peak hours are better because they are typically less expensive for wireless communication).

[0127] A home-system or roaming value associated with the location for the activity records 164 (a home-system value is better because it is typically less expensive for wireless communication).

[0128] Those skilled in the art would recognize, after perusal of this application, that this set of business and technical parameters is only exemplary. There is no particular requirement that the invention is limited to this exemplary set.

[0129] At a sub-step 316b, the prediction module 160 selects the time window with the best calculated quality-of-choice value.

[0130] At a flow point 320, the prediction module 160 has completed scheduling a set of preferred times for wireless programming of the selected target mobile device 124.

[0131] Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention. These variations would become clear to those skilled in the art after perusal of this application.

[0132] The invention applies to any control information to be used with or injected into the mobile device 124, not just to firmware programming. However, in a preferred embodiment, the invention is primarily used for firmware programming of mobile devices 124.

[0133] The invention applies to any mobile device 124, not just to those disposed in vehicles 126. However, in a preferred embodiment, the invention is primarily used for mobile devices 124 disposed in vehicles 126 having GPS location apparatus and capable of reporting their position from time to time (such as periodically or in response to a query from a server associated with the administrator 142). There is no particular limitation of the invention to GPS location; for example, the invention can also use position information obtained by cellular triangulation data.

[0134] The invention applies to data mining for other facts regarding activity records 164 for mobile devices 124, not just to those windows of time when the mobile devices 124 are best programmed. The following possibilities are exemplary.

[0135] The invention can be used to determine those areas of low signal strength, in response to signal strength information (and signal outages) found in activity records 164 and correlated with selected position information.

[0136] The invention can be used to determine those areas where mobile devices 124 should change carriers for wireless communication, in response to signal strength information (and signal outages), position information, and wireless carrier cost information.

[0137] The invention can be used to alert customers 122 to those vehicles 126 likely to become unavailable for wireless communication, in response to signal strength information (and signal outages) and position information.

[0138] The invention can be used to inform customers 122 of likely locations for those vehicles 126 that are unavailable for wireless communication, in response to his-toric areas of low signal strength (or no signal) and recent position information for those vehicles 126.

[0139] The invention applies to predicting or selecting conditions related to operation of any client-server relationship. The following possibilities are exemplary.

[0140] There is no particular requirement that the client (in a client-server relationship) is actually a mobile device, or that the client device is coupled to the server using a wireless communication link. For a first example, the client-server relationship can involve an internet connection between a web browser and a web server, with some number of intervening routing or switching devices. For a second example, the client-server relationship can involve an internet connection between an application program and an upgrade server, where the upgrade server provides bug-fixes, upgrades, or other information to the application program. If the application program were a virus-checking program, the update information could include information about new viruses.

[0141] There is no particular requirement that the server (in a client-server relationship) is the one to initiate the programming (or other download). For example, the client, referred to herein as the mobile device, might initiate the transaction by telling the server it needs some information. The server (having determined that downloading the information would take awhile) could respond by telling the client the requested information would arrive, select when, and so inform the client. As part of initiating the transaction, the client might also propose a set of preferred times for wireless programming, or other information that might assist the server in selecting the actual time wireless programming is conducted.

[0142] There is no particular requirement that the primary information path is from the server to the client (in a client-server relationship). For a first example, in addition to wireless programming, techniques shown herein could be used for requesting information to be sent from the client to the server, instead of or in addition to the other way around. Thus, wireless programming can include also over-the-air status requests by the server. For a second example, the server could send to the client a diagnostic program for examining or testing the client, so that the program could send results back to the server, even if the diagnostic program is not persistently retained at the client.

[0143] Those skilled in the art will recognize, after perusal of this application, that these alternative embodiments are illustrative and in no way limiting.