LiMo Foundation Blog

LiMo’s Legal Counsel, Chris Edwards, summarises some interesting IPR/patent-related snippets that have caught his eye over the past few days:-

1.  Red Hat/Novell Patent Triumph

Red Hat & Novell have successfully defended a patent infringement suit, brought by 2 “non practicing entities” (who some choose to call “trolls”…), in the Eastern District of Texas.  The jury, apparently comprised of individuals with no knowledge/experience of open source software, unanimously found in favour of the defendants.

Having had (pre-LiMo) first-hand experience of dealing with such “claimants”, and the related pressures (both financial and commercial) to settle (even unmeritorious claims), I can only applaud Red Hat & Novell (and, of course, their Lawyers :-)) for sticking to their guns and coming out on top.

See http://opensource.com/law for more information.

2.  Microsoft & HTC

On 28 April, it became known that Microsoft & HTC had signed a patent license deal under which HTC will pay royalties in respect of HTC “Android” mobile phones to Microsoft.

Mobile data has finally arrived. After years of hype, the volume of data on mobile networks is reported to have surpassed that of voice traffic. Whilst the majority of this traffic is driven by people with mobile broadband subscriptions, undoubtedly the new breed of data-intensive mobile devices contributes significantly to this rapid growth. This bandwidth consumption is stressing the edge of the network and backhaul, resulting in a potential field day for providers of optical and microwave infrastructure. I could successfully argue that the capacity crunch is already upon us.

A frequently cited answer to congestion problems is to off-load mobile data from the mobile core network. Various techniques may be deployed to achieve this, such as WiFi or Femtocell offload. For the best results, both approaches rely on mobile devices being aware of their network context and acting accordingly. Unfortunately, the majority of handset software platforms have yet to acquire the necessary smarts to make best use of these whilst staying within the strict energy budgets imposed by today’s battery technologies.

Having spent many years extolling (and publically promoting) the benefits of Java (working for SUN), and in particular Mobile Java in the guise of J2ME, to solve the issues of application portability and fragmentation, I have many battle scars to demonstrate how difficult a panacea to cross platform development and application deployment really is. Remember the battle cry (WORA!!!) Write Once Run Anywhere, or you will probably know it under one of the other acronyms such as (WODE) Write Once, Debug Everywhere, which was much closer to the truth.

I remember speaking with a relatively small mobile Java games development company (who will remain nameless), and they informed me that they had to support 25,000 different SKUs (Stock Keeping Unit) i.e. different versions of their applications, as each device, and in many cases, different versions of the same device, required slightly different versions. So much for WORA.

SUN did a really “poor” (euphemism) job of controlling the definitions and implementations of the various JSRs, leaving too much to the discretion of the implementer. They were really stuck between “a rock and a hard place”, trying to please too many people whilst trying to appear Open.

We have seen similar issues with web site compatibility; although web standards (HTML, CSS, JavaScript etc) are well defined, we all know the issues with “interpretation”.

So what is the answer?

Apart from the expected public response from HTC (“HTC disagrees with Apple’s actions and will fully defend itself...”), and the somewhat more intriguing (preceding) statement from Google (“We are not a party to this lawsuit. However, we stand behind our Android operating system and the partners who have helped us to develop it”), I’m not aware of any substantive developments.  Each case will follow its own procedural timetable (pursuant to which there will be further public filings), and we obviously won’t get to know about any “background” discussions unless they culminate into something worthy of public announcement (e.g. settlement...)

One of our readers asked, “Why did Apple sue HTC and no one else?”   When a patent holder identifies potential broad infringement (by a number of parties), there are a number of factors - legal, commercial, economic and strategic - that are considered when determining who to sue.  It should also be remembered that patent litigation is expensive (even for a goliath such as Apple), and the fewer parties sued equate to lower legal bills (important in the US where each side pays its own legal bills, regardless of who “wins”).   Furthermore, if a positive judgement is obtained against one party this could obviate the need to sue others as those using similar technology may - to avoid being sued themselves - change their product/technology offerings (and/or seek to obtain a license from the patent holder.)

I guess Apple chose to sue HTC (and no-one else) for a mixture of the reasons mentioned above, with the “strategic” (and indirect) shot across the Google/Android bows being a prominent factor. I’m also sure Apple looked at the ability of potential infringers to “hurt them” (e.g. through reverse patent infringement action) and took the view that – in relative terms – HTC were not well placed to do this (and, as such, were a “good target.”)

One of the principal factors in creating a successful software platform is in maintaining its integrity as it evolves.  As developers submit changes to the code in the main “trunk”, it is critical to ensure that this new version of the platform has not dropped in quality. At the very least, this means the platform must still build from scratch although of course many other techniques can and are also employed.

For LiMo, this is particularly important as any of the fifty-plus Member companies may wish to check out the platform code at any point in time; platform integrity is therefore, a priority.

LiMo’s working model is not centralised but open. Distributed teams are built consisting of representatives from several different LiMo Member companies, both at management and technical levels; for example, the 12 members of the Board, each from a different company, or the five members of the Architectural Steering Committee.  It was natural to use the same approach for this issue of platform integrity.

The http://bondi.omtp.org/1.1/ Approved Release (AR) introduces many improvements over the previous 1.1 Candidate Release (CR).

There has been fairly sweeping changes by the BONDI interfaces group, making most synchronous functions alert(foo()); now asynchronous foo(function(result) { alert(result); }, function(err){ alert(err); });.

The good news is that armed with this 0.5.5.7 release of the BONDISDK, Javascript code completion should point out anything untoward in your javascript code. Helping you migrate smoothly to 1.1AR.

The bad news is that tests and BONDI 1.1AR implementations still need to catch up! For example the SDK’s filesystem emulation has not yet been updated to reflect the changes with filesystem’s resolve.

Rest assured the LiMo sponsored work is underway to update all these changes in BONDI.

This is the question raised for mobile operators. Lately, there has been a drive for mobile operators to offer dedicated devices with de-facto technology. De-facto standards are market driven, resulting from many organizations adopting the use of them. In contrast to this, De-jure standards are formal development standards based on openness and due process.  However, although De-jure standards are open they do not define the use of technology.

There are a number of questions facing the community at present, the main being the concept of differentiation.  Apple’s iPhone is a successful handset without a strong sense of de-facto standards other than the use of iTunes for billing of apps.   On the other hand, we have “collaborative” or “open” organisations such as Symbian Foundation, LiMo Foundation and the Open Handset Alliance, where differentiation is not an easy feat to achieve.

It has now been over two months since Google ended the “will-they-or-won’t-they-release-their-own-phone-despite-previously­-stating-that-they’ll-never-release-a-phone?” debate through the announcement and release of Nexus One. The phone has received many positive reviews, but the negative ramifications of Google’s decision to blatantly work against the grain of the mobile industry are becoming increasingly clear.

With the launch of Nexus One, Google turned the mobile retailing model on its ear by selling a high-end smart phone direct to consumers – without the benefit of a physical storefront. While unlocked phones are nothing new for much of the world, they are typically sold or marketed by the OEM or independent retailer – most certainly not by the platform provider. In one fell swoop Google essentially dis-intermediated the operator and the independent retailer from their consumers. While this strategy clearly made sense to Google strategists, it has posed some practical challenges that have led to disappointing sales results.

Recently, Adobe announced a number of new product releases for mobile devices and consumer electronics devices.   This has led to some confusion amongst developers as to which platform is the right one for them to target.   In this blog, I attempt to give a brief overview of the 4 key platforms for leveraging Flash outside the traditional desktop PC domain.

Flash 10.1

Perhaps the most eagerly awaited release in the mobile industry, Flash 10.1 at long last brings the benefits of desktop flash content to the mobile world.   Flash 10.1 is designed for delivering rich browsing experiences on mid to high end smart devices.  Designed as browser plug-in only (i.e. it must run within a web browser) it enables mobile consumers to have access to exactly the same flash based content as any desktop user.   In addition, Flash 10.1 also comes with support for OpenGLES 2.0 which means that it can take full advantage of the latest developments in hardware acceleration and graphics performance on the latest generation of mobile chipsets.  For example, this means that H.264 video content can now be decoded in hardware, delivering both improved rendering performance and critically reducing power consumption.  Other key features that developers will be keen to exploit include Accelerometer input, which could for example be used to enhance flash based mobile games, screen orientation handling, support for multi-touch and gestures, new commands for pause/resume to conserve battery life when the player is not in use and globalization support for device-specific location information.

Flash Lite 4.0

Flash Lite 4.0 is a natural evolution of Adobe’s platform for more limited mobile devices such as

We’re at an interesting time in technology, particularly in mobile technology. As hardware prices continue to fall and hardware capabilities continue to rise, mobile devices that can run more advanced Operating Systems than the RTOS-style software, which has traditionally powered “feature phones” - the most-sold price point for devices globally - are pushing down into the mainstream more and more.

Phones running LiMo-compliant Platforms, phones running Android, and Apple’s iPhone line, are all proliferating, but as they proliferate they also evolve. At last year’s eComm conference in Amsterdam, one speaker likened the evolution of the communications side of the mobile device ecosystem to the evolution seen in the dinosaurs—and to their eventual extinction. Technologies are born, develop, evolve, and become extinct as their “niches” are taken away by more “fit” technologies.

We’re seeing much the same in mobile devices as well, and we’ll continue to see it over the next several years. In the “Cambrian explosion”, more species of a wider variety of sorts came into existence over the shortest time span ever seen in evolutionary history. Of course, most of those species eventually became extinct or adapted in major ways by the end of this period.

First, device form-factors and capabilities will continue to develop in a dramatic fashion.