Tag Archives: payment

Mobility 2011: The Year of NFC

Posted on by

(This is part of a series of blog posts on Mobility in 2011)

Near-field Communications (NFC), the very short-range secure communications channel that will enable for a new breed of application interactions, is making a comeback. The year 2011 is, finally, the year of NFC. Today NFC is the new buzzword. NFC is the “next big thing”.

What makes NFC so attractive? From a user’s perspective, convenience. From a developer perspective, imagine application activation by swiping the handset.

NFC is so hot now, that the NFC Forum, the non-profit industry association that promotes the use of NFC short-range wireless interaction in consumer electronics, mobile devices and PCs and leads the standardization of NFC, recently redesigned its logo and marketing efforts.

Introduced around the year 2006, for some of us, it has been an eternity to get here. For example, back in 2007-2009 I co-founded a company called eZee, with the goal of bringing NFC-based applications and mobile payment into the marketplace; see eZee inc Mobile Coupon and Payment Vision. If you ask me, right on the spot, but 3 years too early. ;-)

And as with mobile apps, NFC suffered from the same preclusion by the Operator. The pain was so heavy that many investors avoided NFC-related startups altogether. Those were the days just pre-iPhone and pre-Android. Nokia was the leader on NFC; it pushed the NFC API into J2ME (JSR-257), was doing its best to expand NFC. In the USA it was next to impossible to get your hands on a NFC handset; Operators were not ordering them, not yet, until the issue of the Secure Element was resolved. With trials and more trials, operators basically brought to a halt all related innovation and ecosystem. Note that near-field communications already had been proven in other regions such as Japan. Convenience the obvious benefit – fast, quick interactions.

Now with Google introducing NFC on its Android software stack and device manufacturers embracing Android/NFC, and (rumors that) Apple will be introducing support for NFC, and organizations such as ISIS (a joint venture by AT&T, T-Mobile and Verizon), and in Europe with projects such as the “Six Pack” with operators and financial institutions involved, the right mix of players and events are happening. The NFC ecosystem is evolving!

2011 will be a definite year on the battle between operator control and the ecosystem. This should look familiar to you as it is similar to how apps moved from the Operator controlled deck and into the ecosystem, 3rd party developers and app stores and markets. Operators have a true challenge ahead of them. It actually is an amazing transformation across the board.

While many equate NFC with mobile payments, payments is just one application. Other types of applications for NFC include check-ins, digital-to-physical world interactions, sharing device-to-device (such as contacts), authentication/authorization, transportation and ticketing, discovering information about a place or object, coupons and marketing, and so on. In fact, perhaps over time, most of the NFC-based interactions won’t be payment related.

Next I will expand on NFC, the players and the year 2011.

The NFC Ecosystem

The NFC ecosystem is a complex one. And when involving mobile payments it is not only complex, but it is extremely (greedy) political. Below I attempt to illustrate some of its players:

Past experiences alone tell me that the control of the NFC ecosystem, led by mobile payments, will shift from the Operator (and the SIM card) and into the ecosystem via non-operator and external secure elements and Trusted Service Managers (TSM).

The NFC Specifications and Standards

The NFC specifications focus on link-level protocols and message payloads to enable NFC-application proliferation. The specifications describe NFC at the low-level such as Logical Link Control (LLC) protocol and connection handover, data exchange formats, support for various popular Tags such as FeliCa, and communication protocol formats for various interaction types such as support for Texting, URI and Smart Poster payloads. All the required protocols are there. The NFC software stacks are there. But the SIM-card centered mobile payment debate continues.

The SIM-Card vs. External Secure Elements Debate (or Debacle)

While NFC has uses beyond payments, the debate of who controls that Secure Element (SE), a mobile payment artifact, is the top reason why NFC adoption has taken forever. For those not familiar with SEs, a SE is a secure location in the device, typically a Smartcard, where things such as secure keys are stored and which must be very difficult to compromise.

Many believe the SIM card, which already plays a key role on handsets by identifying the subscriber and related account, should be the SE of choice for mobile payment. At first, this makes sense as from the technical perspective, the SIM card is very secure, it has a secure channel between the SIM card and the NFC chip over Single Wire Protocol (SWP), and the Over-the-Air (OTA) management aspects are in place. But from the business perspective, there is a huge drawback — it gives way too much control to a single stakeholder, the operator.

The truth is that SEs can be implemented in various ways: 1) the SIM card, as explained above, 2) secure internal memory, and 3) external SEs such as in a microSD. The latter is becoming a strong contender for NFC.

The debate of SIM-cards vs. external SEs will have a major implication on who will benefit the most. If it turns out that the SIM card is in fact the top choice for SE, then a new/different kind of battle for SIM control will commence.

While the above takes place, two technologies are filling the gap: 1) 2D barcodes and 2) RFID stickers:

  • 2D barcodes have great potential and uses; I love them. But are not as convenient as NFC, as it requires multiple clicks from the user to start the app and read the barcode itself;
  • RFID stickers I see as a temporary solution. RFID stickers can be provisioned with info such as account information, and may require multiple stickers for multiple purposes. RFID stickers are “standalone”; with no application interface on the handset itself, the sticker is very static. This is opposed to NFC-based apps, which have an application component, a component on the SE, and the application can interface with the NFC channel and the SE, allowing you to create any UI experience (differentiation) on top.

Apple & Google and Financial Institutions Take the Lead

Enough trials. Enough debates on SEs. Time to move on. And this “move on” means for the ecosystem to take lead. Enter Apple and Google, and financial institutions. The Operators should be very concerned. The whole app scenario is repeating, that is, control shifting from the operator and into the ecosystem.

And it gets better.

Not only Apple and Google have/will be introducing devices (and sofware) that supports NFC, but expect them to become major players on NFC-based payments. Providing NFC hardware and software support is just part of the story. Expect Apple and Google to position themselves right in the middle of this; in the middle of each mobile payment transaction. But how? There are different ways, with different levels of control and influence:

  • One way is to position their own “Checkout” application and back-end system at the center of each payment transaction and getting a percentage for each;
  • Another way is to position themselves as a financial institution;
  • And the third way, is to become a Trusted Service Manager (TSM).

I suspect that Apple will supply their own mobile payment app (#1 above), but also become a TSM (#3). Google probably will use a different angle, one focus on their Search, Places and Recommendations, Ads and Hotpot, combined with their own Checkout payment app; we will see, but they should also consider the TSM route.

Similar to Google and Apple, financial institutions will take lead on NFC and mobile payments by providing mobile payment apps and potentially also taking the TSM route. Most likely financial institutions will go the microSD route:


Source: Nearfield Communication World

This is similar to how Visa Europe last year used a microSD-based NFC solution for mobile payments based on DeviceFidelity‘s In2Pay. Expect more of this happening.

What is a TSM?

A Trusted Service Manager or TSM is the entity that manages the process of provisioning a device (Secure Element) for mobile payment. Gemalto defines a TSM as follows:

“In mobile payment, the Trusted Service Manager (TSM) works behind the scenes to make the entire process of downloading your payment account onto your cell phone efficient and secure. Mobile commerce and payment necessitates a new level of cooperation between wireless operators and financial institutions. A TSM knows both banking and mobile phone security and systems, bridging multiple banks and operators while ensuring that consumer credit card information is completely secure. ” – source Gemalto.

The diagram below provides a simplified view of a TSM; as you can see, TSM are at the center to the whole mobile payment process.

TSMs are basically right in the middle; provisioning payment applets (on the SE and/or SIM card), payment apps, and the secure keys. TSMs can mainly focus on the provisioning aspects, or can offer additional services such as communicating with financial institutions over secure channels for payment processing related tasks, with the device, and with the network.

For Apple and Google, and perhaps the financial institutions, this could mean “TSM on-demand” with user-initiated provisioning via their respective app store/markets and tools; imagine using iTunes to securely setup your iPhone for payment, downloading the secure keys, apps and applets, all integrated into one experience.

Note that becoming a TSM doesn’t preclude others’ apps (and related secure keys) on the same SE, meaning that if Apple or Google, or the operator for that matter, decided to become a TSM, they can be ecosystem-friendly.

You might recall in 2010 a deal between Apple and Gemalto. This rumor was centered on Gemalto-provided SIM cards to enable iPhones to be activated on any operator via an App Store download. While this might be true, this deal felt to me like something else; I will not be surprised if perhaps Apple is planning on using Gemalto’s Trusted Service Manager (TSM) technology to help Apple become a TSM for mobile payments on iPhone.

Will companies like Apple, Google and financial institutions collaborate with ISIS and the like?

ISIS

It is not the first time we have seen a conglomeration of operators that gets together to address NFC and mobile payments. Just a few years ago at Mobile World Congress, a number of operators joined forces on mobile payment. Nothing came out of this.

In 2010, ISIS, a mCommerce joint venture by AT&T, T-Mobile and Verizon in the USA was formed. This is a natural response to the threat by 3rd party companies such as Apple and Google trying to take over mobile payments. I do expect for ISIS to succeed somehow, but to be determined how this in fact will play out.

Note that ISIS is an all operator venture, and the “Six Pack” project in Europe does consist of operators and financial institutions together. Operators have the upper hand, but we live in a new world of mobile ecosystems; it is imperative they work with the ecosystem.

In Conclusion

The year 2011 will (should) be the year of NFC. But it is just the beginning. It really is about preparing for the decade of mobile payments and contactless interactions. Imagine using your handsets to learn about items on the store or places via NFC, exchange your contact info with others, check-in into places, redeem your coupon, and/or make payments, just by swiping your mobile handset.

NFC brings a new kind of interaction — it is about convenience. For me, I’ve been waiting for this for a long time and it is very exciting due to the new kind of apps that will come out of this.

You can read more about NFC, including the JSR-257 Contacless APIs for JavaME, in the NFC section on my blog About Mobility.

Related previous blog posts:

Other:

ceo

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

Posted on by

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

The Google App Market – An Analysis

Posted on by

I’ve written a quick analysis on the Google App Market situation… Looking forward to your feedback/opinions!

You can download this article in PDF format. Download The Google App Market – An Analysis (PDF).

The Google App Market – An Analysis

September 6, 2009 | © 2009 C. Enrique Ortiz — http://CEnriqueOrtiz.com

This article is about App Stores/Markets. It is a personal view on the Google App Market and thus it is totally unscientific. It focuses on Google App Market but it applies to all app stores. In this article “App Market” and “App Store” are used interchangeably and refer to the application catalog on the Web that allows for the discovery, payment and download of mobile applications.

There are like four ten thousand applications on the Android Market while the iPhone App Store has many, MANY times that. Everyone knows that the Google App Market is not doing as great as the iPhone App Store. Even when trying to compare oranges-to-oranges, this is, for example, the number of apps and apps-downloaded and paid-for on a given/same period of time or the same age-period of the store themselves, for some reason the iPhone has clearly done a much better job.

It is a very interesting problem. There are so many variables involved in this problem, starting with the human-factor variable, that makes this nut so hard to crack. Bring on the human-factors experts! Bring the designers and engineers. And let’s not forget the marketers! This problem is way beyond pure engineering — I’ve always said that the iPhone was created by designers and marketers and engineers, while the Android was made by engineers.

Why such big differences between both stores?

  • Are iPhone users really unique/different?
  • Are Android apps “sucky” or are Android users cheap?
  • Are the reported store/market numbers skewed?
  • Does it have to do with “critical mass”?
  • Or is it all due to user-experience — the experience finding, buying and downloading applications?

Perhaps it is all the above. But before I take a stab to the above questions, let me talk about a higher-level view to this problem. To be successful, App store/markets must be built on top of a number of foundation steps as illustrated next.

Figure 1 – Basic Ladder for App Market/Store Success

…where:

  • At the bottom of the ladder as first step is critical mass, as without critical mass there is insufficient effect to realize a long-tail effect. Handset positioning, marketing, pricing, region, all have part on critical mass adoption.
  • The next step up the ladder is user-experience, which perhaps is one of the most difficult steps to get right and is covered in more detailed later in this article.
  • The top step on our ladder is the ecosystem and quality applications as without these there is no app store/markets.

The above foundation steps are critical to the success of app stores/markets. Next let me go back to the questions above and how they relate to this Basic Ladder.

iPhone users have proven to be a unique/different bunch. They are more consumer-oriented than Android and even BlackBerry users. For some reason those users do get applications. Perhaps thanks to marketers (TV commercials | “There is an app for that”) iPhone users see applications as “things that solves specific problems”. The iPhone has critical mass, but BlackBerry has critical mass as well; the BlackBerry store should be a great tester of the theories written in this article (once they implement the two top steps of the Basic Ladder above). Yes, critical mass is one of the foundations for success. As a side-note, while the iPhone has an attractive critical mass, it is not as attractive in all countries due to cultural preferences/differences. Device manufacturers must understand and find what creates critical mass for their own products on specific regions.

Today Android apps are less sophisticated when compared to iPhone applications. On the iPhone it is expected that applications are somewhat sexy/eye-candy. This helps with application quality perception. Applications must just work well and be useful. Good quality apps is another foundation for success. In theory and over time, Android apps should become sexier as well. Should there be an approval process that enforces a minimum user-experience and eye-candy for Andorid apps? Hmm that is a tough one, and doing so go against the idea of a true open platform.

Android users are cheap; Android users don’t buy as many applications as iPhone users do! Maybe this has to do with demographics. Based on observation the majority of Android users are the techies-type who prefer free stuff and who are not willing to pay for applications that aren’t great. But the demographics for Android users will soon shift with the plethora of devices coming from emerging markets and other. (For the record, I’m an Android user)

While we always have to be careful when interpreting industry metrics, as collected numbers, by definition, are and alway be *relative* to a particular set of conditions and data set, existing metrics/numbers do show that there is not enough critical mass (a foundation for success) for Android at this moment. I expect numbers to shift in favor for Android as mentioned above. And the top reason I believe this will be the case is economics — more and more device manufacturers will introduce Android devices because using Android reduces their initial investment and maintenance costs (due to reduced Build of Materials) when introducing a new mobile handset. As you know software and especially Operating System software is a very complex piece and it is very expensive to build and maintain and it is just logical that manufactureres will take advantage of all the research and development already done by Google and that is available for “free” or “at no cost” to them.

And what about the user experience? The user experience, another foundation for success, can definitely be improved on the Android Market. The current experience is not terrible, but it is not helping maximize the transactional opportunity. Towards this goal of improving the user experience Google has been working on a new version (v1.6) of the App Market application which includes a number of improvements including screenshots and more descriptions and new categories — see Some News from Android Market (Google Android Developers Blog) including a short video of the new client.

While I’ve no insight (beyond the above) on what Google will be improving on the Android Market, they must take into consideration a number of additional things, including improving the user experience beyond the on-device client and helping the Search function a bit more.

On User-Experience

User-experience can enhance and promote usage, or discourage it. If the (app store/market) is too hard to use, or if it is too hard to find apps, then people won’t use it. And as the number of applications increases, better ways to find applications must exist.

Recently AdMob reported (PDF – AdMob Metrics July ’09) that over 90% of users in their study reported that most of the application discovery efforts are done on-device instead of their computers. Below are other insights from the AdMob report:

  • The most-cited ways of discovering apps are browsing the Android Market/App Store Rankings and searching for a specific type of app. Over 90% of users who cite these activities do them on their mobile device instead of their computer.
  • Android, iPhone and iPod touch users are all highly engaged with apps. Android and iPhone users download 9-10 new apps per month, while iPod touch users download 18. Over half of Android and iPhone users spend more than 30 minutes per day using apps.
  • iPhone and iPod touch users are more likely to regularly purchase paid apps than Android users. 19% of Android users download at least 1 paid app per month, compared to 50% of iPhone users and 40% of iPod touch users. However, of those users who regularly purchase paid apps, downloading behavior is similar across platforms.
  • Requests from the Android Operating System increased 53% month over month. Android has 7% worldwide OS share.

The above goes back to better ways to discover, buy and download applications is key. I do believe though, that a web-based companion will also improve overall Google App Market performance.

Search is good, but even Search needs some help. And this help is about filters, good filters. Imagine the right filters, including self-organizing ones. With the proper Search and Filters we have the first step towards improving the app store user experience. The other two steps are related to buying and download.

While search by categories, “featured apps” and popularity is important, quickly filtering by “free vs. paid” and “new vs. old” is probably even more so. And to maximize the usefulness of the filters and maximize the transacttional opportunity (minimize incorrect bias) the filters must all be visible and accessible just “one click away”. Let’s take a stab at a potential UI design for such an application discovery application:

Figure 2 – Potential Enhanced UI Design for App Store Client

Note the emphasis on filters by categories; here categories aren’t fixed and will adjust based on historical usage, or preferences. This is important as my favorite categories not necessarily are your favorite ones, and once categories are fixed it translates to exclusion; indiscriminate exclusion is not a good thing. Note the “free vs. paid” and the “new vs. old apps”; the latter should be familiar to Google Reader users. Other useful filters are the ones found on the iPhone App Store client such as “featured” and “Top 25″. But again, it is very important that search and filters are ALL visible and also are “one click away”.

A complete discovery solution must not only be on-device but must have a desktop companion. Apple has iTunes. Google has the Android Market, but it is incomplete in my opinion. See the areas in red below: few filters, incomplete applications catalog, and no push-to-handset method, just to mention the obvious limitations.

(Part of the discovery — the App Market/Store shall also only show the applications that works on the user’s device — here works means resolutions, platform version compatibility and other).

Figure 3 – Current Android Market is Unnecessarily Limited

The enhanced web-based “desktop” market (companion to the on-device market client) shall provide the complete catalog of applications, provide and maintain download and purchase histories, but also must allow for the ability to initiate the download (push) of the application to the handset over-the-air (OTA). In other words, a user should be able to use their browser on their desktop/laptop and go to the Android Market, discover, buy and push applications to their Android handset. This market user interface shall provide all the same search functionality/filters as the on-device discovery UI illustrated above.

Once The App is Discover, what is Next?

Once the application has been found, it is about learning more about the application: here things like screenshots, ratings, descriptions are all important. And the upcoming version of Google App Market client v1.6 will try to improve on all of those areas. What about the ability to share the application? Yes, very important! Google must add such facility (i.e. “Tell a Friend”) as well.

The following illustrates the App Market/Store Cycle and Support Triangle that shows the three main phases a user goes through when interacting with an App store/market including some important characteristics for App Market/Store success.

Figure 4 – App Market/Store Cycle and Support Triangle

You should be able to extrapolate from the above app discovery, payment and downloads diagram and about the transitions in between them.

Last I would like to mention the importance for a super simple payment system. In the past I’ve written about “integrated payment with the operator” approach which should be a very simple approach for users (this of course would only apply to operator-subscribers scenario). Another solution to this is the App Market/Store PC (web) companion that I mentioned above that would allow a user to not only discover and buy applications, maintain existing download and purchase histories, but also easily setup and maintain account and payment histories; for Google this would be Google Checkout in the back-end.

In Conclusion

App Stores are little strange, difficult entities. At this moment it seems that Apple has gotten it right, but not the others yet (others are RIM, Google, Palm, Microsoft). App Market/Store success is dependent on a number of different moving parts, including the most difficult one of all: human-factors. It takes designers, engineers, marketers and human-factor experts to get it right. And it is important to get it right, as the future of the mobile handset useful relies on software and applications, and software and applications are the bread and butter of the developer community, you and me — the Ecosystem.

ceo

V1.5 | September 6, 2009 | © 2009 C. Enrique Ortiz — http://CEnriqueOrtiz.com