Patent Application
20070093243
Not Applicable
Not Applicable
Electronic devices, such as mobile phones and personal digital assistants (PDA's), often contain firmware and application software that are either provided by the manufacturers of the electronic devices, by telecommunication carriers, or by third parties. If firmware or firmware components are to be changed in electronic devices, it is often very tricky to update the firmware components.
It is often difficult to determine what is wrong with a device when a problem is encountered. Quite often, a customer care representative for an operator does not have answers to a customer's problem and is not able to fix it. Determination of problems with a customer's mobile device is a big problem for operators. Answering customer care calls is quite expensive. Especially so if at the end of such a call, the customer care representative is unable to determine what is wrong with the device.
Different devices have different set of resources, different sets of parameters, etc. Managing mobile devices in a heterogeneous network is a huge problem. Figuring out what parameters need to be set is also a problem.
Customer care centers get numerous calls for support from customers. They have very few means to determine what is wrong with a device. The Customer Care Representative (CCR) often asks questions of a customer, but they do not get proper answers. Customers often do not know what is wrong with their device. Thus, configuration changes that can fix a problem cannot be easily determined. Again, firmware updates that can fix the problem cannot be identified.
Quite often, even when a problem is diagnosed, a solution may not be available. Thus, customers who call to report a problem go away without having solved it. Each call to a customer care center typically takes several minutes and often a customer waits in a “queue” until a CCR becomes free to take his call—the next few minutes are then spent just asking questions and collecting device and customer information, etc. Thus, customer care calls can take over 20 minutes even when a problem cannot be determined or a solution provided.
If an operator needs to handle millions of customer care calls, such as when a firmware bug exists in a new device, it will be very expensive and take a lot of resources to handle the customer care calls.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with the present invention as set forth in the remainder of the present application with reference to the drawings.
A system and/or method supporting management of updating of firmware and parameters in a plurality of mobile electronic devices via a communication network, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.
Aspects of the present invention relate to systems and methods for managing electronic devices in a device management network. More specifically, aspects of the present invention relate to the management of firmware and parameter initialization and update in a plurality of mobile electronic devices via a wireless communication network.
The following discussion describes various embodiments of the present invention as applied to a mobile device which may comprise, for example, a mobile phone, cellular telephone, and personal digital assistant (PDA). The specific mobile device examples provided herein are for purposes of illustration, and do represent specific limitations of the present invention. Embodiments of the present invention may have application in the management of a wide variety of portable/handheld electronic devices having a processor, memory, a display, a means of user input, and communications capabilities via wired or wireless networks.
Although many of the operations described here are illustrated in terms of specific prototype screen shots, a representative embodiment of the present invention may, for example, provide equivalent services through simple object access protocol (SOAP) application program interfaces (APIs).
A representative embodiment of the present invention provides reporting and tools to allow for FOTA administrators to track the ongoing update process and easily diagnose the root causes of any unsuccessful mobile device updates.
The following acronyms and abbreviations may be used herein.
The communication network 100 also comprises a provisioning server 129, that may also be referred to herein as a “broadcast server”, and a device management (DM) server 109 that may support, for example, an Open Mobile Alliance (OMA) device management (DM) protocol, or a proprietary protocol. The communication network 100 also comprises a download server 151 for downloading update packages to the electronic device 107. In a representative embodiment of the present invention, an update package may, among other things, comprise a set of instructions executable by an update agent (not shown) in the electronic device 107 to convert or transform an existing version of software and/or firmware code to an updated version.
As shown in the illustration of
A device management system in accordance with the present invention, such as, for example, the device management system 105 of
If a management operation needs to be invoked by the diagnostics server 151 or the customer care server 157, a web services interface (WSI) is used for that purpose. An associated schedule may be provided along with the management operation. Otherwise, optionally, one may be provided by the DM server 109. If the DM server 109 provides a schedule, then it is communicated to the external system such as the diagnostics server 151 or the customer care server 157. In addition, the schedule provided by the diagnostics server 151 or the customer care server 157 for a management operation (or a management task, or set of tasks, in general) may be modified or an alternative schedule selected or computed by the DM server 109. Such modified or alternative schedule is optionally communicated back to the diagnostics server 151 or the customer care server 157, such as via the WSI.
In one embodiment, if a bulk operation is initiated by an external system with the DM server 109, the DM server 109 returns a set of schedules, one for each target device for the bulk operations. The WSI employed for submitting the bulk operation would facilitate specification of a list of target devices for the bulk operation along with a list of schedules. If a list of schedules is not presented to the DM server 109 along with the bulk operation (and the list of target devices, for example), the DM server can generate or compute schedules for those devices (to conduct the associated operation). The generated or computed schedules are used by the DMS to conduct the operation on the associated target mobile devices. In addition, the generated or computed schedules can be retrieved, if necessary, by the external system from the DM server 109. Again, in a related embodiment, the generated or computed schedules are returned to the external system as a response, when the bulk operation is communicated (along with the list of target devices, and perhaps even with proposed schedules) to the DM server 109 by the external system.
The dashed communication means 169, 153, 145 and 155 represent web services interface (WSI) in one embodiment of the present invention, wherein the DM server 109 provides the WSI. Other means of communication are also contemplated.
The mobile device 107 is capable of receiving update packages. It comprises the update agent(s) 115 that is capable of updating the mobile device 107, a diagnostic client 121 that facilitates remote diagnosis and a traps client 125 that facilitates setting traps and retrieving collected information. The mobile device 107 also comprises a DM client 163 that is capable of interacting with the provisioning client 123, the diagnostic client 121 and the traps client 125. The DM client 163 typically received DM commands from the DM server 109 and implements them. The diagnostics server 151 is used to download firmware and software updates.
The customer care server 157 facilitates access to the information in the device by customer care representatives (CCR). When a CCR needs to diagnose a problem with a device, the CCR can retrieve various configuration values, parameters, etc. from a device 107 one at a time. Instead, in accordance with the present invention, the CCR is also able to retrieve a device profile that provides a large set of information from the device comprising a hardware profile, a software profile, a configuration profile, a memory profile, a subscriber profile, a localization profile, a connectivity profile, etc. In addition, the device is capable of communicating the device profile automatically to the customer care server 157 when a customer/subscriber activates a CallMe button 171 on the device to automatically register for a customer care service.
Automatic registration by the customer for service would make it unnecessary for the customer to dial into a customer care service (often using a special dial-in number) and spend several minutes waiting for a CCR to become free to handle the call. It also automatically provides device and subscriber information to the CCR by means of the device profile communicated to the customer care server 157, thereby making it unnecessary for the CCR to ask several questions and spend several minutes just to determine device particulars and determine a profile of firmware and applications on the device.
Thus, instead of employing several different individual DM sessions (or other sessions) during, or subsequent to, a call to a customer care representative by a customer of the device 107, the present invention makes it possible to retrieve this set of information, the device profile, and make it available to the CCR (ahead of time). In addition, the device profile may be communicated to the customer care server 157 in one single session, for example, in one single package, by the device 107 when the CallMe button (or some other button with the same functionality assigned to it) is invoked. In one embodiment, the device profile is retrieved by the DM client 163 and communicated to the customer care server 157 via the DM server 109. In another embodiment, it is communicated over an SMS means available to the device 107.
When a CCR receives a call from the user of the mobile device 107 for customer care service, the customer care server 157 automatically retrieves the device profile stored in the customer care server 157 and makes it available to the CCR, such as on a display (or PC) used by the CCR. In a related embodiment, if the device profile is not available in the customer care server 157, it is retrieved from a self-care website/portal 169, or from alternative databases.
The WSI interfaces may be used by an external system for invoking management operations with or without an associated schedule. This provides the ability to send schedule information along with the management operation details across the DMWSI interface. The following description makes reference to the elements of
In a representative embodiment of the present invention, an external system may specify management operations with an associated schedule, and a DMS may compute a schedule for a management operation invoked by an external system, if one is not provided by the external system. The DMS may report the computed schedule, and may provide a jobid to the external system for tracking purposes. The DMS may report results for management operations scheduled by an external system.
A representative embodiment of the present invention may employ a user interface comprising a number of screens use to convey and permit entry of information related to the operations of a device management system. Such user interface screens may permit a system user to, for example:
The above list of possible uses is not intended to be exhaustive, and a greater or lesser number, or different user interface screens may be employed without departing from the spirit and scope of the present invention.
The purpose and function of each of the parameters shown in
A representative embodiment of the present invention may maintain a time value, in minutes, that controls how often pending tasks are reviewed for possible activation. An exemplary value may be five minutes, which may guarantee that pending jobs will be reassessed for activation at least every five minutes. A default for this value may be five minutes.
A representative embodiment of the present invention may enforce an absolute maximum on the number of SMSC messages sent over a period of one second for each SMSC to be used. This number may be enforced using an SMSC gateway such as Kannel. However, a representative embodiment of the present invention may enforce an equivalent limit at the “per minute” level (i.e., 20 per second equated to 1200 per minute) if SMSC gateway control is unavailable for a given carrier configuration.
A representative embodiment of the present invention may support the concept of regional SMSCs as shown in
Most carriers are expected to order handsets that have been specifically pre-provisioned for the carrier's network. However, it is often necessary to bootstrap one or more handsets to support smaller customer “trials” and other inevitable exceptions, such as the need to support devices not purchased directly from the carrier. The following prototype screen shows how MVP can support both individual device bootstrap requests as well as bulk bootstrap operations
A representative embodiment of the present invention may support bulk device management operations upon mobile devices. Bulk device management operations may also be referred to herein as bulk campaign management. Bulk update operations may be performed by a firmware over-the-air (FOTA) administrator of “FOTA Administrator”. Such bulk operations, each supported by one or more user interface screens, are detailed in later sections of this application.
A representative embodiment of the present invention may support the bootstrapping of mobile devices that have either not been pre-provisioned or have been previously provisioned for another Open Mobile Alliance (OMA) device management (DM) server.
Many carriers order handsets that have been specifically pre-provisioned for the carrier's network. However, it is often necessary to bootstrap one or more handsets to support smaller customer “trials” and other inevitable exceptions, such as the need to support mobile devices not purchased directly from the carrier. The exemplary user interface screen of
In a representative embodiment of the present invention, bootstrap operations may be directed to a specific make and model, so that the device management server is able to determine what type of bootstrap message to send. The type and content of the bootstrap message may be configurable as device capability parameters. Plain profile bootstrap may be supported, with the understanding that the wireless application protocol (WAP)/CP “w7” profile may also be employed.
A representative embodiment of the present invention may provide a “one shot” bootstrap interface that bootstraps a single device on an exception basis, given the manufacturer, model, MSISDN, IMEI, and IMSI. Although shown in
In a representative embodiment of the present invention, bulk bootstrap suppot may be provided for a specified manufacturer and model through an external comma separated value (CSV) file imported from a bulk bootstrap UI. The contents of the CSV file may be MSISDN, IMEI, and IMSI, in that order. Exported and imported CSV files may contain MSISDN as the first field and IMEI (if known) in the second field. This convention is may allow a CSV file to be used for multiple purposes as discussed later in this Application.
Bootstrap operations may take 12-14 separate SMS messages to deliver a bootstrap message to a mobile device/handset. In a representative embodiment of the present invention, the number of SMS messages employed to bootstrap a specific device type may be maintained as a mobile device capability, so that the bulk service may adjust the overall SMS message rate for the higher SMSC load required for bootstrap operations.
A representative embodiment of the present invention may maintain knowledge of whether or not a specific device type is expected to start an OMA DM session as the result of a successful bootstrap operation. For devices that do start an OMA DM session, the effect of a successful bootstrap may produce the same results as if a query operation was issued (i.e., a device management server has now recorded the MMV information in its database). Should a mobile device type be unable to generate an OMA DM session, the carrier may use the same CSV file as input to a subsequent bulk query operation.
Once a search is complete, a summary of the mobile devices selected and the proposed version upgrades may be presented. Clicking on the version detail links may reveal a list of the actual mobile devices and MSISDNs selected by the search criteria. The list of mobile devices may be exported to a CSV file for later use or external processing. Importing a saved device list may re-populate the above screen from previously saved results.
In a representative embodiment of the present invention, a device management server may be pre-provisioned with a list of IMEI/MSISDN pairs for the mobile devices to be supported. However, when the IMEI associated with an MSISDN is unknown, the MSISDN may be used to find the mobile device on the network. Once the mobile device is contacted, a representative embodiment of the present invention may record both the IMEI and the firmware version with the MSISDN, allowing more precise queries to be issued in subsequent operations.
To the extent that a representative embodiment of the present invention has previously communicated with the mobile devices in question, version information will be up-to-date (i.e., as long as no out-of-band updates have been performed). When the mobile device version is unknown, the version may be shown as “unknown”. In any case, the true firmware version of the mobile device may be discovered during the FOTA discovery process, at which time the device management server may capture the correct version information, even if no update is needed. Note that the screen of
In a representative embodiment of the present invention, when the initial screen for selecting the devices for a bulk operation is displayed, as shown in
User interface screens such as, for example, those shown in
In a representative embodiment of the present invention, a user who chooses to use the search capability may specify any combination of IMEI, MSISDN, Manufacturer, Model, and version to form a Boolean AND expression. Partial values for IMEI (e.g., the first six digits that contain the TAC field) and MSISDN (e.g., country and/or area code) may be specified. If the search is successful, and the IMEIs are known, a summary of what mobile devices may be updated and to which firmware versions may be displayed, as shown in the examples of
In a representative embodiment of the present invention, once a collection of mobile devices is established, the list of mobile devices may be exported, in a CSV file with the following fields:
The term “assumed” is used because version information may not be known until the device responds to the update notification and reveals its current MMV information. Nonetheless, it may be expected the a device management server in a representative embodiment of the present invention will have the correct version information almost all of the time, since out-of-band updates should be very rare.
In normal long term use, a representative embodiment of the present invention may be expected to have up-to-date mobile device data (IMEI, and MMV) in its database. When this is the case, clicking on the target version link may bring up the device detail display for that subset of the mobile device collection, as shown in the example of
In a representative embodiment of the present invention, some columns may be eliminated when the context of the detailed display (
In a representative embodiment of the present invention, the IMEI of the mobile device that responds to the update notification may or may not match the IMEI specified. This ambiguity may be controlled by the user during submission.
The mobile device detail navigation controls of a representative embodiment of the present invention provide the means for moving forward, backward, to the beginning, the end, or to a specific page of a mobile device list. This allows the user to check first, last, and a few intermediate pages to be assured that the search produced the expected results.
This detailed display of selected devices and projected version updates may be employed when 1) the search is done directly from the device management server database, and 2) the device management server database has the necessary IMEI data. When a mobile device collection is built from an external CSV file, or when no IMEI data is available to the device management server, the mobile device detail display may be omitted.
In a representative embodiment of the present invention, rate plans may control the rate, in “tasks activated per second”, at which tasks from a bulk job may enter the active state. Specific details and requirements on rate plans are discussed below. In the user interface screen shown in
The user interface screen shown in
In a representative embodiment of the present invention, if an MSISDN selected in this job is also included in another active bulk job, the MSISDN may be excluded from the job being submitted automatically, leaving a message to this effect in the log information for this MSISDN. The first update may achieve exactly the same result as the subsequent update, so there is little to be gained by burdening the user with some form of conflict resolution.
In a representative embodiment of the present invention, the start date and time shall may specify when the job may be started. No tasks from this job may be started before this time. The actual start time may subject to system load, other pending jobs, priority, rate plan, and the global “refresh cycle time”. Thus, once the start time arrives, the job may be allowed to compete for resources, but may not be guaranteed to actually start at that time, subject to other bulk operation parameters and controls.
The user of a representative embodiment of the present invention may be offered a choice of rate plans in the form of a drop down list of predefined rate plans associated with the user's user group (e.g., region). All rate plans may be specific to a user group, such that the only rate plans available to a user are those specific to the user group. The chosen rate plan may govern how quickly tasks from this job can be placed into the active state.
In a representative embodiment of the present invention, the priority value may span from 1 (i.e., highest) to 10 (i.e., lowest). Priority may be treated as “absolute”, meaning that all higher priority work may be serviced before any lower priority work is serviced. In a representative embodiment of the present invention, rate plans offer the flexibility to control how fast a job progresses. Priority may be used in situations where a job or a set of jobs are to be service before all others, or are to be treated as a background activity when no other jobs are active. Priority may be treated as “absolute”, to avoid conflict with rate plans. Thus, when operating at a specific priority level, only the rate plans of the jobs within that priority level may be considered for activation. In a representative embodiment of the present invention, priority may be used to handle exceptions, but rate plans may be the primary vehicle for controlling bulk job workflow.
In another representative embodiment of the present invention, priority may be replaced by an “emergency” flag to handle the one case that rate plans may not optimally handle, namely the forcing of a bulk job to the “head of the queue” at the complete exclusion of all non emergency jobs.
In a representative embodiment of the present invention, a bulk server may provide a drop down set of options to allow the user to control the handling of a different device responding to the notification of an MSISDN than the IMEI expected. The following options may be supported:
If the IMEI test fails, the task may be reported as failed, using a result code in a “vendor specified” range (i.e., “500-599”), as specified in the Open Mobile Alliance (OMA) Device Management (DM) Firmware Over-The-Air (FOTA) standard.
In a representative embodiment of the present invention, each job may be identified by a user specified job name, as illustrated in the example of
The retry expiration time in a representative embodiment of the present invention may specify the number of hours to allow a task from this job to remain active and not completed, before the task is deemed to have failed. This may range for example, between 48 to 72 hours. Note that this value may also be used to set the expiration time for the initial SMS notification message. If an update is not achieved before the retry expiration time is reached, the notification message may expire, and the device management server may assume that the update attempt has failed.
Once the mobile device calls in, a representative embodiment of the present invention may grant additional time for the update to complete, as long as the update session appears to be progressing. User input may not be required beyond the initial retry expiration time. A representative embodiment of the present invention may permit some degree of tuning of this value.
The “retries allowed” setting of
The “pause between retries” entry in
A representative embodiment of the present invention may support the definition of various “rate plans” that control task activation rate for a specific bulk job. A rate plan may be used to control the rate at which bulk update tasks are allowed to enter the active state for each hour of the day, with specific hourly rates specified for days of the week, weekends, and special days. Rates may be specified in terms of tasks activated per second so that the impact on the targeted SMSC can be clearly understood. However, actual enforcement may be performed less often than once per second (e.g., 3 per second equates to 180 per minute).
A representative embodiment of the present invention may schedule bulk jobs by start date and time. The start time may employ a 24 hour clock having a range of between 00:00 to 23:00 hours. Such a representative embodiment may support selection of a SMSC rate plan to manage SMSC rate throttling on a per hour and/or per day basis. A user may be permitted to set priority for critical vs. non-critical updates, and set retry parameters for non-successful tasks. A retry expiration time may be specified as the number of hours allowed for a task to remain active. In some representative embodiments of the present invention, the parameters specified by a user may refer to a particular task, and not to a job.
In a representative embodiment of the present invention, each rate plan may be given a user-friendly name at the time of creation, to allow easy access to different rate plans. Rate plans may be associated with a set of exception dates, discussed in greater detail below.
The times in the table of
Special days and holidays may be handled as exceptions to the weekly rate plan shown in
In a representative embodiment of the present invention, each exception table may also be given a unique name, to allow it to be selected into a rate plan by its name. Each rate plan may refer to only one set of exception dates. Note that exception dates may be updated at least yearly, while the base rate plans may be completely date independent.
A representative embodiment of the present invention may provide an easy to use web UI for creating named rate tables and named special day (i.e., “exception”) tables. Since there may be a great deal of repetitive data in these tables, the use of “data entry assists” may be helpful. One such assist may support a mode where adding a number to a blank cell causes all blank cells to the right to be filled automatically with identical values. Another aid might be to add a control that duplicates the contents of an entire day into the value of the next unfilled day.
It should be noted that the rate and exception tables illustrated in
In a representative embodiment of the present invention, each rate plan may be associated with a named special day plan (i.e., “exception list”). Special day plans may be shared across multiple rate plans and as such may be maintained separately.
A rate plan may be bound to a specific user group (e.g., as might be associated with a country or region). This may serve to bind the rate plan for use with any specific SMSC and SMSC message rate associated with that group or region.
The times in the rate plan may be displayed in the user's time zone or a specific time zone set by the user. Internally, all times may be maintained in UTC (formally known as Greenwich Mean Time (GMT)). This allows the device management server to use UTC time for all time calculations, regardless of what time zone is used to establish the rate plan.
Rate plans are set in terms of activations per second to make it easier for carriers to understand activation rates in the same terms as they view SMSC message rates. Whenever the MVP needs to activate additional tasks, the activation rates shall govern how many tasks for which jobs shall be activated.
By way of example, consider three jobs, A, B, and C, each with a large numbers of tasks waiting to be activated. For the current hour, the job rate tables may specify the following activation rates:
A representative embodiment of the present invention may apportion the work by activating three tasks for job A, five from job B, eight from job C, and so on until the maximum number of active tasks is reached. The tasks may also be activated in larger groups, as long as the activation ratio established by the respective rate plans is maintained for each activation cycle.
In a representative embodiment of the present invention, if the aggregate activation rate across all jobs exceeds the overall rate specified for the SMSC to be used, the individual job rates may be “downsized” to fit the available SMSC bulk job rate in proportion to the rates specified for each job. This aspect of a representative embodiment of the present invention prevents an ill-conceived set of rate plans from exceeding the specified maximum SMSC capacity for bulk jobs.
In a representative embodiment of the present invention, the aggregate rate of an active set of bulk jobs may not exceed the total rate across these jobs. For example, in the above 3-5-8 example, the listed jobs, collectively, may not exceed the aggregated rate of 16 activations per second, even if there “appears” to be unused SMSC capacity. Such unused capacity needs to remain available for subscriber revenue producing work. Rate plans may be designed to “back off” during peak periods as shown in the rate table examples of
A representative embodiment of the present invention may support the reporting of status information on current and previously completed bulk jobs, with the ability to view specific job and task status, and the canceling of a specific job or task.
A representative embodiment of the present invention may provide a summary report for all bulk jobs started within a specified date range. This report may allow the user to navigate to the first, last, next, previous, or a specific page of the report. The specific data shown may include the following:
Clicking on a column heading may sort the report based upon the contents of that column.
In a representative embodiment of the present invention, if a particular graphical element is clicked within the job summary report, the user may be prompted with the following options concerning the associated job:
If the user chooses to abort the job, all tasks that have not yet been activated may be aborted. If a CSV file is requested, a “Save As” dialog box may appear and the MSISDN and IMEI (if available) associated with each cancelled task may be written to the specified CSV file.
In a representative embodiment of the present invention, if a job “pause” button is clicked, no further tasks may be activated from this job until the job is either cancelled or “un-paused”. Note that the pause icon may change to an “un-pause” icon (something like ) to indicate a paused job and provide a means to resume the job. In a representative embodiment of the present invention, clicking on the view icon may bring up a job detail screen, such that shown in
The job detail report may display the summary status of each task within the job, including:
The job detail report may allow the user to navigate to the first, last, next, previous, or a specific page of the report. Also, the user may be able to display subset report data based on any of the following search report criteria, forming an AND expression:
Clicking on a column heading may sort the job detail report based upon the contents of that column. The user may also be able export the data currently displayed to a CSV file.
Clicking on an “Export” button may copy the currently display data to a CSV file for possible off line processing.
The job detail report may also provide a “Cancel Job” button, which may behave exactly the same as described above.
Clicking on the magnifying glass for a specific device may bring up the device detail screen shown in
If a magnifying glass icon is clicked within the job detail report, the task detail report may be displayed as shown in the example of
A representative embodiment of the present invention may provide details of a single DM operation task, and may provide detailed visibility into all events for a single device with date/time stamps. Such detailed information may be useful for debugging failed tasks.
In a representative embodiment of the present invention, if there is a mobile device that is already in an active job or is already scheduled, the device management system may automatically exclude the mobile device from a job. In some representative embodiments of the present invention, a device management server may not give a warning message about conflicts, and Import functionality may not provide MMV information before task execution. This may be due to system performance constraints on a particular platform, and may not affect other support platforms. In some representative embodiments of the present invention, bulk query and bulk update may be identical in both workflow and in user interface screens. In other representative embodiments of the present invention, bulk query and bulk update workflow and in user interface screens may be different. The job type entry on list views may indicate whether bulk update or bulk query is being performed.
A representative embodiment of the present invention may support bulk job management, and may include the following exemplary features:
A representative embodiment of the present invention may also support job recovery management, and may include the following features:
In a representative embodiment of the present invention, a “task” may represent an update to a single mobile device. Each task may be queued and processed separately, and tasks may be activated and tracked by MSISDN and an internal “Task ID”. A “Job” may contain one or more tasks, and a job and its tasks may be tracked by a Job ID, user ID, and job name. A bulk job may be a set of tasks identified by a list of MSISDN's. Each task may be identified by its parent job ID.
In a representative embodiment of the present invention, tasks in a bulk job may progress by time and rate. Tasks may be held in a “bulk job queue” until activated, and tasks may be moved to an “active task queue” to activate processing. Activation may be controlled by job specific dates/times and activation rates. The size of the active queue may limit the number of active tasks, and the order of tasks in the active queue may represent priority order and “rate”. No size limit may be placed on inactive tasks.
In a representative embodiment of the present invention, management of the active queue may involve management of a number of system parameters and functions. For example, in a representative embodiment of the present invention, the number of active tasks may be limited to control overall system load. Only active tasks may be allowed to compete for system and network resources. Queue size, schedule, priority, and rate may control task activation. There may be no limit on the number of jobs or number of inactive tasks in the system.
In a representative embodiment of the present invention, a number of different task activation criteria may be employed in determining when a task is activated. For example, active queue size (i.e., the number of tasks that can be active at one time), job priority (e.g., tasks of a higher priority job may be activated before those of lower priority), job specified date and time schedules (e.g., one or more date/time sets), and the activation rate (i.e., the number of activations per second). A limit may also be placed on overall SMS notification rate.
A representative embodiment of the present invention may support task recovery. Notification may be sent with the job specific expiration time. Once an OMA DM job is established, the time to live may be the same as the expiration time. If a delivery receipt is received but no session results, it may be assumed that a “cancel” was performed. If no session is created within the expiration time, a representative embodiment of the present invention may retry up to a retry count. If session fails, a representative embodiment of the present invention may retry the task, unless the retry count has been exceeded.
The following discussion provides additional details about the principal functions and objects employed in a representative embodiment of the present invention.
A representative embodiment of the present invention may comprise client and Server components that work together to initialize and update mobile devices over-the-air. This concept has practical application for carriers that need advanced over-the-air (OTA) device management (DM) capability, including, for example,
A number of terms may be used to describe activities, elements and functions of a representative embodiment of the present invention. The following definitions may aid in the understanding of the subsequent discussion.
As used herein, the term “bundle” may be defined as a collection of device initialization, upgrade, and application provisioning “steps” to be executed in sequence across the protocols needed to achieve the required device updates. Such steps may include firmware upgrade, “Flex” data update, data application settings, and any number of data and application packages to be downloaded to the device (wallpaper, screen savers, Java Applications, etc.).
As used herein, the term “bundle manager” may be defined as a device management system component that transforms a set of subscriber attributes and data values into a bundle of operation steps to be performed on a specific device known to have a specific set of device capabilities.
As used herein, the term “device detection” may be defined as the process by which MVP detects the presence of a new device and subscriber combination on a carrier's network. Two methods of detection are covered here, 1) one in which a device management client detects a new subscriber identity module (SIM) card in the mobile device, and 2) one in which a proactive SIM applet notifies a device management server of its detection of a new device.
As used herein, the term “device identification” may be defined as the process by which a device management system identifies the make, model, and version information of a device in order to understand what firmware resides on the device and the resulting device capabilities of the device. (Note that device capabilities may depend on the firmware installed, not just the device make and model.)
As used herein, the term “device instance” may represent a single device identified on the mobile network by its “device ID” (e.g., IMEI or ESN). Under normal circumstances, each device instance is associated with a specific subscriber MSISDN or MIN, except for “borrowed” or “stolen” devices discovered on a GSM mobile network.
As used herein, the term “device capability” may describe the capabilities of a specific class of device as identified by its make, model, and firmware version (MMV). Note that capabilities such as “supports Java MIDP 2.0”, or “supports Email” may be dependent on firmware version.
As used herein, the term “firmware version” may describe a single or multiple values. In this document, the term “firmware version” is frequently referred to as if it were a single value. More commonly, it is necessary to consider other values as well, such as “software version” and “flex version”.
As used herein, the term “job” may be defined as a collection of “job steps” to be performed on one or more mobile devices, which has been scheduled as a single request. Once the capabilities of a device are known, the broker in a device management system may create a “bundle” of job steps to execute the job in a manner appropriate to the current device capabilities.
As used herein, the term “job ID” may be used to represent a unique ID that represents a job in process, to allow results and status to be correlated to the initial broker request.
As used herein, the term “OMA DM server” may be used to represent a device management system component capable of retrieving, setting, and modifying OMA DM management tree objects and supporting the emerging OMA DM firmware upgrade standard.
As used herein, the term “OMA download server” may be used to represent as a device management server or system that implements V1.0 of the Open Mobile Alliance (OMA) Download protocol.
As used herein, the term “OMA client provisioning protocol” may be used to represent the protocol used to define various mobile device settings and application characteristics. In a representative embodiment of the present invention, an OMA Client Provisioning document is delivered to the mobile device using an OMA Download or OMA DM protocol.
As used herein, the term “management server” may be used to represent an abstract component, used by a broker component in a representative embodiment of the present invention for device identification as well as for the initiation and management of firmware upgrade and content download services. All device management client/server “management” operations may be handled by the management server. The role of “management server” is normally provided by an OMA DM server, using an OMA Device Management protocol, except in cases where OMA DM is not supported on a mobile device/handset.
As used herein, the abbreviation “MMV” refers to a combination of values that define a device Make, Model, and (firmware) Version. Note that firmware “version” may also be represented by a number of values as defined above.
As used herein, the term “DM server” may be used to represent a server component that provides “Management Server” services as needed to manage device management client devices that do not support the OMA DM protocol. This component allows MVP to fully support devices that have yet to support the OMA DM protocol.
As used herein, the term “OMA DM server” may be used to represent a server component that provides Management Server” services for device management client devices that do support the OMA DM protocol. A representative embodiment of the present invention may also support the emerging OMA DM firmware upgrade standard. When present, OMA DM protocol may be used for retrieving, setting, and modifying device-specific OMA DM management tree objects for the purpose of provisioning data application parameters. (Note that this latter capability may be limited due to a lack of standard OMA DM “provisioning” objects.)
As used herein, the term “OMA download server” may be used to represent a device management system component that implements V1.0 of the OMA Download protocol. One example of such a device is the mProve PRISM component made by Bitfone Corporation.
As used herein, the term “OMA client provisioning protocol” may be used to represent the protocol used to define various mobile device and application characteristic settings. In a representative embodiment of the present invention, an OMA Client Provisioning document may be delivered to the mobile device using OMA Download. In a representative embodiment of the present invention, a device management server may take over the responsibility for provisioning the mobile device according to the contents of the provisioning document.
As used herein, the term “subscriber instance” may be used to define a single subscriber to the device management system for the purpose of managing subscriber specific provisioning information and establishing communication with a subscriber's device using SMS notifications and WAP Push. (Note that in GSM, the specific mobile device may or may not be known at the time a provisioning or upgrade request is issued.)
As used herein, the term “subscriber class” may be used to define a set of subscriber attributes, common to a set of subscribers. A subscriber class may be used to define provisioning attributes associated with geographic region and a class of subscriber service (e.g., consumer, corporate, pre-paid, basic, premier, elite, etc.). Subscriber class data may be “seen” as subscriber data, but may be maintained and managed separately in a subscriber class device management object to avoid duplication of common information.
A representative embodiment of the present invention comprises a client, a server, and a set of interfaces that may initiate all provisioning and management actions. Such actions may be initiated either from a mobile device, from a web user interface (UI), or from an application program. In a representative embodiment of the present invention, the action may ultimately be serviced via a SOAP API call to a device management server, through which actions are initiated and controlled. External actions that initiate device management system services may include the following:
Using a web UI or, in some cases, a carrier-specific UI, a customer care or point of sale representative in accordance with a representative embodiment of the present invention may enter a subscriber into the carrier's system, resulting in the creation of a subscriber instance record in a device management system. Note that the subscriber's device ID may or may not be known at that time. They may also initiate provisioning of the subscriber's mobile device. Assuming the mobile device is OMA firmware upgrade enabled and/or is equipped with a device management client, the device ID may be known once the device responds to the update operation.
In a representative embodiment of the present invention, a customer at a carrier “self care” web page may be provided with much of the same basic provisioning capability as a customer care representative, but with a carrier portal “look and feel”. Thus, a representative embodiment of the present invention may support the same capabilities via its web services, SOAP API.
In a representative embodiment of the present invention, a subscriber may contact a self care web service from the mobile device, using either the device menu or a browser. Such a service may offer the same basic provisioning capabilities, again through the use of a SOAP API provided by a representative embodiment of the present invention.
In a representative embodiment of the present invention, a “device administrator” may initiate or schedule provisioning for a collection of mobile devices, selected by, for example, device ID, make and model, firmware version, subscriber phone number components, or a combination of selection criteria. Progress of such a request may be tracked via SOAP API “status callbacks” for each affected mobile device, or via a status reporting web UI to display the state of all outstanding and completed requests.
In a representative embodiment of the present invention, a “device administrator” may enter new or updated device capabilities or subscriber class information to a device management server. For example, a firmware upgrade may enable Java capability for a given make and model, or a new multimedia messaging service (MMS) server that is now available for subscribers to the “corporate” plan.
In a representative embodiment of the present invention, a “system administrator” may change device management server operational parameters such as, for example, “workflow control” parameters used to control the times and rate at which “bulk provisioning” operations are released for execution.
In a representative embodiment of the present invention, a “system administrator” may issue requests to create reports for billing, auditing, performance, or diagnostic purposes.
In a representative embodiment of the present invention, a new device/subscriber combination may be detected on the carrier's network. Such automatic device detection allows the carrier to automate device setup using device management services, and also provides the carrier with invaluable information about device usage. New device detection may be accomplished using one of the following means:
Actions such as the above may be triggered by the device management client, a SIM card, a device management system-provided web UI, a carrier-provided web UI, or a carrier's operations or business support software. Regardless of the source, in a representative embodiment of the present invention, all device management operations may ultimately be serviced via one or more calls to a device management server's SOAP API.
In reference to
A representative embodiment of the present invention may provide a customer care (or point of sale) web user interface (UI). A device management system in accordance with the present invention may provide this web UI to be able to demonstrate a complete set of device management capabilities. In an actual carrier deployment, the services of this web UI may be integrated with the carrier's customer care and point-of-sale (POS) systems. Thus, the components of this UI may be developed to be reused and adapted as part of a carrier-specific integration effort. The UI may be as simple as possible to use, and provide a model for carrier-specific integration efforts.
A representative embodiment of the present invention may provide administrative web UI's to support the following types of services:
A representative embodiment of the present invention may provide handset initiated services. A subscriber may initiate device management services directly from a mobile device/handset via the handset's browser or via a handset menu item. Such subscriber initiated provisioning services may be supported by a device management server in accordance with a representative embodiment of the present invention, and may be augmented by the carrier. These services provide much of the same function as available to customer care or via a self care web page. A representative embodiment of the present invention may provides basic web services for servicing mobile device initiated requests which also serve as a model for carrier provided services to be integrated within the carrier's business logic.
A representative embodiment of the present invention may support new device detection. As described above, new device detection may be accomplished either through a mobile device management client's detection of a new SIM (“device detects SIM”), or through a device detection enabled, proactive SIM (“SIM detects device”).
The “device detects SIM” case may be preferred, as in this case the device management client may provide the complete MMV and device client information needed for a device management system in accordance with the present invention to provision the device without decoding the IMEI and “poking” the device in an attempt to get this information from the device client. To support device management client-based detection, the device management client may involve OEM interfaces to 1) get the carrier supplied data from the SIM card, and 2) to be able to direct the OEM to use the supplied data connection setting for contacting the device management server. The device management effort may validate quickly the extent to which OEM's are willing to support these capabilities.
The “SIM detects device” case may provide an alternative method for device detection, and may be used if the OEM interfaces and services employed by the device management client to implement “device detects SIM” are unavailable. A device management system in accordance with a representative embodiment of the present invention may implement both techniques to gain sufficient device coverage to support automatic device detection and setup.
A representative embodiment of the present invention may support a set of core device management services behind the device management SOAP API. The following is an example of the core elements of a representative embodiment of the present invention:
A representative embodiment of the present invention may support device identification and validation. Whenever a previously unidentified mobile device is discovered, a call may be made via a SOAP API to an device management system or carrier provided service to decide what action should be taken. The following are examples of possible situations and device management actions:
In the absence of a carrier provided policy service, a device management system in accordance with a representative embodiment of the present invention may default to the following assumptions:
If the mobile device is already assigned to the current subscriber, the device may be provisioned according to the subscriber's attributes if this has not already been done.
A representative embodiment of the present invention may support persistent objects. A device management system in accordance with a representative embodiment of the present invention may provide the following persistent objects, each of which have the capability to enumerate, retrieve, search for, add, delete, and modify a specific type of object:
A representative embodiment of the present invention may support a subscriber instance object. The subscriber instance object may defines a single subscriber to a device management system for the purpose of managing subscriber specific information and establishing communication with a subscriber mobile device using SMS notifications and WAP Push. The properties of this object may include, for example:
In a representative embodiment of the present invention, the subscriber instance object may provide “getters and setters” for all simple properties. In a representative embodiment of the present invention, methods may be provided for, “add”, “find”, “enumerate” and “delete”, as well as for the following public (e.g., pseudo) methods for managing subscriber-specified name/value pairs:
A representative embodiment of the present invention may support a subscriber class object. The subscriber class object may define a set of subscriber attributes which are common to a set of subscribers. A subscriber class may be used to define provisioning attributes associated with a geographic region and a class of service for a given class of customer (e.g., consumer, corporate, pre-paid, basic, premier, elite, etc.). Subscriber class data may be seen as subscriber data, but may be maintained and managed separately in a subscriber class object. The properties of this object may include, for example:
The Subscriber Class object in a representative embodiment of the present invention may provide “getters and setters” for all simple properties. A representative embodiment of the present invention may provide methods for, “add”, “find”, “enumerate” and “delete”, as well as the following public (i.e., pseudo) methods for managing client provisioning and authorized download data:
A representative embodiment of the present invention may support a device instance object. The device instance object may represent a single mobile device identified on the mobile network by its “DevId” (e.g., IMEI or ESN). Under normal circumstances, each device instance may be associated with a specific subscriber MSISDN, IMSI, MDN, or MIN, (except for “quarantined” mobile devices that may be discovered on a GSM mobile network). The device instance object may manage and maintain the following properties:
Note that a subscriber may end up using several mobile devices over a period of time. A representative embodiment of the present invention may make no provision for “cleaning out” unused mobile devices, other than providing the date/time information mentioned above.
The device instance object of a representative embodiment of the present invention may provide “getters and setters” for all simple properties. A representative embodiment of the present invention may provide methods for, “add”, “find”, “enumerate” and “delete”.
A representative embodiment of the present invention may support a device capability object. The device capability object in a representative embodiment of the present invention may describe the capabilities of a specific class of device as identified by its make, model, and firmware version. Capabilities such as “supports Java MIDP 2.0”, or “supports Email” may be dependent on firmware version, which may be a combination of “version” information such as firmware version, software version, and “flex” version. The device capability object may manage and maintain the following properties for each unique combination of device make, model, and version:
The Device Capability in a representative embodiment of the present invention object may provide “getters and setters” for all simple properties. Methods may be provided for “add”, “find”, “enumerate” and “delete”, as well as the following public (i.e., pseudo) methods for managing client provisioning and authorized download data:
A representative embodiment of the present invention may support a firmware definition object. A firmware definition object may be used to manage the data that maps source and target firmware package to specific device capabilities. The purpose of this object is to add a general capability to cover the following cases:
The firmware definition object may be employed as a “front end” to the functionality provided by an existing device management tool, such as the PRISM tool from Bitfone Corporation. The firmware definition object may be used to “front end” a download server. In a representative embodiment of the present invention, the firmware definition object may be defined to manage the following properties:
Note that the firmware definition object may allow separate firmware packages to be found for a specific combinations of source, target, and base firmware IDs.
The Firmware Definition object of a representative embodiment of the present invention may provide “getters and setters” for all simple properties. Methods may be provided for “add”, “find”, “enumerate” and “delete”, as well as the following public (i.e., pseudo) methods for looking up firmware packages:
Note that the above methods may be replaced by a general “find” method, but is documented above to show examples of the lookup parameters that may be used.
A representative embodiment of the present invention may support a download object. An additional download object (not shown in
The download object of a representative embodiment of the present invention may provide “getters and setters” for all simple properties. Methods may be provided for “add”, “find”, “enumerate” and “delete”, as well as the following public (i.e., pseudo) methods for looking up firmware packages:
Note that the above method may be replaced by a general “find” method, but is documented above to show examples of the lookup parameters that may be used.
As described above with respect to
A representative embodiment of the present invention may comprise a deployment manager. The deployment manager of a representative embodiment of the present invention may provide services for making provisioning requests to be performed by device management system. Such requests may ultimately be resolved to one of more specific subscriber ID's, which may be specified directly, or via a multipart query expression (e.g., all subscribers associated with devices with a specific make, model, and version, AND subscribed to the “Corporate” subscriber class).
Two forms of request may be provided, a simple form, designed to be used from a customer care or self-care UI or web service, and another to perform more complex requests, or bulk requests involving a set of subscribers, most likely derived via some multipart query expression.
A representative embodiment of the present invention may support simple subscriber provisioning. In the single subscriber provisioning case, the provisioning request may take the following general form:
If a mobile device corresponding to the makeModel parameter is known not to support the device management client, the device management request may be aborted immediately, without sending useless SMS messages trying to communicate with the mobile device. If the makeModel parameter does indicate support for device management according to a representative embodiment of the present invention, or if the make and model is not specified, a representative embodiment of the present invention may attempt to contact an device management client in the mobile device to discover its identify and MMV information. Owners of self-care web pages may wish to specify make and model to try to avoid unnecessary SMS traffic and possible misunderstanding, concerning the level of device management support for the mobile device.
A representative embodiment of the present invention may also support extended subscriber provisioning. In the single subscriber provisioning case, the provisioning request may take the following general form:
In a representative embodiment of the present invention, the deployment manager may pass the job ID and the list of subscribers directly to the deployment scheduler, which handles all scheduling, workflow control, dispatching, bookkeeping, and status reporting tasks.
A representative embodiment of the present invention may support status reporting. Once a simple or extended provisioning request job is passed on to the deployment scheduler, the deployment scheduler may handle all status reporting callbacks. However, the deployment manager in a representative embodiment of the present invention may also provide an interface by which the current status of a job may be retrieved from the transaction log. The following request may be used to return an array of status objects, one for each operation in the original request:
statusArray getStatus (jobID);
where each object in status array contains a subscriber ID, phone, device ID (if known) and the current status of the job (e.g., scheduled, dispatched, in progress, in retry, completed, etc.). For jobs completed in error, an additional, error code and error code dependent message may also be included to pass back any details that may be needed to take corrective action.
A representative embodiment of the present invention may comprise a deployment scheduler. The deployment scheduler of a representative embodiment of the present invention may do all the “heavy lifting” for the deployment manager, which may act mainly as the external interface for initiating provisioning requests. The interface to the deployment scheduler may be identical to the extended and status reporting interfaces of the deployment manager, with the single exception that any query expression may resolve into a list of subscribers as follows:
The main job of the deployment scheduler in a representative embodiment of the present invention is to handle request scheduling, workflow management, operation dispatching, and status reporting. The deployment scheduler runs off a timer as well as when called from the deployment manager. Once a request is placed in the request queue, the deployment scheduler may monitor the request schedules and the current workload to determine when to dispatch more operations from the request queue to the in process queue.
The general flow of work from the deployment scheduler's point of view may be summarized as follows:
Whether or not any operations have been dispatched, the deployment scheduler may invoke the deployment broker, to give it a chance to forward its outstanding workload.
A representative embodiment of the present invention may comprise a deployment broker. The deployment broker may be responsible for managing all steps in the provisioning process. The broker's workload may be predetermined by the deployment scheduler through the action of moving requested operations from the request queue to the in-process queue. The broker looks at the in-process queue for new operations to be processed and to maintain state for operations already in progress. The deployment broker may be given an opportunity to run every time the scheduler runs, but may also use its own timer should it need to run more often.
Provisioning operations in a representative embodiment of the present invention may progress through a series of “steps” along the following lines:
As each deployment broker step proceeds, the deployment broker may maintain the current state of the entire operation within the in-process queue, so that if the process is interrupted, the process can be restarted at the step that failed.
Deployment broker operation relies heavily on the ability to receive the “step completion post” from the device management client and the ability to ask the device management client to perform another subsequent operation as part of the deployment broker's response. The deployment broker also may employ a DM-service provided “session in waiting” feature, that allows the deployment broker to ask the device management client to start a DM session, using the out-of-band post request response feature, to avoid initiatign all DM sessions with a separate SMS notification message. Note that this feature may also be used to cause the device management client to initiate a DM session in response to a device management client invocation of a web page or web service that uses a DM session to complete the request.
A representative embodiment of the present invention may comprise a bundle manager. The bundle manager in a representative embodiment of the present invention may create provisioning bundles dynamically, given a subscriber instance object, a device capability object, and a list of job steps requested by the job Options object. The subscriber instance may provide access to subscriber-specific data values, as well as access to all common download information and provisioning data contained in the subscriber class object associated with the subscriber. The device capability object may define the provisionable capabilities of the device, and specific download versions that the device is able to support.
If the firmware upgrade job option is set, the bundle manager may invoke the firmware object to find the firmware for the MMV in the device capability object, consistent with the various job options (selected source firmware, target firmware, skip firmware upgrade, etc.). If firmware upgrade has been selected and there is an appropriate firmware upgrade for the specified parameters and options, the bundle manager may set up the firmware upgrade as the first step in the bundle.
The bundle manager may then append additional steps to the bundle according to the target mobile device capabilities, subscriber settings, and job options. If the bundle contains “placeholder” values, the bundle manager may substitute the necessary subscriber specific values for all “placeholders” (e.g., replacing “#POP_USERID#” with “bdaley”). The resulting bundle may then be passed back to the deployment broker in a form that allows easy access to each individual step in the bundle.
A representative embodiment of the present invention may comprise a management server. The management server in a representative embodiment of the present invention may have two implementations, a management service for managing mobile devices/handsets that cannot support the device management client using OMA DM, and a management service that supports OMA DM. In the first case, the DM service may send a unique SMS message to the mobile device/handset that tells the device management client to contact the device management server and provide MMV information. Through a specific HTTP/HTTPS interchange of messages, the device management server in a representative embodiment of the present invention may communicate the same information to the device management client as would have been communicated had the device management client been able to use the OMA DM protocol.
In the second case, the device management client is compatible with the OMA DM protocol. The device management service may support the specific features employed by a representative embodiment of the present invention, most specifically those employed by the deployment broker. The interface to the DM service may support interfaces equivalent to the following functionality:
A representative embodiment of the present invention may comprise a download server. The download server in a representative embodiment of the present invention may be any OMA Download compliant download server able to support adequate security for firmware and application download operations. A representative embodiment of the present invention may be able to support more than one download server, perhaps as many as two or three, including the use of components for firmware management and download such as the mProve and PRISM components from Bitfone Corporation.
A representative embodiment of the present invention may comprise a report manager. A representative embodiment of the present invention may provide for two types of reports, both of which may be based on fielded data maintained across server nodes in a shared database. One type of report may be based on the device management system transaction log, which logs each provisioning transaction. The “transaction log” may be used for status reporting on pending, in-process, and completed transactions. These transactions may provide specific date, time, subscriber, device, operation performed, requesting user, completion statue, and any related transaction information that may be needed for billing, auditing, summary error tracking, and performance monitoring.
Another type of reporting is a more detailed “event” log that is roughly analogous to the UNIX syslog and supports various “levels” of logging, commonly referred to as ALERT, ERROR, WARNING, and DEBUG. In a representative embodiment of the present invention, logging levels may be changed to gather more or less event information, depending on the need for such information. The most intense level of logging, DEBUG, may rarely be used in a production environment, except for short periods of time to diagnose serious system problems. Certain levels of logging, e.g. ALERT, ERROR, and WARNING messages may also trigger an simple network management protocol (SNMP) trap to alert a carrier's network management system.
To support integrated reporting via the report manager, a representative embodiment of the present invention may maintain an event log as a database shared across all MVP server nodes. Like the transaction log, the data may be fielded to allow data selection and reporting based on date time, operation type, logging type, initiating user, or even specific device(s) or subscriber(s) when such information is known at the time the message is logged.
The report manager may provide interfaces that define and generate reports from either the device management system transaction log or the device management system event log. Data to be reported may be specified using a query expression to select the data to be reported, and an ordered list of fields to be captured. Report specification as well as query expressions may be saved, retrieved, used, copied, and modified to produce both repeatable and flexible reports
Reports may be generated on demand in CSV format, suitable for export to an external system for billing and or analysis, or displayed by a separate report viewing web UI.
A representative embodiment of the present invention may comprise a configuration manager. The configuration manager in a representative embodiment of the present invention may provide a central source for setting and retrieving variable system parameters. Configuration data may be maintained as a set of name/value pairs, both within the device management system database and in memory. Most requests to retrieve configuration data may be serviced from memory, with the data updated from the common configuration database “periodically” (e.g., every five minutes). Retrieving configuration values may be deliberately optimized at the expense of a minor delay before all nodes respond to a configuration change. Note that the update period may also be changed.
Many configuration parameters may be defined for use in a device management system in accordance with a representative embodiment of the present invention. Below are identified only a few of those configuration parameters that are employed by features described above. It should be noted that a greater or lesser number of configuration parameters, or different configuration parameters may be employed, without departing fromt eh spirit and scope of the present invention. An exemplary set of configuration parameters may include:
A representative embodiment of the present invention may comprise query manager. Several of the device management system components discussed above make reference to a “query” expression to select the items to include in some request. Rather than burden each of the previous component discussions with query considerations, the concept of a query manager component is introduced here. A query manager in accordance with a representative embodiment of the present invention may accept query expressions such as, for example:
Whenever a field name is not unique across objects (e.g., in tables) it may be prefixed by its object name (e.g. DeviceInstance.SubscriberID). Queries may be used to select a set of objects (records) based on:
Queries may be saved and retrieved for later use or re-use, and may be saved in the database in a predefined format. Methods may be provided for creating, modifying, and retrieving queries by name. A representative embodiment of the present invention may employ a proprietary easy-to-learn syntax, 2) use a simplified subset of SQL or 3) employ a combination of the two to address both flexibility and ease of use considerations.
A device management system in accordance with a representative embodiment of the present invention may comprise a device management client. A device management client in accordance with a representative embodiment of the present invention may comprise a significant extension over other device management clients. The device management client software of the present invention comprises a client agent, which interfaces to the device management server via a specific enhanced implementation of the OMA DM protocol. The client agent serves as the client side “agent” of the device management server, and may support SIM detection and “multi-step” job step management in close collaboration with the deployment broker described above. The major functional components of the device management client are as follows:
A key component of the device management client is the client agent, which is designed to interface device management-enabled handsets to a device management server in accordance with a representative embodiment of the present invention. The client agent discussed in this section employs the OMA DM protocol for initiating firmware upgrade, server to device user communication, and OMA DM data application service provisioning. A non-OMA DM-compatible version of the client agent is discussed below. The primary difference in function is the ability to set application parameters into the OMA DM tree when using the manufacturer's OMA DM implementation. The principal services of the client agent are:
During the execution of a multi-step job, the client agent may maintain communication with the deployment broker of the device management system by initiating a DM session and/or posting status reports to the device management server. The response from each such status post may be 1) to start an OMA DM session with a specified URL, 2) to begin an OMA download from a specified URL, 3) to end the current job.
When using an OEM implementation of OMA DM client services, the client agent of a representative embodiment of the present invention may have the responsibility of interfacing to OEM DM services, so that other system components can remain unaware of the OMA DM client services implementation.
A device management client in accordance with a representative embodiment of the present invention may comprise an OMA DM client service. The OMA DM client service may be provided with the device management client, or as part of the OEM mobile device/handset. The device management system-provided version of the OMA DM Client Service may be designed to be optimized to reflect its principal goal of supporting communication between the device management client and the device management server, not necessarily to be 100% OMA DM compliant. OMA DM compliance may be achieved, but OMA DM compliance is not a specific limitation of the present invention. A representative embodiment of the present invention may or may not be OMA DM compliant. A goal is to address the needs to support a sequence of OMA DM firmware upgrade, OMA data service provisioning, and initiating OMA Download operations.
The OMA DM features and commands involved in supporting firmware download include, for example:
In a representative embodiment of the present invention, an OMA DM client may or may not maintain actual DDF information on the device, and a device management server may or may not provide DDF information for new tree nodes. Additional tree elements may be added to the manufacturer's initial management tree without any DDF information as long as the manufacturer's DDF and access control lists (ACLs) of the original tree are not violated (e.g., by attempting to delete an OEM permanent node).
When an OMA DM compliant device management client is used, the DM client may be responsible for interfacing with OEM services for communicating OMA DM application data settings to the mobile device/handset by whatever means the OEM provides. When an OEM's version of the DM client is used, the OEM's DM client may have this responsibility, as it may control the OEM's management tree and its relationship with internal device settings.
A download agent in accordance with a representative embodiment of the present invention may interface with the client agent for both firmware and application downloads, and report status via the client agent. The client agent may assume responsibility for whatever handset “installation” might be required, based on a MIME type of a downloaded item.
A discovery agent in accordance with a representative embodiment of the present invention may be able to interface with the client agent, to gather MMV information for SIM detection and preparation for a firmware upgrade. In some representative embodiments of the present invention, the discovery agent may be a part of the client agent.
A handoff agent in accordance with a representative embodiment of the present invention may interface with the client agent. In some representative embodiments of the present invention, the handoff agent may be a part of the client agent.
An update agent in accordance with a representative embodiment of the present invention may interface with the client agent. In some representative embodiments of the present invention, the update agent may be a part of the client
A provisioning agent in accordance with a representative embodiment of the present invention may interface with the client agent. In some representative embodiments of the present invention, the provisioning agent may be a part of the client agent. In some representative embodiments of the present invention, the OMA DM protocol may prove to be unsuitable for general provisioning of data application settings, either due to insufficient support for OMA DM in the mobile device, or a lack of standardization of the application provisioning objects. Therefore, a representative embodiment of the present invention may implement its own settings provisioning service based on standardized OMA client provisioning “application characteristics”. Rather than using SMS push, OMA CP provisioning documents may be delivered to the device management client via OMA download, which the client agent may “install” through the use of the provisioning agent.
Once a client provisioning “package” has been delivered, the provisioning agent may be invoked to process the provisioning package and to update the appropriate data service and application settings in the mobile device. To update these settings, the provisioning agent may make use of device-specific “wrapper” functions, provided by the manufacturer of the mobile device, to access the appropriate values within the memory of the mobile device.
In a representative embodiment of the present invention, a complete set of provisioning parameters may be sent from the device management system service, but the provisioning agent may allow partial updates of mobile device settings. For example, the mobile device may have already been data provisioned and may already have enough information for browsing, bookmarks, and MMS. However, the email settings may be missing needed user ID and password values, so email may not yet be operational. The subscriber may visit the carrier's web site to update this information, which may trigger a new device management system request to (re-)provision the subscriber's mobile device. Since only the email settings have changed, only the application characteristics need to be sent to the client.
A representative embodiment of the present invention may read device parameters from the mobile device and send them to a device management server. In this manner, the device management server may be updated with setting changes made directly on the mobile device, 1) to update its data to avoid overwriting local changes, and 2) to be able to “back up” user settings, so that they can be reloaded on the same or different (new) device.
A representative embodiment of the present invention may also support a non-OMA DM compliant device management client. For some handset deployments, a version of the device management client may operate without the services of an OMA DM client implementation. The device management server may make requests for MMV information and may initiate downloads and firmware upgrades using custom SMS messages to the client agent. The SMS messages may contain the same server credentials as would be used in an OMA DM implementation, and the client agent's HTTP response may contain equivalent client credentials. Once communication is established, the client agent and device management server communication may be managed via HTTP request/response cycles, with the same overall method used for communicating step completion and getting the “next command” from the server.
Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
The present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.
The present application makes reference to, claims priority to, and claims benefit of U.S. Provisional Patent Application Ser. No. 60/730,286 entitled “DEVICE MANAGEMENT NETWORK” (Attorney Docket No. 101USMD101), filed Oct. 25, 2005, the complete subject matter of which is hereby incorporated herein by reference, in its entirety. The present application makes reference to PCT Application with publication number WO/02/41147 A1, PCT number PCT/US01/44034, filed Nov. 19, 2001, and to U.S. Provisional Patent Application Ser. No. 60/249,606, filed Nov. 17, 2000, the complete subject matter of each of which is hereby incorporated herein by reference, in its entirety. The present application also makes reference to U.S. Provisional Patent Application Ser. No. 60/664,249, entitled “DEVICE CLIENT SPECIFICATION” (Attorney Docket No. 101USMD117), filed on Mar. 21, 2005, to U.S. patent application Ser. No. 11/385,162, entitled “MOBILE DEVICE CLIENT” (Attorney Docket No. 16639US02), filed Mar. 21, 2006, to U.S. Provisional Patent Application Ser. No. 60/652,457, entitled “NETWORK FOR CUSTOMER CARE AND DISTRIBUTION OF FIRMWARE AND SOFTWARE UPDATES” (Attorney Docket No. 101USMD111), filed Feb. 11, 2004, to U.S. patent application Ser. No. 11/352,702, entitled “NETWORK FOR CUSTOMER CARE AND DISTRIBUTION OF FIRMWARE AND SOFTWARE UPDATES” (Attorney Docket No. 16554US02), filed Feb. 13, 2006, the complete subject matter of each of which is hereby incorporated herein by reference, in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60730286 | Oct 2005 | US |
