Patent Application
20110010383
The present invention relates generally to computer networks, and more particularly to methods and systems for accomplishing over-the-air and over-the-wire management of computing devices.
The Open Mobile Alliance (OMA) has issued a Device Management (DM) technical specification which standardizes methods, messaging formats and commands for managing devices remotely, such as via over-the-air or over-the-wire communication links. The term device management refers to managing device configurations, provisioning client applications, and detecting problems of remote devices from servers.
Methods and systems enable streamlining remote device management by eliminating the need for device management servers to download device configuration data from remote computing devices when no changes have been made to device configuration data since the last device management session with the server. A computing device may record data enabling it to determine whether configuration data has been changed since the last update session with a device management server. Device management servers may record configuration data of computing devices with which they perform update services. While initiating a device management session, a computing device can inform the device management server whether an intervening configuration data change has occurred. If no intervening configuration data changes have occurred, the device management server can forgo commanding the computing device to download its configuration data, thereby saving communication time and bandwidth. In an alternative embodiment, the remote computing device may send to the device management server the URI of the item that has been changed since the last update session with the server, enabling the server to request download of just the changed item. In a further alternative embodiment, the remote computing device may provide to the device management server the configuration data that changed since the last update session with the server.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.
The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations.
As used herein, the term “remote device” refers to any of a variety of programmable computing devices which are configured to receive device management updates from remote servers, and may include personal computers and mobile devices. As used herein, the terms “mobile device” refers to any one or all of cellular telephones, personal data assistants (PDA's), palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, Global Positioning System (GPS) receivers, wireless gaming controllers, and similar personal electronic devices which include a programmable processor and memory and a transceiver for communicating with a wireless communication network.
As used herein, the terms “computer,” “personal computer” and “computing device” refer to any programmable computer system that is known or that will be developed in the future. In a preferred embodiment a computer will be coupled to a network such as described herein. A computer system may be configured with software instructions to perform the processes described herein.
The various embodiments described herein provide methods and systems that enable streamlining the process for performing device management on remote devices from device management servers. The processes, protocols and data structures specified in the OMA DM technical specifications provide great flexibility in enabling a server to remotely manage the configuration of remote devices. However, if the pending device management task depends upon the particular configuration implemented within a remote device, the device management server must command the remote device to transmit its configuration data to the server before the management processes can begin. Such downloading of configuration data can require a significant amount of time for mobile devices. Yet, configuration changes may occur infrequently. Further, changes to configuration data for some applications may have no impact on device management of other applications or the particular update that is to be made. The various embodiments enabled bypassing the step of downloading configuration data when no changes in device configuration data have occurred since the last time the device management server communicated with the remote device.
To determine whether intervening configuration data changes have occurred, devices may maintain data records in memory whenever a device management session occurs with a particular device management server. Such data may be stored in the form of a data table or database within computing device memory. When a computing device engages in a device management session with a device management server, the computing device may record the current configuration update count in a data record associated with the particular device management server. Alternatively, the device may record the time and date of the device management session in a data record corresponding to the server. The next time that the computing device initiates a device management session with the same device management server, the computing device uses the stored data to determine whether a configuration change has occurred since the last session with the server. This may be accomplished by determining whether the current configuration update count is different from the update count stored in the data record associated with the particular device management server. Alternatively, this may be accomplished by determining whether the time and date of the last configuration update is different from the time and date stored in a data record corresponding to the particular device management server (e.g., a data record recording the time and date of the last session with the server).
If the computing device determines that no intervening configuration change has occurred, it provides that information to the device management server (e.g., in the form of an alert command) as part of the session initiation communications. If the device management server receives an alert from the remote device that no intervening changes in device configuration have occurred, the server can recall the device's configuration data from a memory record, which may be in the form of a device configuration database coupled to the server. Obtaining the computing device configuration data from a local database eliminates the need for the server to request the device to transmit its configuration data. This enables the device management server to proceed immediately to the scheduled or appropriate device management task.
In a further embodiment, the device may maintain a record of the URI of objects or items modified in each configuration update. Then, as part of the device management session initiation communications, if the device determines that an intervening configuration change has occurred, the device may send to the device management server an alert listing the URIs of each item affected by intervening configuration changes. The device management server receiving one or more URIs in an Alert embedded within a device management message from a remote computing device may determine whether changes to the configurations of items corresponding to the URIs might be relevant to the device management task to be accomplished. If configuration changes to the items corresponding to the URIs might be relevant to the pending device management task, the device management server may command the remote device to download the configuration data associated with those particular URIs, recalling other device configuration data from a device configuration database. If configuration changes to the items corresponding to the URIs would not be relevant to the pending device management task, the device management server can simply recall the configuration data it needs from a device configuration database, and proceed immediately with the pending device management tasks. Enabling the device management server to obtain device configuration data in this manner can reduce the amount of configuration data that needs to be downloaded.
In a further embodiment, the computing device may maintain a record of the configuration data changed in each configuration update. Then, if the computing device determines that an intervening configuration change has occurred, the device may send to the device management server an Alert containing the configuration data associated with the intervening configuration changes as part of the device management session initiation communications. The device management server receiving configuration data from a remote computing device may update the configuration data record associated with the remote device in a device configuration database, and use the updated configuration data to proceed with the pending device management task. If no configuration data is received from the remote computing device, the device management server may download the device's configuration from the device configuration database, and proceed with the pending device management task.
An example communication system suitable for implementing the various embodiments is illustrated in
Some components of the communication system 100 that enable remote management of mobile devices 102 are illustrated in
Mobile devices 102 may be configured to include a computer platform 220 having a memory 222 in communication with a processor hosting the computer platform 220. Stored within the memory 222 may be a database 224 of device management servers with which the mobile device 102 communicates. The computer platform 220 may also include a number of software process modules used in receiving remote device management, such as a service (SMS) router 226, a push router 228, a device management transport client 230, a device management data processing client 232, a configuration manager 234, and other functional modules or components required to enable updates according to the OMA DM protocol.
While
An overview of the processes involved in the various embodiments is illustrated in
To initiate the device management session, the computing device establishes a communication link with the data management server, step 306, such as by making a data call to a wireless communication network and initiating an HTTPS session with the device management server. The device management server 110 receives the request to establish a data session, and then the device and server cooperate to establish the communication link, steps 306, 308.
If the computing device 102 determines that the configuration has changed since the last update by the device management server 110, that is determination 310=“Yes,” the computing device may proceed according to the OMA DM protocol by transmitting the DevInfo data to the device management server 110, step 312. The DevInfo data includes information about the computing device, such as the device ID, its hardware version, its software version, and other pertinent device-specific information. Once the DevInfo data has been transmitted, the computing device may receive and respond to device management messages from the device management server 110, such as a GET command requesting download of the device configuration data and updates according to the OMA DM protocol, step 316.
If the computing device 102 determines that the configuration data has not changed since the last update by the device management server 110, (i.e., determination 310=“No”), the computing device transmits to the device management server the DevInfo data in conjunction with an alert command indicating that no intervening configuration changes have been made, step 314. Within the OMA DM protocol, the alert command enables the remote computing device to provide information to the device management server. In this embodiment, the alert may provide a simple value or flag since the Alert need only indicate that no intervening configuration changes have been made. Once the computing device has transmitted the DevInfo data and an alert if there have been no intervening configuration changes, the computing device may receive and respond to device management messages from the device management server 110 according to the OMA DM protocol, step 316.
When the device management session is completed, the computing device updates the data record for the particular data management server that will enable the device to determine in future sessions whether there have been intervening configuration changes, step 318.
The device management server 110 receives the DevInfo data from the computing device 102, as well as the Alert if it is included, and determines from this information whether the computing device configuration has changed since the last device management session, determination 320. If the server determines that the configuration of the remote computing device has been changed since the last session with the server (i.e., determination 320=“Yes”), the device management server may obtain the device's latest configuration data by sending a GET command according to the OMA DM protocol, step 322. The computing device will respond to the GET command by transmitting its configuration data in step 316. Using the downloaded configuration data, the device management server 110 may proceed to update the computing device, step 326. Once the device update is complete, the device management server 110 may save the computing device's configuration data in a device configuration database for future reference, step 328.
If the configuration of the computing device has not been changed since the last session with the server (i.e., determination 320=“Yes”), the device management server may obtain the computing device's latest configuration data by accessing a device configuration database within or coupled to the server in order to obtain a data record containing the configuration data of the computing device, step 324. Such a device configuration database may be any form of accessible data storage coupled to the server, such as internal hard disk storage (as illustrated in
Once the device update is complete, the device management server 110 may save the computing device's configuration data in a device configuration database for future reference, step 328. The saved configuration data may include any changes made to the device's configuration as result of the device management session. If the device management session did not result in a change in device configuration data and there have been no intervening configuration changes (i.e., determination 310=“No”), the data in the device configuration database would still be accurate so there would be no need for the device management server 110 to save the device configuration data.
As mentioned above, the device management server may create and maintain the device configuration database by storing the device's configuration data at the completion of each device management session. Thus, downloaded device configuration data (i.e., data received in response to step 322) and changes to configuration data resulting from the device management session may be stored in a data record associated with the remote computing device (such as indexed to the device's identifier). This database stored in (or coupled to) the device management server will reflect the configuration of the computing device until some other process or device management server causes a configuration change.
An example embodiment method 400 that may be implemented within a computing device for determining whether an intervening change has been implemented is illustrated in
Using the identifier for the device management server, the computing device may access a corresponding data record stored in its memory, step 404. The data record corresponding to the device management server may include an update counter value or the time and date of the last device management session performed with the particular server. The computing device may then compare the current update counter value or time/date in the accessed data record to the current update counter value or to a date of a last configuration update, step 405.
As is well known, computing devices may maintain a serial counter of configuration updates, which is referred to herein as the “update counter.” This update counter is incremented as each configuration update is performed on the computing device. The update counter value (or update count) may be stored in memory accessible via the device operating system or application platform. By comparing the update counter value at the time of the last communication session with the device management server to the current update counter value, the computing device can determine whether an intervening configuration change has occurred. Specifically, if the stored update counter value differs from the current update counter value, then there has been an intervening configuration change.
Another way to determine if an intervening configuration change has occurred is to compare the date of the last session with the device management server obtained from a data record in memory to the date of the last configuration change, which may be stored in another memory location. Operating system records may store the date and time of the last configuration change. This information may be obtained via the operating system or application environment and compared to the value stored in memory at the time of the last session with the data management server. If the date of the last session with the device management server is earlier than the date of the last configuration change, then there has been an intervening configuration change of the computing device.
Other mechanisms for determining whether an intervening configuration change has occurred may be implemented. For example, a database of device management server identifiers and configuration change flags may be maintained in memory of the computing device. In this embodiment, whenever a device management server makes a change to configuration data, a flag in the data record associated with that server may be reset (e.g., set to “0”) while flags in data records associated with all other device management servers are set (e.g., set to “1”) indicating that an intervening configuration change has occurred. The computing device can then determine whether an intervening configuration change has occurred simply by checking the flag in the data record associated with the particular device management server.
To initiate the device management session the computing device may initiate an HTTPS connection to the device management server, step 406, as well as send and respond to mutual authentication messages to/from the device management server, step 408.
Before or after establishing the HTTPS connection to the device management server, the computing device determines the type of initial information to send to the server based upon whether an intervening configuration change occurred, determination 410. If an intervening configuration change has occurred (i.e., determination 410=“Yes”), the computing device transmits the DevInfo data per the OMA DM protocol, step 412. On the other hand, if an intervening configuration change has not occurred (i.e., determination 410=“No”), the computing device may transmit the DevInfo data per the OMA DM protocol along with an alert containing an information (e.g., a flag value) indicating that no change has occurred to the device configuration since the last session with the server, step 414.
Thereafter, the computing device responds to the device management server commands to accomplish the update in accordance with the OMA DM protocol, step 416. Once the device management session is ended, the computing device may obtain the current update counter or current time/date, step 418, and stores the obtained value in a data record associated with the device management server, step 420. As mentioned above, the computing device may alternatively store flag values in a data table of device management servers to indicate that an intervening configuration change has been made for all but the currently accessed server. With the device management session complete, the session process 400 may end, step 422.
While the foregoing example embodiment includes the computing device sending an alert when no intervening configuration change has occurred, it should be noted that in an alternative implementation the computing device could send the alert when an intervening configuration change has occurred. Further, the information regarding the status of intervening configuration changes may be transmitted as another command or message other than the alert command used in this example. Thus, the scope of the claims should not be limited to a particular type of message or whether the message is sent to indicate the presence or absence on an intervening configuration change.
An example embodiment method 500 by which a device management server may perform an update on a remote device is illustrated in
Once the session is established, the device management server will receive the DevInfo data from the computing device, step 508. The computing device may parse the received message to determine if it includes an alert (or other message) indicating whether any intervening configuration changes have occurred, determination 510. If the received communication includes an Alert (or other type of message) indicating that no intervening configuration change has occurred (i.e. determination 510=“Yes”), the device management server may access a device configuration database to obtain device configuration data from the data record associated with the computing device, step 512. If there is no Alert or the Alert indicates that an intervening configuration change has occurred (i.e. determination 510=“No”), the device management server may send a GET command (or other command) to the computing device to obtain its configuration data, step 516. The computing device configuration data download is received, step 518, and the received information stored in a data record corresponding to the computing device within the device configuration database, step 520. With the computing device configuration data in hand, the device management server may proceed with the process of updating the computing device according to the OMA DM protocol, step 514. It should be noted that the step of storing device configuration data in the device configuration database, step 520, may be performed after the device management session complete, thereby including any changes to configuration data implemented during the session.
As mentioned above, in further embodiments the computing device may be configured to provide the device management server with more than just an indication of whether an intervening configuration change has occurred. Providing more information regarding the nature of intervening configuration changes, may enable the device management server to determine whether there is a need to download the device configuration data, thereby potentially saving communication time and bandwidth.
In a first alternative embodiment method 600 illustrated in
The computing device transmits the DevInfo data along with the Alert including the obtained URI or URIs to the device management server, step 604. Similar to the embodiment described above with reference to
Once the DevInfo data and Alert have been transmitted (either steps 414 or 604), the computing device may respond to commands from the device management server to accomplish the update according to the OMA DM protocol, step 416. When the device management session has completed, the computing device may store the URI of each object or item for which configuration data was updated during the session in the configuration update data table, step 606. As described below with reference to
If the Alert received from the computing device includes a URI (i.e., determination 702=“Yes”), the device management server may evaluate the URI to determine whether the particular configuration item is relevant to the pending device management task, determination 704. The URI may enable the server to determine that any changes made to the configuration data associated with that URI will not impact the pending update task. In that case (i.e., determination 704=“No”), in which case the server may skip the step of downloading configuration data from the computing device and, instead, obtain the device's configuration data from the device configuration database, step 512. This will enable the device management server to proceed with the device management session in accordance with the OMA DM protocol, step 514. In this manner, if the URI previously updated is not relevant to the pending device management task or the device management server does not interact with the specified URI, the server can avoid expending the time and bandwidth required to download configuration data from the remote computing device.
If the Alert received from the computing device includes a URI (i.e., determination 702=“Yes”), and the device management server determines that an update to the specified URI is relevant to the pending device management task (i.e., determination 704=“Yes”), the server may command the computing device to download the configuration data associated with the specified URI, step 706. This may be accomplished by issuing a GET command specifying the URI as enabled by the OMA DM protocol. The server may then receive the device configuration data for the specified URI (or URIs) from the computing device, step 708. A single GET command may be issued listing multiple URIs when more than one URI is received in the Alert. Alternatively, a series of GET commands may be issued each specifying a single URI when more than one URI is received in the Alert. Using the received configuration data, the server may update the device configuration information in the corresponding data record within the device configuration database, step 710. As part of updating the device configuration data in the device configuration database, the server may also access the other device configuration data stored in the associated data record. With the configuration data for the specified URI received, the device management server may proceed to update the computing device in the device management session in accordance with the OMA DM protocol, step 514.
As mentioned above, the step 710 of updating the device data record in the device configuration database may be accomplished after the device management session is completed so that any additional changes in configuration data implemented during the session can also be included in the database. In this alternative implementation (indicated by the dashed arrows), after (or before) the configuration data associated with the specified URI is received, step 708, the device management server can access the device configuration database to obtain the rest of the computing device configuration data, step 512. Then, using the configuration data received from the computing device and obtained from the device configuration database, the device management server can proceed with the device management session in accordance with the OMA DM protocol, step 514. Once the device management session is completed, the device management server may save the computing device's configuration data in a corresponding data record within the device configuration database, step 710.
Using the embodiment described above with reference to
In a second alternate embodiment, if the computing device determines that an intervening configuration change occurred, the computing device forwards to the device management server the configuration data which was changed since the last session with that server. An example embodiment method 800 by which the computing device can accomplish this process is illustrated in
Once the DevInfo data and Alert have been transmitted (either steps 414 or 804), the computing device may respond to commands from the device management server to accomplish the update according to the OMA DM protocol, step 416. When the device management session has completed, the computing device may store all of the configuration data that was updated during this session in the configuration update data store or database, step 806. As described below with reference to
An example embodiment method 900 that a device management server may implement to conduct a device management session using the configuration data provided by a computing device is illustrated in
As mentioned above, the various embodiments may be implemented using a data store that records information that can enable the computing device to determine when an intervening configuration change has occurred since the last session with a particular server.
Another example server access data table is illustrated in
As mentioned above, the various embodiments may be implemented using a data store or database that records the URI or URIs that are changed each time a change is made to configuration data. An example data structure 1040 for this purpose is illustrated in
An alternative data structure for storing the configuration data changed in an update session is illustrated in
As mentioned above, the various embodiments may be implemented using a device configuration database within or accessible by the device management server that records the configuration data obtained from remote devices in each device management session. An example data structure for such a database is illustrated in
It is worth noting that in the OMA DM protocol, the computing device generates a device management tree of URIs at the time a device management session is initiated. An example of a device management tree is illustrated in
The various embodiments may be implemented by programming servers and computing devices to add the additional processing are described herein. This may be accomplished by revising the OMA DM protocol to permit one or more of the embodiment methods.
Computing devices which may benefit from the various embodiments may include computing devices with access to a network including a remote device maintenance server, such as a mobile device 102 or personal computer 103. Mobile devices 102, such as cellular telephones, may particularly benefit from the various embodiments due to the typically slower data transmission rate of wireless communication networks. Typical mobile devices 102 suitable for use with the various embodiments will have in common the components illustrated in
The embodiments described above may be implemented with any of a variety of server devices, such as the server 1400 illustrated in
The processors 191, 1401 in the various devices may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described herein. In some devices, multiple processors 191, 1401 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 191402 before they are accessed and loaded into the processor 191, 1401. In some mobile devices, the processor 191, 1401 may include internal memory sufficient to store the application software instructions. In some devices, the secure memory may be in a separate memory chip coupled to the processor 191, 1401. In many devices the internal memory 192, 1402 may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to all memory accessible by the processor 191, 1401, including internal memory 192, 1402, removable memory plugged into the device, and memory within the processor 191, 1401 itself
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Similarly, the order in which elements are recited in claims are arbitrary and do not imply that such elements must be performed in the order presented. For example, determining whether an intervening configuration change has occurred since a last communication with a device management server may be accomplished by a computing device before or after initiating a device management session or establishing a communication link to a server. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.
The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module executed which may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. what is claimed is:
This application claims the benefit of priority to U.S. Provisional Patent Application No. 61/223,635 entitled “Systems and Methods for Streamlining Over-The-Air and Over-The-Wire Device Management” filed Jul. 7, 2009, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61223635 | Jul 2009 | US |
