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.
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!]