Patent Application
20070207800
[Not Applicable]
[Not Applicable]
Electronic devices such as, for example, 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 such electronic devices, it is often very tricky to update the firmware or firmware components.
It is often difficult to determine what is wrong with an electronic device when a problem is encountered. Quite often, a customer care representative for a system 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 system 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 electronic device.
Different electronic devices have different sets of resources, different sets of parameters, etc. Managing mobile devices in a heterogeneous communication network is a huge problem: Figuring out what parameters need to be set is also a problem.
Debugging software problems that occur in mobile devices, “in the field”, is a challenging endeavor. A user or a software developer cannot step through code using a debugger. He/she must rely on debug information recorded in the memory of the mobile device during field use of the device, in order to diagnose problems with any software in the device. This information may consist of trace information, logs of data taken from a radio subsystem, stack dumps, error flags, or anything the developer has stored in specific memory reserved for debugging purposes. Currently, after trace data is recorded, the information is manually transferred from memory of the mobile device into a personal computer (PC) via a wired interface such as a universal serial bus (USB) cable, and the developer examines the debug data file on the PC. This process suffers from a number of drawbacks, however. First, the user or software developer and the problematic device may not be co-located, so obtaining the debug file is nontrivial. Second, the users of the device (typically field or beta testers) may be inconsistent about retrieving debug files from the memory of the mobile device in a timely manner and debug information may be overwritten after a period of time, so the user or software developer may never receive the needed debug information. Existing diagnostic clients work on proprietary protocols, and often on a cable/wire-based solution. These approaches are not adequate for diagnosing widely reported problems with millions of deployed mobile devices.
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 device, method and system supporting control of diagnosis and tracing in a plurality of mobile electronic devices, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.
These and other advantages and novel features of the present invention, as well as details of an illustrated embodiment thereof will be more fully understood from the following description and drawings.
Aspects of the present invention relate generally to the management of mobile devices. More specifically, aspects of the present invention relate to the use of managed objects for diagnostics and monitoring of mobile/handheld electronic devices such as, for example, a mobile handset, a cellular phone, a personal digital assistant, a pager, a personal computer, or any of a number of other portable or handheld electronic devices with communication functionality. Although much of the following discussion relates to a mobile handset or mobile device such as a cellular phone, the teachings of the present invention also apply to any of a wide variety of electronic devices with wired or wireless communication functionality that provide subscriber access to communication services such as, for example, those named above, and other electronic devices having similar characteristics.
A mobile network in accordance with the present invention such as, for example, the mobile network 105 shown in the illustration of
As shown in
In a representative embodiment of the present invention, the electronic device 107 may, for example, comprise a non-volatile memory 111, and a random access memory (read/write memory) RAM 165. The non-volatile memory 111 may, for example, comprise flash-type memory, and may contain application software 127, a DM client 163, a traps client 125, a provisioning client 123, a diagnostic client 121, a diagnostic agent 171, an operating system (OS) 119, firmware 117, update agent(s) 115, and a boot loader 113. In a representative embodiment of the present invention, a DM client such as the DM client 163 may received DM commands from a DM server such as the DM server 109, and may interact with a provisioning client such as the provisioning client 123 to implement the received DM commands. The DM commands may be, for example, those in accordance with an Open Mobile Alliance (OMA) Device Management (DM) Version 1.2 or later protocol, as developed under the sponsorship of the Open Mobile Alliance, Ltd.
A representative embodiment of the present invention may comprise a traps client such as the traps client 125, which may facilitate setting traps and retrieving collected information. Diagnostics firmware such as, for example, the diagnostic client 121 may act to facilitate remote diagnosis of the electronic device 107. Update agent firmware such as the update agent(s) 115 may enable the updating of firmware, software and configuration information in the electronic device 107, and may be employed to update, for example, application software 127, operating system (OS) 119, or firmware 117 in the electronic device 107. The update agent(s) 115 may employ an update package delivered by, for example, the download server 151, which is used to download firmware and software updates to mobile devices in the mobile network 105. The electronic device 107 in a representative embodiment of the present invention is capable of applying the received updates using one or more update agents 115 that are each capable of processing update packages or subsets thereof.
A mobile device in accordance with the present invention may also receive provisioning information from, for example, a customer care server such as the customer care server 157, or a provisioning server (not shown). A provisioning client such as, for example, the provisioning client 123 may process the received provisioning information to correct configuration problems or to reconfigure software and hardware of the electronic device 107. Device capability information stored in non-volatile memory 111 of the electronic device 107 may be modified as necessary when this occurs.
The electronic device 107, which may comprise a mobile device such as those described above, may be used by a customer to request customer care service via a customer care server 157. Device capability information retrieved from the electronic device 107 may be a part of the parameters provided to the customer care server 157. A customer service representative (CSR) may provide a service to the customer using the electronic device 107, after determining the device capability information retrieved from the electronic device 107. In this manner, a representative embodiment of the present invention may make it unnecessary for a customer to provide such information him/herself to a CSR. The mobile network 105 may support remote diagnostics by a CSR via a customer care server such as the customer care server 157. An electronic device (e.g., the electronic device 107) of the mobile network 105 of
A representative embodiment of the present invention makes it possible to obtain debugging and other diagnostic information from mobile devices (e.g., electronic device 107) in an operator network such as a cellular or paging network, for example. An exemplary Log management object (MO) is illustrated in
In a representative embodiment of the present invention, a log file may be employed to collect information on various device features for which tracing or debugging is enabled (i.e., turned on). Such a log file may also be used to selectively collect information on specific events that are monitored, device specific data being collected, and network performance data, for example. Representative embodiments of the present invention make it possible to obtain debug and other diagnostic information from mobile devices such as the electronic device 107 of
In a representative embodiment of the present invention, a diagnostic client such as the diagnostic client 121 of
Representative embodiments of the present invention employ a device management (DM) approach for mobile diagnostics, wherein management objects (MOs) are created and used for diagnosing each feature domain or application. Each of the diagnostics-related management objects may comprise parameters to be monitored, configuration data to be set, and tracing information to be collected, to name only a few examples contemplated. Each application installed in an electronic device such as the electronic device 107 of
System operators/service providers associated with the mobile network 105 may enable/disable device tracing of applications in an electronic device such as the electronic device 107, as the need arises. For example, even if an electronic device such as the electronic device 107 supports debugging of application settings and application resource usage, the operator of the wireless network providing service(s) may disable (e.g., either temporarily or permanently) some of the tracing features, or configure them as enabled when they are needed.
In various representative embodiments of the present invention, the collected trace information may be retrieved from the electronic device as a log file, or as trap information sent by a trap set on specific electronic devices. When a log file is employed, the collected information may be retrieved as, for example, an extensible markup language (XML) file, a binary file uploaded from the electronic device, as a structured file (e.g., formatted per a well defined format and structure based on standards or proprietary as defined by the manufacturer of the electronic device or the diagnostic client 121 or diagnostic agent 171), or as device-specific formatted content.
In the example illustrated in
A method in accordance with a representative embodiment of the present invention may support the following:
In a representative embodiment of the present invention, all parameters settable on an electronic device (e.g., the electronic device 107 of
In some representative embodiments of the present invention, uploading of the log file results in the automatic deletion of the log file in the electronic device 107. In other representative embodiments, the log file is not deleted, even after it has been transferred to a server such as, for example, the device management server 109, diagnostic server 129 or the customer care server 157 of
There are a number of ways in accordance with a representative embodiment of the present invention that diagnostics data may be generated on an electronic device such as the electronic device 107 of
In a representative embodiment of the present invention, debug messages or trace messages included in the software and/or firmware of an electronic device like the electronic device 107 of
In a representative embodiment of the present invention, diagnosis of several different user agents or applications may be supported by an electronic device such as the electronic device 107 of
In one embodiment, the Log file MO 307 may enable collection of categories of diagnostic data that are each associated with a security mechanism and a format for layout. The security mechanism and the format information may also be provided in the Log file MO 307 such that a consumer of the Log file MO 307 may use them to retrieve and process the diagnostic data.
The Log file MO 307 may be digitally signed for security, and a signature 315 may be included in the Log file MO 307. The Log file MO 307 may be transferred to a diagnostic server over a ftp (file transfer protocol) connection, an htpp (hypertext transfer protocol) connection, a short range wireless network connection such as that referred to by the name Bluetooth, or any of a variety of other communication paths. In one representative embodiment of the present invention, the Log file MO 307 may be communicated by a DM client 163 in the electronic device 107 over an http connection by means of an http “POST” mechanism. In another representative embodiment of the present invention, the Log file MO 307 may be communicated by the DM client 163 in the electronic device 107 by means of an ftp mechanism. In yet another embodiment, it is communicated over the large object download mechanism of the OMA DM protocol supported by the DM client 163.
A representative embodiment of the present invention may support settable device tracing parameters on an electronic device such as the electronic device 107 of
In a representative embodiment of the present invention, a user interface for a server such as, for example, the customer care server 157 of
In a representative embodiment of the present invention, a client-side application such as the diagnostic agent 171 or diagnostic client 121 of the electronic device 107 of
In a representative embodiment of the present invention, does not interfere with normal operation of the electronic device being monitored or diagnosed, even under heavy loading conditions. In a representative embodiment of the present invention, the client-side firmware and/or software may support a client-side call into a trace functions every 10 ms, and each call may transfer a 1 kilobyte of data.
Table 1, below, lists the acronyms and abbreviations used in this document:
Table 2, below, lists exemplary terminology and definitions used in this document:
In a representative embodiment of the present invention, a diagnostic server such as the diagnostic server 129, may be incorporated into servers of an existing device management platform, or may be implemented as one or more servers dedicated to the monitoring and diagnostic functions described herein.
In a representative embodiment of the present invention, a trace client such as the diagnostic client 121 and diagnostic agent 171 may support device initiated logging and uploading of logged information to a trace server such as the diagnostic server 129, as well as to a USB attached PC, and/or a removable handset SD card. The following discussion illustrates some of the functionality of a trace client in accordance with the present invention such as, for example, the diagnostic client 121 and diagnostic agent 171.
A representative embodiment of the present invention may provide a native shared library service that may be called from other applications, other shared libraries, and also during interrupt time, to record errors, warnings, and other events of interest in an electronic device.
In a representative embodiment of the present invention, each log entry may be recorded with a component ID, a sub-component ID, and a severity level of an event. The ability to include optional binary data (e.g., a stack trace) and/or a text message may be provided.
In a representative embodiment of the present invention, message logging may be controlled by a filter that specifies one or more component and sub-component pairs, and associated severity levels of the messages to be logged. If the component and sub-component IDs are not matched within the filter, or if the severity level of a matched filter entry is lower (e.g., less severe) than the message to be logged, the message may be discarded and the logging process may return to its caller.
In a representative embodiment of the present invention, caller thread operations may be written to a dedicated RAM buffer by native processor code such as, for example, code for an ARM processor from ARM, Ltd. Movement of log messages to other, slower storage targets may be performed by lower priority threads.
In a representative embodiment of the present invention, the main RAM log buffer may be implemented as a “circular buffer”, in which the oldest log messages may be discarded if processes for moving data to other storage targets fall behind.
In a representative embodiment of the present invention, an option to configure a larger internal flash “backup” buffer may be provided. This internal flash buffer may be supported by a background thread that regularly moves log data from RAM to internal flash to free RAM log space. Such a thread may run at a priority lower than the priority of any caller of the logging service, but higher than the thread that moves log data from internal device memory to an external target.
In a representative embodiment of the present invention, information moved to internal flash may be maintained as a set of flash files. Flash file size may be limited to 64 KB in length for flash performance reasons. Log messages may not be split across flash files. If the amount of internal flash memory may be exceeded, the oldest flash file may be overwritten to ensure that the newest log information is preserved.
In a representative embodiment of the present invention, a “real time” logging mode may be provided in which log messages are written directly to a USB attached PC. When real time mode is active, log information may not be logged to internal memory, except possibly for buffering purposes. Once the log message is successfully received by the PC, it may no longer be retained in internal memory in an electronic device such as, for example, the electronic device 107, for example.
In a representative embodiment of the present invention, the use of a “special” key sequence may invoke a dialog box/screen for setting log mode, “trigger” criteria, buffer sizes, external upload target(s), and filter criteria, for example. The user interface for this dialog box/screen may be modeled after other log configuration dialog boxes/screens with appropriate additions and changes. A representative embodiment of the present invention may permit entry of component and sub-component IDs that were not known at the time the operating system of an electronic device was built, when the descriptive name may not be known.
In a representative embodiment of the present invention, a trace server such as, for example, client-side software/firmware such as the diagnostic client 121 and/or diagnostic agent 171 of an electronic device may receive and process a complete set of configuration information from a trace server such as the diagnostic server 129, to configure remotely any parameters that are configurable locally on the electronic device.
In a representative embodiment of the present invention, a logging service may expose a shared library interface for changing and reconfiguring log filters, settings, and trigger criteria, for example. This logging service may be used both by a device logging configuration dialog while handling server configuration request messages, and also by local device-side diagnostics or testing software.
In a representative embodiment of the present invention, the following “triggers” may be supported for initiating log data uploading to one or more configured external targets, described above:
In a representative embodiment of the present invention, a logging service may expose an interface for retrieval of log messages from an internal log buffer of an electronic device. This interface may be used, for example, for device-side acceptance testing, to check that the messages that should be in the log are there, with no “unwanted” information.
In a representative embodiment of the present invention, a diagnostic client such as the diagnostic client 121 and/or diagnostic agent 171 may provide the ability to remotely configure OTA connectivity settings over SMS, using methods of a customer care system such as, for example, the SmartCare or FusionDM system available from Bitfone Corporation.
In a representative embodiment of the present invention, a logging “transfer” service may provide a means of moving internal log data (e.g., stored RAM or flash) to one or more of the following external targets, in the following priority order:
When multiple targets are configured, “blocks” of log data may be written to each target in priority order. If all three external targets are configured, “blocks” of log data may, for example, be written in the following order:
In a representative embodiment of the present invention, successful transfer of a block of log data to any external target may release (e.g., erase) the internal storage for that log data.
In a representative embodiment of the present invention, transfer of log data to an external target (e.g., a diagnostic/trace server, a USB interface to a PC, or an SD card) may run at a lower priority than a thread that moves data from RAM to internal flash (e.g., when internal flash is configured). This helps to assure that storage for RAM log data continues to be available for new log messages.
In a representative embodiment of the present invention, each log message transfer may have a header that includes information such as, for example:
In a representative embodiment of the present invention, a logging service (e.g., in the diagnostic agent 171 and/or diagnostic client 121) may provide a means of clearing all internal log buffers, either from a configuration dialog of an electronic device like the electronic device 107, or via an SMS request by a trace/diagnostic server such as the diagnostic server 129, for example.
In a representative embodiment of the present invention, a trace/diagnostic server functionality may comprise a new service built upon an existing customer care system such as the SmartCare/FusionDM server architecture of Bitfone Corporation, or a separate standalone server architecture, to support the management of, and data collection from, diagnostic/trace-enabled devices. The following diagnostic/trace server functionally may be provided in a representative embodiment of the present invention:
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may be able to trigger a log data transfer on an electronic device such as the electronic device 107 of
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may be able to clear all log data on the electronic device (e.g., electronic device 107) by sending an SMS notification to the device.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may be able to collect available trace settings and log filter settings from the electronic device using OTA methods.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may be able to configure available trace settings and log filter settings on the electronic device using OTA methods. Trace settings may include, for example, those settings described above.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may be able to collect basic device information and data connection (IP) settings from the electronic device using OTA methods.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may be able to configure data connection settings on the electronic device using OTA methods. If the data connection is incorrectly configured and TCP/IP is not available, the diagnostic/trace server may fix the GPRS data connection setting using SMS.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may permit a user to historically search through diagnostic/trace data. Search criteria may be a combination of zero or more of the following: component, sub-component, severity, device time when diagnostic/trace data is logged, and server time when log data is received, to name only a few examples.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may allow for deletion of trace data.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may allow for the export of trace data to a CSV (comma separated value) file.
A representative embodiment of the present invention may comprise a “Log Message Receiver”, hereinafter referred to simply as the “Logger”. The Logger may be a shared library in native processor code for the electronic device and, except for interrupts, may run in the thread of a caller. The Logger may be supported by a lower priority background thread that maybe responsible for moving log messages from RAM into internal flash memory to free up RAM log space, if space for an internal flash log has been configured. The Logger may operate in one of the following modes:
A representative embodiment of the present invention may comprise a “Log Transfer Module”, hereinafter referred to simply as the “Uploader”. The Uploader may include associated SD card manager, USB PC communication, and server communication modules. The Uploader may be responsible for moving log messages from internal log memory to one or more external recipients. The Uploader may comprise a shared library in native processor code (e.g., for an ARM-based processor) and may run at a priority lower than the thread that moves messages from RAM to internal flash memory. In some representative embodiments of the present invention, when internal flash is configured in the electronic device (e.g., electronic device 107 of
A representative embodiment of the present invention may comprise a device agent such as the diagnostic agent 171 and/or diagnostic client 121 of
A representative embodiment of the present invention may comprise a “Data Manager”, hereinafter referred to simply as the “Configuration Agent”. The Configuration Agent may be responsible for processing both client-initiated and server-initiated configuration requests. Such a Configuration Agent may be a separate component, or an extension to an existing device agent such as, for example, a device agent used as part of the SmartCare or FusionDM products from Bitfone Corporation, for example. The Configuration Agent may run as an application, and may present a UI as necessary.
Each of these client-side components of a representative embodiment of the present invention is described in greater detail in the following sections.
The Logger (i.e., the Log Message Receiver) in a representative embodiment of the present invention is the central logging interface for message logging for operating system (OS) components and applications. The Logger may be called by any OS or application component, and may also be called under the following special conditions:
The Logger in a representative embodiment of the present invention may be capable of sustaining a peak rate of 10 KB of log data every 10 milliseconds. In some representative embodiment of the present invention, and some operating conditions, the Logger (i.e., the Log Message Receiver) may be a high duty cycle component. A C++ language function prototype for a logging call in accordance with a representative embodiment of the present invention, may look as follows:
A representative embodiment of the present invention, several shorter versions of the above call may be provided for situations where there is no binary data, and/or no text data. A variant that provides formatting may also be provided. Formatting for messages that do not “pass” the log filter may not be done, to avoid unnecessary overhead.
The Logger of a representative embodiment of the present invention may check the following parameters upon receiving a logging request, to determine whether or not the message should be logged. This determination may be based on a set of parameters that match both the message severity and the component and sub-component pair specified by the caller. Thus, all of the following criteria may be matched before a message is logged:
It should be noted that in some representative embodiments of the present invention, the severity level “FAULT” may always be logged, regardless of other criteria, as this level may only be used for the most serious of errors (e.g., where an imminent crash of an electronic device (e.g., the electronic device 107 of
To check whether a message should be logged, the component and subcomponent IDs may be combined as shown in the following exemplary structure, to enable look-up in a sorted list:
In some electronic devices, 64-bit integers may not be supported (e.g., on electronic devices such as those manufactured by Palm). In this instance, the following structure may be used to represent these values. In the case of component and subcomponent ID pairs, the component ID may be the “high” word, and the subcomponent ID may be the “low” word.
In a representative embodiment of the present invention, a single bsearch may be used to look-up the 64-bit combined component and subcomponent ID pair. If the ID pair is not found in a pre-specified list of IDs, the Logger may immediately return to the caller. If the search is successful, the value of bySeverity in the matching entry may be used to determine whether the message is to be logged. If the severity level specified by the caller is less than or equal to bySeverity, the message may be logged, otherwise the Logger may immediately return to the caller.
In a representative embodiment of the present invention, any message that passes the filter test may be used to trigger an upload of all log messages held in “internal” log storage. If the value of bySeverity has the low order bit set, the logging of this message may notify the Uploader thread to move all internal log data to an appropriate receiver external to the electronic device (e.g., the electronic device 107 of
In a representative embodiment of the present invention, filter criteria and other logging parameters (e.g., log buffer sizes) may be set by a user of a handset or electronic device (e.g., the electronic device 107 of
In a representative embodiment of the present invention, component-independent event codes may be used to capture discreet events such as low/high signal or roaming transitions, for example. Event codes may be implemented using an artificial component ID ‘EVNT’, and assigning event-specific codes as subcomponent IDs. This allows a Logger call to specify the system-wide unique “event” being reported, regardless of the component actually reporting the event. An event code may be assigned to the ‘EVNT’ component for “call drop” and another for “Call Origination Failure”, for example, occurring anywhere within the handset or electronic device.
In a representative embodiment of the present invention, when real-time logging mode is enabled (i.e., turned on), logging messages may be sent directly to a USB-attached PC, and may not written to internal log memory. If the USB connection to the PC is lost, or becomes unresponsive, log messages may again be written to internal log message memory, to avoid log message data loss. If the PC connection later becomes available, real-time logging to the PC may resume, but messages written to internal memory may not automatically be sent to the PC.
In order to enable operation at the highest level of performance, the Logger of a representative embodiment of the present invention may write new log messages sequentially into a dedicated, pre-allocated circular RAM buffer in the electronic device (e.g., in RAM 165 of electronic device 107 of
In some representative embodiments of the present invention, a 64-bit time value may be stored as two 32-bit numbers, and may represent a device-specific, high precision time value. Such time values may be in local or in UTC time, and may be subject to device user intervention. Thus, the time value may be mostly useful to record the relationship of a series of log messages that occur over a very short period of time. In a representative embodiment of the present invention, conversion of log entry time values to a more readable format may be handled by a diagnostic/trace server such as, for example, the diagnostic server 129 or the customer care server 157, of
In a representative embodiment of the present invention, information may be maintained in binary form, to provide highest performance and to save message space. Indexes or other form of pointers may not be used to walk through messages. The following code example walks through all messages in the log message buffer. Note that although such functionality may be present in representative embodiments of the present invention, the following example code does not take wrap around of message in a circular buffer into account.
In a representative embodiment of the present invention, a RAM buffer may be managed as a sequential, circular buffer. In situations in which there is no place to save the contents of the RAM buffer, older log entries may be sacrificed to make room for new entries. When the RAM buffer is unloaded, the entire set of messages available at the start of the unload operation may be moved to a new location, and the contiguous memory freed can then be re-used. A representative embodiment of the present invention may employ a pair of “read” and “write” mutexes, so that the uploading operation may proceed to move older log messages while the Logger is adding new entries. This approach may be employed to protected log messages from being overwritten.
In a representative embodiment of the present invention, the Logger may use a log threshold to trigger the uploading of log data, to help free space for new messages. If internal flash memory has been configured as storage for log data, the Logger may notify an Internal Flash Transfer thread to move RAM messages to internal flash memory. If there is no internal flash memory configured, the Logger may notify the Uploader to move log data to appropriate external logging target(s) (e.g., SD card or USB linked PC). This enables a representative embodiment of the present invention to continue to free RAM log space for new messages.
In a representative embodiment of the present invention, moving data from RAM to internal flash (i.e., when the electronic device is so configured) may be an ongoing process, intended to free space in a much smaller RAM buffer. In some representative embodiments of the present invention, moving data from internal memory to one or more external targets may not automatically be triggered by the movement of log data from RAM to internal flash, as the log data may still be considered “internal” to the logging service. Uploading to the external target(s) may be triggered by one of the following exemplary types of events:
In a representative embodiment of the present invention, the thread that uploads internal log data (e.g., stored in RAM or internal flash memory such as RAM 165 or non-volatile memory 111, of
In a representative embodiment of the present invention, an “Internal Flash Transfer” module may be responsible for backing up the RAM log buffer to internal flash memory to free space in the RAM buffer. This moves log data to memory that will not be lost if the battery of the electronic device (e.g., electronic device 107 of
In a representative embodiment of the present invention, backup flash data storage may be managed as a variable number of 64 KB files (or, for example, some other selected file size), since adding data to the end of a very long flash file can be quite time consuming. The files may be named, for example, “BK—001” through “BK_xxx” to provide xxx times 64 KB of flash backup storage. If all backup files become full, the oldest backup file may be overwritten, so that only the oldest log data is lost.
In a representative embodiment of the present invention, each backup file may contain a set of contiguous and complete log messages, preceded by a message header. The message header may be completely filled when the final size is known. An exemplary message header is described elsewhere herein. In some representative embodiment of the present invention, log messages may not be split across files. It may be permissible to exceed the 64 KB file size (or, for example, some other selected backup file size) to complete a log message, but once a file exceeds 64 Kb, no more messages may be added to it. Each 64 KB file may be maintained in the format in which it will be transferred to an external target(s) (e.g., SD card, USB link PC, remote server via OTA).
In a representative embodiment of the present invention, the operating system of an electronic device (e.g., the electronic device 107 of
As each block of log memory is moved to internal flash memory, the current flash file size maintained in the file directory may be used to determine where to write the next block of log information. This value may be cached for efficiency, but any cached value may be discarded when the electronic device is rebooted. A representative embodiment of the present invention may handle a system crash or power loss that results in a corrupted directory entry. The flash file system may only update file length after the information is successfully written to flash memory.
In a representative embodiment of the present invention, writing to the RAM buffer (e.g., in RAM 165 of
In some representative embodiments of the present invention, when the Logger is called by an Interrupt thread (e.g., using an interrupt-specific entry point), special handling may be involved (e.g., for the Palm OS). When the Logger is operating during an interrupt, it may try to obtain the log mutex, but may not be able to “wait” for it if another thread has it. In such a case, the Logger may use a dedicated “interrupt buffer” to store the log data. In a representative embodiment of the present invention, memory space may be provided for such interrupt messages (e.g., five messages). If such memory space is exceeded, interrupt data may be lost.
When the Logger releases the RAM buffer mutex, it may check to see if any log messages have been placed in the interrupt buffer, and if so, may moves them into the main RAM buffer to free the interrupt buffer space. When updating any counters that control the interrupt buffer, the Logger may briefly suspend interrupts. The method for suspending interrupts may be specific to the manufacturer of the electronic device, to prevent data corruption of these counters.
In a representative embodiment of the present invention, the main Logger code may be written in native code for the processor of the electronic device (e.g., for an ARM-based processor in electronic devices that use a processor from ARM, Ltd.). An exemplary native code interface to the Logger is represented by the following function prototypes:
The format of the filter list may be as follows:
The format of function prototypes for Logging functions may be as follows:
In a representative embodiment of the present invention, code written for a first processor platform may be re-used on a second processor platform using a set of “shim” functions that allow calls to native code functions on the second processor. Such shim functions may convert parameters and other calling conventions to be compatible with the native Logger functions of the second processor platform, for processing. Conversion of big Endian to little Endian format may also performed by the shim functions, such that the Logger may always receive parameters in native processor format (e.g., for an ARM processor, little Endian).
In a representative embodiment of the present invention, the following variation of the above logging calls may be used (e.g., for code in electronic devices manufactured by Palm) that is running at interrupt time.
The Logger in a representative embodiment of the present invention, upon receiving this call may know that the Logger is being called at interrupt time, and that use of the interrupt specific logic detailed above is appropriate.
In a representative embodiment of the present invention, the following exemplary entry point may be used to enumerate (i.e., list) currently available log entries in internal log memory, RAM and internal flash memory:
In some representative embodiments of the present invention, this function may enumerate only the contents of the RAM log buffer. In other representative embodiments of the present invention, more full support may be provided.
In a representative embodiment of the present invention, the Uploader may be responsible for the actual transfer of log data from internal device storage (e.g., in RAM 165 or flash memory such as the non-volatile memory 111, of
Since the Uploader may run at lower priority than the thread that transfers RAM log data to internal flash memory, and since that move to internal flash memory may be non-blocking, the log data to be transferred externally may already have been stored as files in internal flash memory.
In a representative embodiment of the present invention, such external transfers may result from some type of trigger, accompanied by a notification (e.g., a mailbox message) to the Uploader thread. The various triggers may be specified in an Internal Log Memory Management section, as described above. Triggers may be pre-specified during Logger configuration, or may result from an explicit SMS message request from diagnostic/trace server such as, for example, the diagnostic server 129 or customer care server 157, of
In each of the above cases, a Log Transfer module may use one of the components described below to accomplish the actual data transfer, but may maintain control of the overall transfer process. The Log Transfer module may establish a data connection when needed for data transfer to a server such as, for example, the device management server 109, the diagnostic server 129 or the customer care server 157, and will take precautions to not interrupt an existing voice connection when establishing the needed data connection. The Uploader may minimize the data connection and transfer times in order to minimize the visible impact to the user, since on some electronic devices, voice calls cannot be made while a data connection is in session.
In some representative embodiment of the present invention, multiple targets may be selected. For this reason, the Uploader may move data in 64K blocks (i.e., the same as internal flash file size) to each selected target in a priority order. For example, if both the USB transfer to PC and SD card options are selected, and there are three (3) 64K files sitting in internal flash memory, the following exemplary transfer sequence may be used:
If one of several targets is unavailable for any reason, but another target is currently available, data may be written to the available target. The unavailable target may not receive the lost log data. A representative embodiment of the present invention may not attempt to preserve data for an unavailable target, when other targets are available. However, if no selected target is available (e.g., only an unavailable target is selected), the log data may be retained within internal flash memory of the electronic device (e.g., the electronic device 107 of
Note that in a representative embodiment of the present invention, the 64K value is an exemplary threshold, not a precise, fixed unit of data transfer. Since a log message may not be allowed to be split across internal flash files or transfer message blocks, it may be acceptable for some transfer messages to be a bit larger than 64K, to the extent that the last log message in the buffer crosses the 64 KB threshold. Each unit of log message transfer may be prefixed with the following exemplary message header:
In some representative embodiments of the present invention, when a new internal flash file is written, a complete header may be written to the front of the log file. In this case, the final file size may not be known until the last set of log messages is written. Until the final file size is known, the value of the header element u32MsgLength may be set to zero. When moving log files to an external target, Upload may copy the header from the flash file, fill in the message (i.e., file) length, transfer (e.g., write) the corrected header to the target followed by the log data, which may be written directly from flash memory. In the case where no internal flash memory has been configured, the Uploader may format the above header information directly from the RAM log data.
In a representative embodiment of the present invention, a boot number, maintained by the OS, may be placed in the header at the time the header is first created. When using internal flash memory, the change of a boot number may start a new log file. The time value may be device specific may be in a device-specific precision, and it may represent either device local time or UTC time. At the time the transfer header is created, the device time and a value representing the number of minutes offset from UTC may be calculated as show by the following exemplary sequence:
The reason this may be done at header creation time, rather than at log time, is that the conversion from local to UTC (or vice versa) may require access to preferences that may be stored in flash memory of the electronic device. Access to the flash memory may dramatically slow down the Logger when writing new log messages to the RAM log buffer.
The Uploader in a representative embodiment of the present invention may make use of one or more of the following exemplary modules to move data to the selected external target(s):
In a representative embodiment of the present invention, a Server Communications Module may contain low level code to support wireless communication over TCP/IP and HTTP. This module may be responsible the API's and protocol specifics employed to transfer each unit of “64K” log data reliably. Note that although SMS may be used for handset configuration and control, SMS may not be appropriate and may not be used for transferring large amounts of binary log data. For OS platforms that support TCP/IP over USB, this module may be used for USB data transfers as well to a USB attached PC.
Some electronic devices (e.g., some Palm OS-based electronic devices) do not have an HTTP interface for communication using the HTTP protocol. Such electronic devices may provide a file transfer interface used to move 64 KB files between the electronic device and a PC over a USB interface. It appears likely that the means of communication between an electronic device or handset and a PC will vary depending on the electronic device platform. In any case, in a representative embodiment of the present invention, the actual binary log information transferred may be exactly the same content and format as when communicating over the Internet, exclusive of protocol specifics.
In a representative embodiment of the present invention, a different interface may be used between an electronic device (e.g., electronic device 107 of
In a representative embodiment of the present invention, when a diagnostic/trace client such as the diagnostic client 121 is first in operation, it may not know how to communicate with its server. A diagnostic/trace client such as the diagnostic client 121, for example, may employ a subset of the IP configuration settings of a customer care system such as those used to communicate with a device management server, diagnostic server, or customer care server such as, for example, the device management server 109, diagnostic server 129 or customer care server 157 of
Until an electronic device (e.g., electronic device 107 of
In a representative embodiment of the present invention, such a configuration dialog screen may allow component and subcomponent IDs (e.g., ‘COMM’ and ‘RECV’) to be entered directly, to be able to activate (i.e., turn on) logging for components that have not identified themselves to an OS loader. Once the user has selected a set of component and subcomponent filters, a new filter list may be passed to the Logger via the SetFilters function described above, along with the user-selected severity level.
The configuration dialog screen may also provide a means for reconfiguring other Logger parameters such as, for example, the amount of RAM and internal flash memory to be allocated to the Logger. Note that reducing the amount of memory allocated to the Logger may result in the loss of some older log data.
The device-side logger configuration dialog may be seen as an extension of the existing log configuration dialog.
In a representative embodiment of the present invention, a diagnostic/trace server such as the diagnostic server 129 may used for collecting and persisting log data from groups of electronic devices (e.g., the electronic device 107 of
A diagnostic/trace server in a representative embodiment of the present invention may make use of functionality of a customer care server such as the SmartCare or FusionDM customer care server available from Bitfone Corporation, for example, for OTA collection and modification of diagnostic/trace settings on the devices. The diagnostic/trace server may initiate a collection or configuration request on an electronic device (e.g., electronic device 107 of
A diagnostic/trace server in accordance with a representative embodiment of the present invention, such as the diagnostic server 129, for example, may also be responsible for receiving and persisting log data collected on an electronic device like the electronic device 107 of
A diagnostic/trace server in a representative embodiment of the present invention may be implemented, for example, as a J2EE (Java Version 2.0, Enterprise Edition) application with a web-based user interface. A Struts Action framework may be used for building the web-based user interface. The application server used may be JBoss Application Server 4.0.3 SP1, available from Red Hat, Inc., and the database used may be Oracle 91 or higher, available from Oracle.
In a representative embodiment of the present invention, a subscriber may be a mobile phone account owner in a wireless carrier network, and may be characterized, for example, by a mobile number. Subscribers that have common characteristics may belong to the same Subscriber Class. An electronic device may be a mobile/cellular phone, a wireless-capable personal digital assistant or a pager, and may be characterized by an IMEI/ESN. A subscriber may have one or more electronic devices, but there may be only one ‘last known device’ associated with each subscriber. A user may be a person who logs in to a diagnostic/trace system to retrieve electronic device trace logs and to perform other administrative tasks. There may be two types of users in the system—a Super User and a Regular User.
In a representative embodiment of the present invention, each user may belong to a user group, and each user group may be allowed to manage subscribers belonging to one or more Subscriber Classes. A user may only be allowed to view and manage those subscribers that his/her user group has access to. The Super User may belong to a special DEFAULT user group, and may have access to all subscribers and functionality within the system.
In a representative embodiment of the present invention, a user may, for example, have the following properties: Login Name, Password, First Name, Last Name, Email, Work Phone, Mobile Phone, User Group, Time Zone, and Description. In some representative embodiments of the present invention, a default User Group may be preloaded into the database and a Group dropdown menu may only show the preloaded User Group. A representative embodiment of the present invention may employ web page user interface screens for searching, creating, editing and deleting Users from the database.
In a representative embodiment of the present invention, a subscriber may, for example, have the following properties: Subscriber Class, First Name, Last Name, MSISDN, Email, Home Phone Number, and Address. In some representative embodiments of the present invention, a Subscriber Class may be preloaded into the database and the Subscriber Class dropdown may only show the preloaded Subscriber Class. A subscriber may also have one or more devices. However, there may only be one “Last Known Device” associated with a subscriber. In a representative embodiment of the present invention, there may be web page user interface screen for searching, creating, editing, deleting and importing Subscribers.
To import a list of Subscribers and to associate them with an electronic device, a User may, for example, click on Browse, select a CSV file from the file system, and click Import. The CSV file may, for example, be in the following format:
If the IMEI/ESN is supplied, the system may try to associate the Subscriber with the electronic device. If the IMEI/ESN is not supplied or is not found in the system, the system may only create a Subscriber record.
In a representative embodiment of the present invention, a Device may, for example, have the following properties: Device ID (IMEI/ESN), Device Type, Description and Associated Subscriber. All Device Types may be preloaded into the diagnostic/trace database.
In a representative embodiment of the present invention, a Device may, for example, be created in one of at least two ways:
In a representative embodiment of the present invention, there may, for example, be screens for Searching, Creating, Editing, Deleting and Importing devices. Since the unique identifier of a Device is the Device ID, the Device ID is not editable once the device is created.
In a representative embodiment of the present invention, diagnostic/trace data may be logged on an electronic device (e.g., electronic device 107 of
In a representative embodiment of the present invention, the structure of a log message transmission header may be as shown in the following example:
In a representative embodiment of the present invention, the structure of a log entry may be as shown in the following example:
In a representative embodiment of the present invention, the server side may comprise a servlet, a Java Message Service (JMS) Queue and a JMS Listener for receiving trace data. For performance reasons, the servlet may have minimum processing logic. In some representative embodiments of the present invention, the servlet may just read the entire binary data stream, parse the message length in the header, and compare the total transmission data length. If the lengths do not match, a special HTTP status code, 400—Bad Request, may be returned. If the lengths match, the servlet may queue the data into the JMS Queue for further processing and return HTTP status code 200 (Success).
In a representative embodiment of the present invention, a diagnostic/trace data transfer session may be server-initiated by a User requesting a diagnostic/trace data dump on an electronic device, or may be client-initiated when a timer or buffer condition fullness is met on the electronic device, or when a PC application sends electronic device data back to a diagnostic trace server such as the diagnostic server 129 of
In a representative embodiment of the present invention, the JMS Listener may receive the message from the JMS Queue as a javax.jms.ObjectMessage. The JMS Listener may then parse the log data into individual diagnostic/trace log entries and write them persistently into the database.
In some representative embodiments of the present invention, duplicate diagnostic/trace data may result when both a PC Application and the electronic device (e.g., electronic device 107 of
In a representative embodiment of the present invention, a diagnostic/trace server such as, for example, the diagnostic server 129 of
In a representative embodiment of the present invention, each log entry may comprise a device-dependent time value (u64 Time) to record when the log message is logged. This time value may be returned by an API on the electronic device and the unit, precision, time zone and basis of the time may differ from electronic device to electronic device. A diagnostic/trace server such as the diagnostic server 129 of
In a representative embodiment of the present invention, the diagnostic/trace server may be responsible for capturing the datetime of when the log entry is received by the diagnostic/trace server. This datetime value may be stored as UTC in the last_response_date column in the MDI_LOG_EVENT table. If multiple transfer sessions for the same event (except for event id 0) are received by the diagnostic/trace server, the completion time of the last transfer session may be stored in the last_response_date column.
In a representative embodiment of the present invention, if the message transmission header contains a valid Device ID and no such Device instance exists in the database, the diagnostic/trace server may be responsible for creating the Device instance record in the database. If the message transmission header contains a valid MSISDN and no such Subscriber instance exists in the database, the diagnostic/trace server may be responsible for creating the Subscriber instance record in the database. The Subscriber may be created under the DEFAULT Subscriber Class. If the message transmission header contains both a valid Device ID and a valid MSISDN, the diagnostic/trace server may be responsible for updating the Last Known Device on the Subscriber record and the Subscriber ID on the Device record.
A representative embodiment of the present invention may support a user interface screen for displaying diagnostic/trace data on a device-by-device basis. The user can provide one or more of the following search criteria to further streamline the results:
In some representative embodiments of the present invention, the list of available Components and Subcomponents may be preloaded into the database. In other representative embodiments of the present invention, there may be screens for searching, maintaining, and importing Components and Subcomponents.
Below are a few examples of how these search criteria may be combined to produce useful reports:
In a representative embodiment of the present invention, search results may be displayed in tabular format. If there is any binary data, the “Binary?” column may show “Y”. By clicking on a magnifying class icon, a user may bring up a Trace Data Detail screen where binary data will be displayed as hex strings.
To delete a log entry, a user may check a checkbox of the log entry and click a “Delete” button. To delete multiple records, a user may check more than one checkbox and click the “Delete” button. To delete all records on the screen, a user may check a checkbox on the header to select all records, and then click the Delete button. Clicking on the header columns may allow a user to sort the results; Clicking on an “Export” button may export the search results to a CSV file. The format of such a CSV may, for example, be:
In a representative embodiment of the present invention, if the data value is empty, it may be represented as an empty string. If the data value contains a comma, the entire field may be enclosed in double-quotes. If the data value contains a double-quote, the double quote may be escaped by another double-quote in front, and the entire data value may be enclosed in double quotes. For example, a data record with no binary data and text data containing double quotes and comma that may as follows:
In some representative embodiments of the present invention, there be no export or display of data in XML format.
In a representative embodiment of the present invention, clicking the ‘Transmit’ button on the web page user interface screen 1500 for displaying diagnostic/trace data may send a specially formatted SMS message to the identified electronic device, to request a Trace Data Transfer. Such a request may employ either proprietary or standards-based protocol, such as that employed in the SmartCare and FusionDM products of Bitfone Corporation. When an electronic device such as the electronic device 107 of
In a representative embodiment of the present invention, clicking the ‘Clear’ button on the web page user interface screen 1500 for displaying diagnostic/trace data may send a specially formatted SMS message to the identified device to clear all Trace Data. The Clear Data Request may employ either proprietary or standards-based protocol, such as that employed in the SmartCare and FusionDM products of Bitfone Corporation. When the electronic device receives a Clear Data Transfer Request, it may clear all trace entries on the electronic device.
In a representative embodiment of the present invention, the Super User may have the ability to retrieve trace data on one or more Devices. This feature allows the Super User to generate diagnostics statistics for a selected group of devices. The search criteria may include, for example:
Below are a few examples of how these search criteria may be combined to produce useful statistical reports:
In a representative embodiment of the present invention, there may be a user interface screen for displaying the most recent Device information collected. This Device information may includes the Device IMEI/ESN, Manufacturer, Model, Platform, Revision, Processor, OS Version, Free Memory, Signal Strength, and Data Connection Settings, for example. Additional Device data may be collected depending upon the functionality of the APIs in the electronic devices.
In a representative embodiment of the present invention, the most recently collected diagnostic/trace settings from the Device may also be displayed. These settings may include, for example:
1. A Collection of Filter Criteria
In a representative embodiment of the present invention, data may be displayed as key-value pairs on the user interface screen and parameters may be categorized onto different tabs on the display.
To trigger a real-time collection of device data and diagnostic/trace settings in a representative embodiment of the present invention, a User may click on the “Profile” button.
To configure settings on the Device in a representative embodiment of the present invention, a User may click on a small “edit” icon next to an attribute. This may open up the field(s) for editing. After the settings are modified and saved, the User may click on “Configure” to see a Summary of configuration changes. The User may click on “Configure Device” to send the configuration changes to the Device.
In a representative embodiment of the present invention, the User may be configure and fix TCP/IP connectivity by editing settings on the “Connection” tab.
A representative embodiment of the present invention may make use of standards-based protocols, or a proprietary protocol such as that employed by the SmartCare and/or FusionDM products by Bitfone Corporation, for collection and modification of Device data and diagnostic/trace settings. A transport mode parameter for profile and configuration may be set to “Auto”, so that the Device may automatically try TCP/IP first, and then revert to SMS if TCP/IP connectivity is not available.
Aspects of the present invention may be seen in a handheld electronic device comprising at least one non-volatile memory having stored therein one or both of firmware and software, and at least one processor operably coupled to the non-volatile memory. The at least one processor, during operation, may wirelessly receive, from a remote server via a communication network, configuration information for controlling one or more of diagnostic, monitoring and tracing activities in the handheld electronic device. The configuration information may be communicated according to a device management protocol standard. The at least one processor, during operation, may store the configuration information as a sub-node of a standards-defined device management object in a device management tree in the non-volatile memory, and may log information comprising one or both of events and operating parameters of the handheld electronic device based upon the configuration information for controlling one or more of diagnostic, monitoring and tracing activities in the handheld electronic device. The at least one processor, during operation, may also transfer the logged information to a remote server via a communication medium.
In a representative embodiment of the present invention, the handheld electronic device may comprise one of a mobile handset and a cellular phone, and may comprise one of a personal digital assistant and a personal computer. The received configuration information may be expressed as extensible markup language (XML), and the configuration information may be stored as a sub-node or part of a device management object defined in the Open Mobile Alliance (OMA) Device Management (DM) Version 1.2 or later protocol specification. Storing the configuration information may comprise adding an application-related sub-node to a standards-defined device management object in the device management tree.
In a representative embodiment of the present invention, the non-volatile memory may comprise flash type memory. The communication medium may comprise the communication network, a universal serial bus (USB) communication connection, and a non-volatile memory card known as a Secure Digital (SD) card. The communication network may comprise a public communication network. The configuration information may be accessible using an Open Mobile Alliance (OMA) UAProf based device profile. The logged information may be accessible as a sub-node of a standards-defined device management object in a device management tree, and the management object set or modified by storing configuration information may be initially set by a manufacturer of the handheld electronic device.
Further aspects of the present invention may be found in a computer-readable storage comprising a plurality of code sections for operating a handheld electronic device in a device management network. The plurality of code sections may have stored therein instruction code executable by a processor for causing the processor to perform a method. Such a method may comprise wirelessly receiving, via the device management network, configuration information for controlling one or more of diagnostic, monitoring and tracing activities in the handheld electronic device. The configuration information may be encoded to be compatible with a device management protocol standard. Such a method may comprise storing the configuration information in a non-standard sub-node of a standards-defined device management object of a device management tree in non-volatile memory of the handheld electronic device. Such a method may also comprise logging information comprising one or both of events and operating parameters of the handheld electronic device based upon the configuration information for controlling one or more of diagnostic, monitoring and tracing activities in the handheld electronic device. In addition, a method in accordance with the present invention may comprise transferring the logged information to a remote server via a communication medium.
In a representative embodiment of the present invention, the code sections may further comprise instruction code executable by the processor for causing the processor to wirelessly receive information for updating instruction code in the computer-readable storage to update functionality of the handheld electronic device. The handheld electronic device may comprise one of a mobile handset and a cellular phone, and the handheld electronic device may comprise one of a personal digital assistant and a personal computer. The received configuration information may be communicated as extensible markup language (XML), and the device management protocol standard may be the device management protocol referred to as the Open Mobile Alliance (OMA) Device Management (DM) Version 1.2 or later protocol. The non-volatile memory may comprise flash type memory.
In a representative embodiment of the present invention, storing the configuration information may comprise adding an application-related sub-node to a standards-defined device management object in the device management tree. The code sections may further comprise instruction code executable by the processor for causing the processor to wirelessly download update information used to update the one or both of firmware and software. The communication medium may comprise the communication network, a universal serial bus (USB) communication connection, and a non-volatile memory card known as a Secure Digital (SD) card. The device management network may comprise a public communication network. The configuration information may be accessible using an Open Mobile Alliance (OMA) UAProf based device profile. Storing the configuration information may comprise adding one or both of a diagnostic and a tracing-related non-standard sub-node from a standards-defined device management object in the device management tree. The logged information may be accessible as a sub-node of a standards-defined device management object in a device management tree.
Yet other aspects of the present invention may be seen in a system for managing diagnosis and tracing of a plurality of handheld electronic devices. Such a system may comprise at least one server comprising at least one interface enabling communication with the plurality of handheld electronic devices via a wireless communication network. The at least one processor may be operably coupled to the at least one interface and at least one memory containing configuration information for controlling one or more of diagnostic, monitoring and tracing activities in the plurality of handheld electronic devices and information for updating executable code in the plurality of handheld electronic devices. The at least one processor may function during operation to, among other things, receive a request for one or both of diagnostic and tracing functionality for one of the plurality of handheld electronic devices. The at least one processor may also function during operation to store configuration information for controlling one or more of diagnostic, monitoring and tracing activities for the one of the plurality of handheld electronic devices in the at least one memory. In addition, the at least one processor may transmit, to the one of the plurality of handheld electronic devices via the wireless communication network in accordance with a device management protocol standard, the configuration information for controlling one or more of diagnostic, monitoring and tracing activities for the one of the plurality of handheld electronic devices. The transmitted configuration information may be arranged to cause updating of a non-standard sub-node of a standards-defined device management object in a device management tree in memory of the one of the plurality of handheld electronic devices.
In a representative embodiment of the present invention, the plurality of handheld electronic devices may comprise one of a mobile handset and a cellular phone, and may comprise one of a personal digital assistant and a personal computer. Transmitted configuration information may be communicated as extensible markup language (XML), and the device management protocol standard may be the device management protocol referred to as the Open Mobile Alliance (OMA) Device Management (DM) Version 1.2 or later protocol. The at least one processor may function during operation to, among other things, receive logged information for one or more of diagnostic, monitoring and tracing activities from the device management tree of the one of the plurality of handheld electronic devices. The at least one processor may function during operation to, among other things, download update information used to update one or both of firmware and software to the one of the plurality of handheld electronic devices.
In a representative embodiment of the present invention, the communication network may comprise a public communication network. The device capability information may be arranged according to an Open Mobile Alliance (OMA) UAProf based device profile. The transmitted configuration information may be arranged to cause adding of a non-standard sub-node of a standards-defined device management object in the device management tree in memory of the one of the plurality of handheld electronic devices.
Still other aspects of the present invention may be found in a handheld electronic device comprising at least one memory having stored therein one or both of firmware and software. Changes in functionality of the handheld electronic device may be enabled by remotely updating the one or both of firmware and software. One or more of diagnostic, monitoring and tracing activities in the handheld device may be enabled by remotely provisioning configuration information for controlling one or more of diagnostic, monitoring and tracing activities as additional management objects in a standards-defined device management tree. The handheld electronic device comprises a cellular phone. The device management tree may be in accordance with a device management protocol referred to as the Open Mobile Alliance (OMA) Device Management (DM) Version 1.2 or later protocol.
Other aspects of the present invention may be observed in a system for managing one or more of diagnostic, monitoring and tracing activities in mobile electronic devices. Such a system may comprise at least one server communicatively coupled to at least one mobile electronic device. Configuration information resident in memory in the at least one mobile electronic device may act to control the one or more of diagnostic, monitoring and tracing activities of the at least one mobile electronic device, and the configuration information may be initially provisioned and subsequently managed using management objects based on a device management protocol referred to as the Open Mobile Alliance (OMA) Device Management (DM) Version 1.2 or later protocol standard. The at least one mobile electronic device may comprise a cellular phone. The initial provisioning of configuration information in the at least one mobile electronic device may be performed by a manufacturer of the at least one mobile electronic device. One or more of diagnostic, monitoring and tracing activities of the at least one mobile device may be enhanced by remotely updating, from the at least one server, one or both or firmware and software in the memory of the at least one mobile electronic device. The enhanced functionality of the at least one mobile electronic device may be enabled by new management objects provisioned, by the at least one server, into a device management tree in the memory.
Although a system and method according to the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternative, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by this disclosure and appended diagrams.
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 Application Ser. No. 60/774,406 entitled “Diagnostics And Monitoring Services In A Mobile Network For A Mobile Device” (Attorney Docket No. 17521US01 101USMD134), filed Feb. 17, 2006, the complete subject matter of which is hereby incorporated herein by reference, in its entirety. The present application also makes reference to U.S. Patent Application Ser. No. 60/664,249 entitled “Device Client Specification”, (Attorney Docket No. 16639US01 101USMD117), filed on Mar. 21, 2005, the complete subject matter of which is hereby incorporated herein by reference, in its entirety. In addition, this application makes reference to U.S. Provisional Patent Application Ser. No. 60/249,606, entitled “System and Method for Updating and Distributing Information,” filed Nov. 17, 2000, and International Patent Application Publication No. WO 02/41147 A1, entitled “System And Method For Updating And Distributing Information”, filed Nov. 19, 2001, and having publication date Mar. 23, 2002, the complete subject matter of each of which is hereby incorporated herein by reference, in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60774406 | Feb 2006 | US |
