Flying the MDM Flag

David Murphy meets David Ginsburg, Vice President, Marketing & Product Management at MDM (Mobile Device Management) firm, InnoPath

DM: So give us the InnoPath story if you would please David.

DG: We launched in 2003 with FOTA (Firmware Over The Air) deployments in Japan, expanded to Tier 1 operators in N. America in 2005, and we are now extending our OMA-DM (Open Mobile Alliance - Device Management) footprint globally.
We have gone through five quarters of profitability. In September, we announced that Verizon had launched a FOTA service using our software. We are currently deploying with China Unicom, the second largest operator in the world, which is adopting MDM for FOTA updates, advanced customer care, and security, and we have also been selected by KDDI as the basis for their next-generation common platform, a BREW implementation spanning all handsets in their network in Japan.
We are firmly focused on device management, and we are seeing 2008 as a watershed year, with deployments in places like Europe and Latin America. We have a complete server-side solution that we sell into operators, and a client solution that we sell into OEM partners (handset makers), so we bring a unique understanding to the market of the problems and concerns that both the operators and the OEMs have in deploying an end-to-end solution. These solutions are part of our Integrated Mobile Device Management (iMDM) product family.

DM: And what’s on the cards for this year?

DG: We have three big announcements for 2008. The first is that we are extending our reach through our new Customer Self-Care and operator Customer Service Representative (CSR) portals. The second is that we are extending our reach into enterprise device management with a new client architecture and the industry’s first implementation of OMA-DM standards-based application management. The third is a set of initiatives to kick-start the deployment of OMA-DM within GSM operators through an Integrated Device Capabilities Repository (iDCR) that adds OMA-DM for the first time, coupled with a hosted FOTA offering with our partner WDSGlobal.  We’ve also announced a set of device testing initiatives to ensure end-to-end interoperability between our iMDM server and both our client as well as those from other vendors.

DM: So tell us a little more about OMA-DM.

DG: OMA-DM defines a set of standards that are relevant to Over the Air (OTA) device management. Most operators and OEMs are familiar with FOTA – firmware updating. But configuration management is important as well, and can take place in two different ways. The older way is OMA-CP, for Client Provisioning. Almost all GSM operators have deployed CP, and many are looking to evolve their deployments to OMA-DM. This all implies the existence of the device management client on the handset. Analysts are predicting about 26% penetration for this by the end of this year, a number confirmed by the OEMs and the Tier 1 operators. Right now, it’s about 15% if that.
The SCOMO (Software Component Management Object) component is concerned with the management of applications and should be standardised by the summer. We are one of the drivers here, and it will permit OMA-DM to be used for enterprise device management. There are also two other areas undergoing standardization: diagnostics management, permitting the operator to check on the health of the device or the network; and security management, including ‘lock & wipe’ functionality, for when a handset is lost or stolen and the owner wants to prevent someone else from using it or accessing the information, such as emails and contact details, stored on it.
Based on customer demand, what we have done in some instances is to bring pre-standard implementations to the market. For example, we use a partner for client-side lock & wipe functionality, and they have implemented an OTA paradigm for device management, but they use their own objects to control locking and wiping. An operator deploying this solution may easily upgrade to the standard once finalized, since it will require no changes on the iMDM server.

DM: And what’s the Self-Care Portal all about?

DG: Currently, if a customer has a problem on a device that is not OMA-DM enabled, they go into IVR hell, as I call it. It takes forever to reach the correct helpdesk person and then to correct the problem. To date, we’ve sold our iMDM server into the operator, but they have limited the use of the iMDM console to the upper tiers of customer service. The Self-Care Portal means the operator can, for the first time, extend the reach of mobile device management all the way down to the first tier with little or no training, and can further extend its reach to the subscriber. They may now easily troubleshoot and self-correct handset problems, protect their phones if lost, or download new software when required.
This addresses one of the operators’ biggest problems - frontline customer care, as evident with growing expenses and more and more issues that go unresolved.  The net effect is that the customer has to send the handset in or go to the shop, when it’s usually something basic and easy to fix.   
Every operator has a subscriber portal for phone upgrades, billing enquires etc. Now the customer can click a tab saying ‘Self-Care’ and troubleshoot problems themselves. So let’s say they are having problems with a multimedia streaming application. The customer logs on, the back end queries the MDM server, and this queries the device, checks for firmware revisions, and if a problem was identified in a given firmware release that causes problems with this multimedia application, what could happen is that the subscriber would get a message saying: ‘Jane, we know what the problem is. Your phone has firmware revision 1.0. We want to upgrade you to 1.2. Do you want to accept?’ Once Jane accepts, the firmware is immediately upgraded over the air. 
Or perhaps the problem is not with the firmware on the phone, but the Self-Care Portal says: ‘We want to check the runtime configurations, can we pull them off the phone?’ So then through OMA-DM, it queries the configuration parameters and compares them with the operator’s baseline for services and so identifies a problem and corrects it.
Or let’s say Jane loses her phone, including all her contact information and emails. She can go on to the portal to lock the device and wipe the data off it. But let’s say she wants to restore this information if the device is found. The second part of the service would be for the operator to offer a back-up and restore service. 

DM: And operators want this?

DG: Without a doubt. The operators are saying to us that anything we can do to add another layer of diagnosis or troubleshooting before the customer gets to them is a great thing, and will save them money. Putting a heavyweight client on the device has been bounced around as a partial solution, but this is a much simpler solution that makes use of the native OMA-DM client on the handsets.

DM: And the Customer Care Portal?

DG: This uses the same architecture as the Self-Care Portal, but it’s designed for the operator. It enables frontline representatives at operators to diagnose and fix mobile phone faults with a single click, and to offer and configure new services and applications. So it too could be used to push a firmware upgrade to the device, for example. Or if a lot of brands started using QR (Quick Response) Codes on their advertising, for example, it could be used to offer customers a QR Code reader as a download to their phone so they could interact with these promotions. In both cases, the portal is completely customisable by the operator. What is shown to the subscriber or the customer services representative is aligned to their service plan, so they can be given the option to upgrade to this or that service or tariff in a very targeted manner.

DM: And what is the level of device management penetration?

DG: Verizon says that by the end of 2008, it hopes to have 50% of its customers’ handsets OMA-DM-enabled. AT&T mandates it on 3G devices. This is something you can run the numbers on and say it is going to impact this percentage of customer care costs, so it is easy to project the positive impact on frontline service costs.

DM: And what sets InnoPath apart from any other MDM company?

DG: We have focused on a foundational approach to MDM as opposed to gluing together this and that functionality and pasting in some Frankenstinian system; it is a scalable extendable platform so it’s simple to add new services such as lifecycle application management or security capabilities. In addition, we’re now leveraging what we’ve learned as part of mass consumer deployments into the enterprise device management space. In line with this, we are working with operators on a global basis to evolve their existing MDM deployments from FOTA to more advanced technologies, and working with them to understand how to deploy MDM. To support this, one focus of this set of announcements is that we have spoken to operators and integration partners and said: ‘What are the barriers to entry? Where do you have trouble managing devices over DM?’ Some say that they do not know the device capabilities for management. Or there is no end-to-end interoperability testing with handsets and no way to integrate applications into DM and create new workflows, without spending umpteen millions of Euros with systems integrators. So this is why we want to kick-start the adoption of device management in the GSM world. They want to migrate to OMA-DM, but in some areas need help. 

DM: How will you do that?

DG: One way is through interoperability testing. We have relationships with major OEMs who resell our client and we are creating standard-based test tools that OEMs can use to make sure they are compliant with standards. We are also making our server platforms available in a secure fashion across the web to OEMs and third-party OMA-DM client vendors, so they can test client implementations against our server. Then the next stage of testing is to enable them to test very operator-specific versions of our server. Operators want testing ahead of the client so they know when a handset with an OMA-DM client comes onto the network, and that it works out of the box.
The problem for operators is that they have OMA-DM devices on the network, but they don’t know what applications a given handset supports. How do you map it into the server? To answer this, we are taking the device capabilities repository concept, bringing in data through our OEM partners and in-house interoperability testing and other sources into a single database, and making it available to customers. This then allows them to deploy our server platform with the necessary data to effectively manage the OMA-DM client in their network.