Archive for November, 2009

Carnival of the Mobilists #202 at the Mobile Strategy blog

Monday, November 30th, 2009

In its 202th edition, the Carnival of the Mobilists continue strong. This week’s Carnival is hosted at the Mobile Strategy weblog where you will find a number of interesting blog entries from MOpocket, WIP Jam, MSearchGroovem, Mobile Manifesto and About Mobility weblogs.

Also if you haven’t seen last week’s Carnival (#201) visit Burning the Bacon blog.

ceo

Will RIM go the Android Way?

Tuesday, November 24th, 2009

RIM Android

Will RIM adopt Android? A very interesting thought indeed. But why or not would RIM do such a thing? Some thoughts below:

Why this would be unlikely?

  • “Not built here” mentality — this is probably the biggest hurdle for them. There will be internal people resistant to the change, resistant to drastic changes and “throwing away” all legacy work, but sometimes, this must be done;
  • “Why promote a competitor” mentality — this would be a weak argument, due to the “pros” – see below.

Why this would be likely?

  • Deliver more value while reducing overall investments/expenses;
  • Overall reduced Build of Materials (BOM) costs — reduced R&D related to OS; reduce OS team size that instead can focus on value for end-users (apps) and developers. No need to re-invent App Stores. Leverage Google infrastructure (such as Maps which will be an expected feature by end-users) while adding own differentiators on top;
  • Android OS is advanced and customizable, and open — OSes are complicated and expensive handset elements. Android is based on Linux which is stable, which is open, and which is proven. The Android APIs are robust. The whole environment is open. And is community-based. Able to add own differentiators on top;
  • Java-based satisfies current developer base — no new programming languages to learn or adapt to. Tons of tools that already exists, from UI to IDEs;
  • Provides migration path — RIM can decide to continue exposing existing BB Java-based APIs and application life-cycles as needed on top of Android as a migration path;
  • IDE tools already in place — Eclipse is a very good IDE. There is NetBeans too. Both are open and community based and very complete. There would be no need for their own BlackBerry-specific Java-IDE and that t team can instead focus on BlackBerry-specific extensions to Eclipse, NetBeans and/or other – in other words, a much cheaper route to developer tools than developing or maintaining developer tools from the ground up;
  • Business models provided by Google — such as search, Maps, other and provide additional revenue streams for RIM.

As you can see, there are a number of positives for going the Android path; let’s see what will happen.

BTW, the above also applies to Nokia, but let’s see if they end up buying Palm instead…

CEO

MobileMonday Austin Event – December 7 ‘09 – Technology Incubators, Funding Sources and Demos

Friday, November 20th, 2009

MobileMonday Austin

Mark your calendars! The next MobileMonday Austin event is scheduled for December 7, 2009, 5:30-8pm.

For this event we will have a number of Central Texas Technology Incubators come in and talk about what and how they help local mobile developers and start-ups. We will also have a local Angel investor present on “Funding Sources”. And we will have some local companies demo their mobile products. It is going to be a very interesting and informative event!


When: December 7, 2009, 5:30 – 8:00pm

Topic: Central Texas Technology Incubators, Funding Sources and Mobile Apps Demo Night

Agenda:

Where: West Pickle Research Building, The Alamo room — see http://bit.ly/4Va4MW

Cost: Free. Pizza and sodas will be served.

Space is limited! To have an accurate headcount, please register by *adding your name* to the “December 7th Event page” at: http://groups.google.com/group/momoaustin/web/mobilemonday-austin-event-december-7-2009

If you are a startup or developer who would like to demo your applications, please send me an email to enrique dot ortiz at gmail dot com.

Thanks to our sponsor, the Austin Wireless Alliance! And to our Speakers!!!

ceo
@eortiz
@momoaustin

OMTP BONDI 1.1 Candidate Release — Open to public for review/feedback

Wednesday, November 18th, 2009

BONDI 1.1 is now in Candidate Release and it is open to public for feedback.

Note that this phase will close on the 2nd of December so you’ll need to get your comments in before then.

See OMTP and BONDI at the betavine website.


What is BONDI?

In short BONDI is a set of specifications, reference implementation and compliance criteria for the creation of mobile web apps based on Widgets.

This means that BONDI widgets rely on the web-runtimes or browser as its execution environment. BONDI defines a set of APIs that provides BONDI widgets with access to the handset functionality such as access to camera, contacts and location information.

The BONDI official website contains all the information you need to learn more.

From the BONDI website:

During 2007 and 2008, it became increasingly apparent that the future direction and success of the mobile web could be harmed without a concerted effort to drive a standardized approach to how web applications access the key local capabilities on the mobile device.

If web applications had to use different APIs (for the same capability) on different devices and platforms, then development of web applications which work on any mobile device would not happen. On top of this, the risk of malicious web applications having free access to local mobile capabilities is unacceptable. Therefore, a need to create some form of security layer to protect the user from harm was essential.

It is with this background that OMTP launched its BONDI project with the aim of acting as a catalyst to drive the standardization of a small set of key interfaces from web services to mobile devices and also to put in place a well understood and user controlled security policy with which to protect the user.

BONDI consists of several activities, each of which interacts and as a whole builds towards the aim defined above.

Interface Requirements — A high level definition of the BONDI interfaces which include a dynamic API which is remotely updateable once the device is in the field

Security and Architecture requirements — Requirements for BONDI architectural constraints and for the security policy which protects the user from harm

API specifications — A set of Doxygen generated HTML pages that define the syntax and semantics of the BONDI APIs

Security Policy DTD — An interoperable XML description of the security policy which defines the access that a particular web application and widget will have to the BONDI APIs.

Reference Implementation (RI) — The RI is a real concrete example (using Windows Mobile as the platform) of how the interfaces and security specifications should be implemented. The RI SDK contains API documentation and example code.

Compliance Criteria — A set of criteria which may be used to judge compliance of implementation against the defined standard and RI.

The BONDI Reference Implementation has been created as an Open Source project. This enables both OMTP Members and Participants as well as non members to collaborate on the creation of a rapidly iterating and testable implementation in a public arena. The use of real code in a RI ensures that other implementations for different devices and platforms can be tested and declared compliant against well defined criteria.

ceo

Near-Field (Proximity) Communication in late 2009

Tuesday, November 17th, 2009

It almost is the end of 2009. And where does near-field proximity communication-based applications stand? From mobile marketing, to customer loyalty, payments and authentication, to information exchange, transportation and health-care. Well, it still stands very far from its full potential.

Due to its characteristics, proximity is an excellent class of physical interaction. And inherently a very special class of interaction. It can be very personal, in theory secure, and it can be very localized — all excellent attributes for interactions that provide secure context.

Regardless of its potential and benefits to consumers (which is about convenience) and the real business models that exist, NFC have had major adoption (growing) pains. Pilots have said again and again that consumers do like the convenience, but it is the enablement problem what has basically prevented its adoption. It took Bluetooth more than 10 years and it will take NFC the same.

If we wanted to deliver the convenience benefits of proximity-interactions today, what is the answer? Will it be RFID or NFC the one that stands up at the end? Will it be embedded chip-sets, USB or microSD, or plain RFID stickers?

While not the perfect vision the NFC Forum members had, sticker (RFID) are the short-term solution for this today. Some call it an interim solution, but we will see.

From Blaze Mobile (to whom I provided my services to back when they were called MobileCandyDish), to Giesecke & Devrient, Alcatel-Lucent (my current employer), Oberthur Technologies, MasterCard, First Data, and Tetherball, they all are dealing with the realities of NFC and while waiting for it have decided to follow the “RFID sticker” route. Blaze Mobile was one of the first one years ago.

Stickers. But RFID stickers are very limiting as they are limited to “one function”. How many stickers can you fit, or want to fit, on the back of your phone? Yet stickers bring NFC close to reality. Expect branded and colorful RFID stickers of all kinds.

When I saw ViVOTech (a leader on NFC and contactless in general) recently announce their ViVOtag product; in other words, even ViVOtech has submitted to the realities of NFC, I said to myself, “NFC is dead, long live NFC” – this time is the sticker way. Yuck. See ViVOtech Launches ViVOtag.

There are other vendors going the route of USB or microSD NFC devices such as Tyfone, Giesecke & Devrient and DeviceFidelity. Another example is Sony — see Sony’s next generation Memory Stick which might potentially be integrated with NFC.

In the meantime Gemalto Boosts Rollout of SIM-Based Mobile Contactless Services and touchatag, an Alcatel-Lucent venture and Clear2Pay partner on technology for contactless payments.

And as I wrote before, Will the iPhone trigger the Mobile RFID/NFC revolution?

So there is lots of interest, noise and activity related to mobile NFC/RFID. It is a matter of time, I’m convinced. But the ideal solution is NOT stickers, yet stickers are the fastest and cheaper way to get there, and because of that, the best way to validate the applications and models. And once that happens, I hope that for the sake of the consumers themselves that we move on to a solution that allows for MULTIPLE applications such as smart-cards or handset-based (which includes USB or microSD-based) approaches.

For a good paper on alternative NFC form factors see white-paper by The Human Chain titled Alternative NFC form factors.

Now, last but probably the top deployment reason why proximity interactions based on NFC/RFID are extremely important: to work around that pesky patent on barcode interactions (i.e. nn-ee-oo-mm-ee-dd-ii-aa); with the NFC/RFID path there is clear and well documented (including in the NFC standards) prior-art.

It is time for operators and device manufacturers to push for NFC. Yes, enabling NFC require investment but pilots already provided good results. Go sticker in the interim to validate, and remember that it is about the applications and usability. No need to wait on Apple, again, to define the path. (The exception to all this is Nokia who has been forward looking since day one, with the handsets, APIs, documentation and toolkit to make this happen.)

ceo

Will the iPhone trigger the Mobile RFID/NFC revolution?

Friday, November 13th, 2009

Will history repeat itself?

There was/is the 12 keys keypad cellphone.
And few care about Touch.
Then came the iPhone.
Now everyone loves Touch.

There was the operator Deck.
Everyone hated the Deck.
Then came Apple.
And created the App Store.
Now everyone loves the App Stores.
And everyone still hates the Deck.

There was RFID. Then came NFC.
With clear use-cases and business-models.
Yet it has taken forever to deploy this.
Pilots and more pilots, when it is going to end?
Embedded chip-sets or stickers.
But few seem get it. (Nokia does!)
Who is going to take the first big step?
Operators don’t get it. Or do they?
And stuck with pilots they are.
“Hey, this is great!”, the pilots say.
Enablement is expensive! That is what they say.
But guess what?
Proximity support, the iPhone will have.
And all of the sudden, “RFID/NFC on the go” everyone will want.

And I say, if the iPhone introduces support for proximity, it will trigger the mobile RFID/NFC revolution… Wanna bet?

Here, some rumors via the NFC World Blog:

NFC specialist Narian Technologies and who runs the Near Field Communications Group on Linkedin.com, has reported the following:

Had to share this news. A highly reliable source has informed me that Apple has built some prototypes of the next gen iPhone with an RFID reader built in and they have seen it in action. So its not full NFC but its a start for real service discovery and I’m told that the reaction was very positive that we can expect this in the next gen iPhone.

If Apple does it, expect every phone manufacturer and their sister to begin pumping out NFC enabled phones, at least for service discovery and sync.

This just reinforces what we knew based on the two separate patents Apple submitted that had the iPhone enabled to read RFID tags. I’m told that the touch project video and the BT SIG’s specs were all driving forces to push this forward as well as other factors.

Guess I’ll be touching my iPhone to my Mac to link them together to sync iTunes by next year.

On-bill App Store Purchases – finally, an operator leveraging their own infrastructure in new ways, on the new era of app stores

Thursday, November 5th, 2009

Operators have so much infrastructure already in place and it has taken them so many years to take advantage of it in news ways — to leverage such infrastructure for their own benefit and the benefit of the ecosystem, by repackaging and offering this infrastructure as “open” Services: their payment system, their marketing/reach methods, their customer support systems and other…

Recently T-Mobile announced (PC World) that they will start support for on-bill Android App Market purchases; up to this point the only way to buy applications on the Google App Market has been via Google Checkout.

“T-Mobile will let its subscribers pay for Android applications on their monthly mobile bills starting Nov. 17, also introducing its own section of the Android Marketplace that day.”

These news though, I’m surprised, haven’t made much noise within the developer community yet. This announcement is VERY interesting and important. A number of us, including William Volk (Extremepreneur blog) have been advocating this as an important approach to help simplify the app store application purchase (and/or purchase decision) and as a way to better ‘compete’ with Apple who already have a robust, established, recognized and independent (from operators) billing/payment framework.

For developers, this on-bill purchase/payment support means (in theory) that because the process of buying apps is becoming simpler for subscribers (no registration required, one-click buy) the resistance to buy applications should be less than before, and thus we should see an increase on the number of apps being purchased on Android and thus the Android platform should be more attractive to target since again, in theory, the ROI for it should also increase as a result of the introduced app purchase simplicity.

“Brodman characterized T-Mobile’s billing system as a simple, “one-click” purchase method that doesn’t require the user to give credit-card information or personal credentials. So far, Android users generally have had to use Google Checkout to pay for applications, but Google has said it wants a variety of payment choices for the market.”

Is the fact that there hasn’t been much (positive or negative) reaction to this announcement an indication that on-bill purchases don’t matter? Perhaps it is an indication that this is just a no-brainer and was just expected. Time will tell.

Related to this see The Google App Market – An Analysis (About Mobility).

T-Mobile has taken the first step into this combined billing approach to app stores. This will set a precedence that will not favor Apple. Little by little and over the years, slowly but surely, operators have been understanding (or forced to understand) and have been learning and adapting. This is the only way operators will regain their position and be recognized within the ecosystem in ways that allows then to compete with companies such as Apple and Google — by themselves becoming part of the ecosystem in positive ways. It will take them years still, but they are learning. We have seen the mobile/wireless industry transforming from 1) being operator-centered, 2) to recently becoming ecosystem-centered where the developer community and users and open systems are at the center and where the operator is not viewed as a positive contributor or partner. But if operators adapt well (and time is of essence for them) we will see 3) an ecosystem where the operator becomes a very important ecosystem partner, which is anyways what they always have wanted, to offer services and be recognized beyond a pure pipe.

Apple has iTunes, Google has Checkout and the Operators have a proven robust billing/payment infrastructure (and other infrastructure) already in place for years that now they can extend to app stores. Let’s see if they will take advantage of this new opportunity and let’s see how this will play out.

In conclusion, T-Mobile’s on-bill support will be a great experiment that will help determine if this converged or combined billing/payment approach will be a positive influence on people’s decision to buy mobile applications. Logic dictates that it should…

ceo