Image courtesy of WaveMarket
US mobile operator, Sprint recently announced a couple of new ways for third party developers to create location aware applications and mobile web services. What Sprint has done is to partner with two companies, WaveMarket and uLocate’s Where.com, who both act as intermediaries between Sprint and content providers. Developers and publishers no longer have to partner with Sprint in order to get access to location data. WaveMarket and uLocate will handle the entire relationship including serving the location data and managing the associated privacy requirements.
I spoke with WaveMarket VP Joel Grossman yesterday about the company, the Sprint deal and what it means for off-portal mobile web publishers and third party application developers. WaveMarket, which was founded in 2001, developed Sprint’s Family Locator and similar services for Alltel and Canada’s Bell Mobility. Using the infrastructure and privacy management features behind the Family Locator, WaveMarket has created a new platform called Veriplace that provides an API which can be used by off-portal mobile web sites and downloadable applications to create location aware services.
The way Veriplace works at a high level is:
- A web service or application makes a request for the user’s location using the Veriplace API. The request is signed with the application’s encrypted key identifying the source of the request.
- Once the requester is verified, WaveMarket interacts with the user to obtain permission to share their location with the particular service making the request (image above).
- If the user grants permission, their location is returned to the requester. Location can come from a variety of sources including AGPS, cell tower triangulation or tower IDs.
The actual process is fairly complex with about ten steps to the workflow, but doesn’t appear to be particularly difficult to implement. I particularly like that Veriplace is using the open standard OAuth for it’s secure keys which means no cost to developers for the keys.
Veriplace is currently in pre-release mode. The API documentation and SDK can be downloaded now from developer.wavemarket.com. Potential developers can sign up on the same site to access WaveMarket’s sandbox server to test their applications. Veriplace is expected to go live on Sprint early next year with several other operator deals in the works.
Pricing is the big question mark for Veriplace. For it to achieve wide adoption the cost to developers has to be low enough to be covered by advertising revenue or subscription fees. Traditionally mobile operators have valued location data rather highly, charging several cents per location fix delivered. That sort of pricing pretty much rules out the ad supported model as mobile ad revenue is typically measured in fractions of a cent per impression. Veriplace pricing hasn’t been finalized but Joel indicated that it will be on a pay per request basis and will be affordable, particularly for subscription services. Pricing would be tied to precision as well, with lower accuracy positioning data being priced considerably lower. Services would be able to offer location based advertising – which should be chargeable at higher cost per click or impression than non-localized advertising.
I’m cautiously optimistic about Veriplace. It promises to greatly streamline the process of getting location data from mobile providers, which is currently a very time consuming and expensive process. WaveMarket will completely handle the relationship including the testing and certification of location aware web services and applications. WaveMarket is even able to sign downloadable applications with the elusive Sprint operator domain certificates, which are required for location access on Sprint’s feature phones. This means that it will finally be possible for 3rd party developers to offer location aware applications off-portal and without partnering with Sprint.
Wow, this could be big, first broad scale initiative that could bring location info to the mobile Web! Hopefully other carriers will follow suit, and all adopt a standard API … one can dream anyway :-)