To Build or to buy? To Patent or not to?

The mobile software industry is never short of challenges. Manufacturers and software vendors are constantly riddled with the question of build vs. buy; should they invest in in-house development of a software component, or license it from a supplier? Ultimately build vs. buy is an investment decision, as it requires investment of either resources or money and so is determined by a multitude of factors. A complex ecosystem of customers and stakeholders affected by software decisions, combined with the many software components in a mobile phone can make the build vs. buy decision a difficult call.

Additionally this decision is increasingly complicated by patent and intellectual property rights considerations. It is not coincidental that over half of the top 20 patent filing applicants in 2006 are major mobile handset or equipment manufacturers, according to WIPO (see below). These immensely successful companies obviously see the link between successful intellectual property and patent strategy – so is there a lesson here for software providers?

3. Siemens
4. Nokia
10. Motorola
11. Mitsubishi
12. Qualcomm
13. Huawei
14. Ericsson
15. Fujitsu
16. LG Electronics
18. HP
20. Samsung

Unlike the top-20 patent players, most technology companies lack dedicated IP and patent teams. However, tomorrow s successful companies will be those that pay due attention to the increasing importance of these key strategic build vs buy and patent decisions

Build vs Buy: decision criteria
At the most basic level, the decision whether to build or buy a piece of software comprises some basic factors:

1. Stick to standards? It generally makes sense to implement an industry standard, if one exists, particularly if the standard is accepted and widely used. Differentiation can be achieved by exemplary implementation of a standard, providing you with a means of excelling against your competition. However it should be noted that there are IP risks with implementation of even de-facto industry standards, as with the recent claim successfully brought by Alcatel against Microsoft for infringement of their patents in the MP3 standard.

2. In-house development? Considerations here are your in-house development expertise, prioritisation of the requirement given limited resources and budget availability. If you are developing in a new technology area the decision about whether to build or buy has additional complexities. Assuming that there is no standard industry agreement regarding a new technology (and this is usually the case) it is likely that you will need to either develop your own solution or alternatively look to procure a solution from specific technology experts. Investment in new technologies is increasingly expensive and so you will necessarily be looking for a solution that has the potential to become the dominant solution in the market and ideally reap you profitable revenue returns.

The following diagram illustrates the build vs buy trade-offs depending on whether the technology is standardised or new.

Build or Buy ?

3. The complexities of intellectual property rights
Not withstanding the generally well acknowledged technical and developmental challenges of new technology areas, there is an additional factor that is generally less well understood by software companies but one that is no less important. It is Intellectual Property Rights (IPR) and patents how these can play out in a new technology development lifecycle. I ‘ll next try to analyse the key IPR issues (although I ‘m not a laywer, so seek advise before acting!).

Assuming that a build decision is reached, then there are a number of IPR factors to consider. If you are a mobile software company it would appear prudent to carry out some initial investigations in the technology area to ascertain if others already have essential patents (essential meaning that you cannot implement the technology without them).

However this apparently logical decision is not without its own risks. In the US, for example, knowledge that a third party has patents in a technology area that you wish to develop in can potentially give rise to punitive damages (up to three times the normal damages) this is if the courts determine that you wilfully ignored this fact, having had prior knowledge of the fact in the technology development stage. The alternative, to fastidiously ignore what others have done to create and patent your own solution is not without risks either. If you are found to have infringed others patents after having developed the technology, you still run the risk of being litigated against for patent infringement. It may feel as though you are damned if you do infringe patents and damned if you don t! Thorough investigation is definitely preferable to blind ignorance.

Assuming that you successfully navigate your way around the patent minefield, there is then the all important objective of achieving adoption of your technology to ensure your investment is successful whilst also ensuring that you retain some exclusivity to the technology to benefit from your first-to-market position. Patenting your solution can give you the security of exclusivity and makes sense in order to protect your investment, but how do you then achieve successful adoption of your technology knowing that others may be put off by your having patents in this area?

These objectives, which may initially appear mutually exclusive, can be managed provided you have planned your patent strategy in advance. For example, you could setup (or join) an industry standards body and contribute the essential technology patents thus ensuring a level playing field, at least for the basic implementation. Additionally you may provide additional patents under FRAND terms (fair, reasonable and non-discriminatory terms). Companies who wish to implement technologies in this area, may prefer to license your patents knowing that this then gives them some indemnity regarding their risk of potential infringement. However, at what point in the technology development lifecycle is it appropriate to take this decision and to allow others to either contribute or license your essential patents?

Unfortunately there is no one-size-fits-all solution; each decision should be taken with a good understanding of the likely outcomes, benefits and drawbacks.

Decisions regarding build vs buy and to patent or not to patent are bread and butter issues for mobile software companies. Whether the importance of these issues registers is another matter. Strategic gains, in the form of revenues and technology leadership (or even domination) can be achieved by either forcing others to acknowledge your patent as an essential one or by preventing competitors from innovating in a specific technology space by virtue of your patents. Nevertheless, there is always the risk that third parties will find an alternative technology implementation that does not require your essential patents, which may prove more successful or, even more worryingly that your technology could be found to be infringing others patents.

So whilst build vs. buy decisions may be perceived as generally straight-forward, they are actually complex, strategic product decisions. The technology company that leaves these decisions only to their development or engineering teams may be jeopardising their success more than they are aware. As reiterated by Ikka Rahnasto, Nokia s Vice President for Intellectual Property Rights in a recent WIPO magazine article Our IP strategy is deeply integrated into Nokia s business strategy. the focus has increasingly been on understanding the role of IP in each Nokia business and on improving the return on our technology and IP investmen…IP assets are managed by a centralized IP department reporting to the Chief Strategy Officer, with very close links to Nokia business groups and technology groups to enable full strategic alignment .

[updated: Thanks to WapReview for mentioning this post at the Carnival of the Mobilists!]

Rethinking application environments

Handset software is a fascinating topic in the mobile industry, albeit one that is often misunderstood. Application environments like Java, Flash Lite and Qtopia open the world of handset software to developers and allow the handset GUI to be customised. Here I introduce a new taxonomy for application enviroments and explain why seemingly distinct technologies like S60, Widsets, Maemo, Qtopia and Openwave MIDAS are essentially part of the same landscape.

[Note: I have updated this article in response to much feedback and comments (thanks Nick, Philippe and Malcolm). Thanks also to Judy Breck maintainer of the Carnival of the Mobilists for selecting this article as post of the week.]

Today there are 10s of different tools technologies for opening up handset software to developers and generally those who want to customise the handset GUI in some shape or form. These range from skins designers, to games developers, to operators who want to create a ‘signature’ look & feel spanning the entire user interface. I would argue that application environments include not only Java, as well as environments for creating skins, desktop UIs (a.k.a. idle screens) and core applications (dialler, menu system, email, messaging applications, etc which are entirely different to downloadable applications).

Contrary to popular understanding, openness is not an exclusive privilege of open operating systems (OSes) as I argued in a previous research paper. A range of technologies exist to ‘open’ access to the handset software internals, and can be divided in two categories: external and internal application environments.

The distinction between external and internal environments is down to several variables: level of functionality exposed to an application, who can access that functionality (certified apps only?), depth of integration (e.g. can you replace core apps such as the dialler and contacts application), when an application can be installed (at the point of manufacture, before the point of sale, or after the point of sale) and who can install the application.

1. External application environments, i.e. those which allow application development and handset customisation after the software has been embedded in the handset ROM. These are generally accessible to external developers, scripters and designers. Examples are:
– Nokia’s S60, SonyEricsson’s UIQ, Microsoft’s Windows Mobile and Qualcomm’s BREW, which are advanced platforms. These can also be viewed as external application environments, in that they offer a rich set of APIs for application development and deployment post-load, in other words environments designed for developing downloadable but not core applications. For example companies like DreamSpring have created good contacts replacement applications for UIQ and S60. However such applications are not a complete replacement for core apps (such as the contacts app) since the can only hide the built-in app, and they are not able to access sensitive APIs such as the voice-dialling API as this is hidden by the handset manufacturer. See my comment on this post for further analysis on why S60/UIQ etc are designed as external and not internal app environments.
– Open C (POSIX APIs on top of Symbian), which are C/C++ APIs aimed for use by application developers
– Java 2 ME (in its myriad forms and extensions), Python for S60, .NET Compact Framework and AppForge, a range of application environments for developers or scripters
– Adobe’s Flash Lite aimed at scripters and designers developing graphics-intensive apps.
– S60 ActiveIdle, Windows Mobile homescreen framework and Nokia’s Widsets, a range of technologies for allowing developers to customise the UI desktop (aka idle screen)
– Nokia’s Carbide.UI theme edition tool for deep skinning of the handset GUI

2. Internal application environments, i.e. those which allow application development and handset customisation before the software has been embedded in handset ROM (and in certain cases during the handset lifetime, too). These are accessible to handset manufacturers, network operators and handset distributors. Examples are:
– Openwave MIDAS, a ‘deep’ scripting environment for creating operator-customised applications
– SVG players from Ikivo and BitFlash for developing graphics-rich, interactive applications such as Vodafone’s Live! Cast.
– TAT’s Cascades, Digital Airways’ Kaleido and Mentor Graphics’ Inflexion (previously NextDevice), which are rapid prototyping tools software frameworks for rapidly creating custom end-to-end user interfaces (i.e. the entire suite of core applications) from scratch.
– e-SIM (now part of SKY Mobile Media) and Comneon’s APOXI, which are development tools for building suites of core applications (albeit tools which are more aimed towards engineers than designers).
– Trolltech’s Qtopia, Maemo’s Hildon port, ALP’s Hiker, OpenMoko’s application framework, TTPCom’s Ajar and Windows CE app framework, which are sets of C/C++ APIs for creating core applications and managing application communication and lifecycle.

In the next diagram I attempt to classify the above application environments in terms of the extent of customisation which they permit and the time at which they can be applied.

The x-axes show, the time of customisation is directly related to the barriers to customisation; internal application environments are mostly accessible to the manufacturers and partners, whereas external application environments are accessible to all. Note that the chart is quite extensive but it is still work in progress.

The y-axis shows that there are four broad types of customisation that can be applied via application environments:
– change of themes and skins across the handset (e.g. Carbide UI theme edition)
– development and deployment of downloadable applications (using e.g. S60, UIQ, Windows Mobile, BREW)
– replacement of a core application (e.g. replacing the idle screen or contacts app)
– core application re-design (redesigning the entire user interface from scratch)
Taxonomy of application environments

This landscape map is very revealing, but still it doesn’t do enough justice to highlight some important parameters of application environments: the cost of customisation, the part of the software stack which a technology provides, and the target addressable market in terms of breadth of device models. Another important parameter is why customisation is applied: this can be to re-enforce branding (and retain customers) or to provide easier discovery of, and access to, new services by operators and third parties.

A couple of noteworthy remarks on the map:
– Flash Lite is moving from an application environment for downloadable, graphics-intensive apps, to an environment for creating other core applications such as the idle screen and the dialler (see the Samsung D900 implementation for example).
– Java is also moving towards enabling development of desktop UIs (aka idle screens) and some core apps, thanks to the capabilities introduced in MIDP3.

So what are the trends in application environments? On one hand all ecosystem players, from operators to manufacturers and beyond are striving to reduce the high time-to-market impact of pre-launch customisation. At the same time, external application environments do not reach as far as core applications (desktop UI, dialler, menus, email/calendar/contacts applications, camera application, etc), due to the lack of modular design of most operating systems today (including Symbian/S60 and Windows Mobile, the so-called ‘open’ OSes).

Therefore, a number of technologies are being introduced to bring much-needed modularity within application environments, both pre- and post-launch. These range from rapid application creation tools from TAT, Digital Airways and Mentor Graphics, to Open Plug’s FlexibleWare modular software development framework and Red Bend’s Embedded Feature Delivery technology. These technologies will be impacting not only handset development practices, but also making an impact to the consumer market. Within the next year we should hopefully be seeing many more examples of unique GUIs such as Vodafone’s Simply range and B&O’s Serene handset.

Thoughts ?