Free beta access to location-based fraud monitoring and alert service

0
Posted by jfinkelstein on August 30, 2010 – 12:31 pm
Filed under Market Observations, Partner Communications, Universal Location API

finsphere logo

A few months ago, I predicted we’d see some exciting new services that use the location of mobile phones in novel ways. Well, check this out…

Location Labs is proud to highlight the beta launch of Finsphere’s PinPoint service.  PinPoint is a subscription-based fraud monitoring and alert service that uses Location Labs’ Universal Location Service to access cross-carrier network-sourced location of mobile phones.  PinPoint monitors all of the user’s card-based transactions, and sends email and text alerts on potentially fraudulent transactions based on a number of factors, one of which is the consumer’s physical location as indicated by the location of their mobile phone.

If you want to test the service free of charge enter “LocLab” in the Promotional Code box on the signup page.

We’re looking forward to seeing more exciting announcements from our partners at Finsphere in the near future!

@locationjason

Location Labs Selected By Inc. 500

0
Posted by admin on August 24, 2010 – 6:58 pm
Filed under General & Administrative

2010 RANKING

#458 Location Labs
www.location-labs.com
Emeryville, CA

Location Labs’s business model

Location Labs (formerly WaveMarket) provides advanced location-based technologies’scalable and secure software platforms that allow third-party developers to build applications and services that can remotely locate more than 150 million devices across Tier 1 carrier networks. This enables users to share their mobile phones’ location with sites and services such as Facebook. Location Labs’ customers include AT&T, Sprint Nextel, and T-Mobile USA

http://www.inc.com/inc5000/profile/location-labs

RWW guest post from Location Labs CEO

0
Posted by jfinkelstein on August 15, 2010 – 1:01 pm
Filed under Geofencing SDK, Market Observations, Partner Communications

Check out a recent guest post in Read Write Web from our CEO @tassor where he discusses the many different kinds of geofences:

Geofencing: What’s Next For Location-Based Services?

For those coming up to speed on LBS, especially geofencing, this article provides a great education covering everything from pure, static place-based geofences to dynamic geofences that continuously shift to peer-to-peer geofences.   Not to mention, there’s a great video embedded in the article which offers a very concise explanation of the various types of geofencing.

Let us know what you think.  Enjoy!

@locationjason

GeoLoco 2010

0
Posted by jfinkelstein on July 19, 2010 – 9:12 pm
Filed under Events

The Location Labs team will be at GeoLoco this week in San Francisco.  Akash Agarwal, our SVP of Corporate Development, will be on a panel discussing Location & Privacy beginning at 1pm.

We look forward to meeting developers, journalists, and other interested parties.  Look for Jon, Akash, or Kedar. We hope to see you there!

Location Labs Geofence Library for iPhone

12
Posted by sahotes on June 23, 2010 – 1:26 pm
Filed under APIs, Tools & SDKs, Geo Intelligence, Geodata, Geofencing SDK, Location-as-a-Service, Universal Location API

On Monday Location Labs announced the initial release of our Geofence Library for the iPhone platform in private beta.  In many ways we believe this solution will set the standard both for how geofencing services are provided on the iPhone and other smartphone platforms, and more generally how location data streams will be derived from the mobile device.

Wikipedia defines a geofence as a “virtual perimeter for a real-world geographic area”.  In the mobile context, when a mobile device enters or exits the geographic area, the relevant caller (typically a mobile-resident or network-based application) is notified.  Sounds simple enough, but of course the devil is in the details.

There are two key factors that complicate the implementation of a geofence solution in a mobile context.  The first is location technology.  Deriving location from a mobile device is not a new problem, dating back at least to the FCC E911 mandate, and as it turns out there is no single one-size-fits-all solution to this problem.  As with many important engineering problems, there are trade-offs.  The second, and related factor is battery consumption.  For example, GPS, an important enabling technology for mobile location, is a battery hog, typically drawing 300-350 mA on a modern smartphone device (as reference, typical smartphone batteries have a capacity in the 1,200-1,500 mA hour range.)

On Monday, Apple released its latest version of the iPhone operating system, iOS4.  One of the important advances Apple provided as part of this release is the ability to support background processes.  This rectified an important deficiency in the iPhone platform, as other modern competing platforms have supported this for some time (Android, RIM/Blackberry, Symbian, etc.)  It is also essential for supporting a geofencing capability.

The iPhone provides two separate capabilities relevant to the problem of background location access and geofencing.  The first option, available in all versions of the iPhone operating system, is the standard location service.  This is a callback-based API that will notify the caller when location changes based on configurable accuracy and distance change filters.  The particular location technology used by the underlying OS is determined by Apple, and may involve GPS, WiFi triangulation or cell/sector triangulation.  The second option is the newly introduced “significant change location service”, which is a low-battery consumption option that presumably updates only on cell/cell-sector change, and will report even if the application has been suspended.

As it turns out, the iPhone significant change location service is simply not adequate for geofencing applications.  In in-house testing on 3G and 3Gs devices, we see notification delays of up to multiple hours.  It appears that Apple is too conservative here in terms of battery consumption.

A second, extreme approach would be to run GPS continuously (this can be accomplished using the standard location service with optimal accuracy settings.)  Of course, if GPS runs continuously, you can trigger notifications very promptly when a geographic boundary is crossed.  Along with this extremely low trigger latency behavior comes dramatic battery consumption which renders the battery drained within less than six hours, depending on the health of the battery and other service use.

Location Labs has taken a significantly more sophisticated approach.  With the iPhone, we employ a combination of techniques and heuristics involving both the standard and significant change location services, intelligent interaction with the iPhone backgrounding and suspending logic as well as local awareness of proximity to the geofence boundaries.  Together these allow us to offer a high quality firing latency guarantee (measured in minutes) while keeping impact on battery life to a minimum.

The release of our Geofence Library for iPhone is available in private beta, follow this link for details on participating.

- @sahotes

We’re speaking tonight at Mobile Monday Silicon Valley

0
Posted by joelg on June 21, 2010 – 12:59 pm
Filed under APIs, Tools & SDKs, Events, General & Administrative, Geofencing SDK, Location-as-a-Service, Universal Location API

Interested in learning more about our Geofencing API or Universal Location API? Come visit us tonight at Mobile Monday Silicon Valley: http://www.mobilemonday.us/?p=353

Welcome to Location Labs

0
Posted by tassor on June 17, 2010 – 1:51 pm
Filed under APIs, Tools & SDKs, General & Administrative, Geofencing SDK, Location-as-a-Service, Privacy Manager, Universal Location API

Carrier & developer-partners, customers, investors, friends, and those discovering us for the first time, welcome to Location Labs! A new era of mobile location services has arrived, and we’re bringing the action to drive the next wave of innovation. Over the coming weeks we’ll be opening our private beta for developers. The first to sign up and use our Geofencing SDK, Universal Location API, and Privacy Manager products will get out ahead of the pack with a whole new class of iPhone & Android apps and services leveraging background location, with access to other special secrets we’ve included. Roll up your sleeves coders, and to all our partners: Stay tuned, we have much more coming soon!

-@tassor

Google and MG – LBS Evangelists

0
Posted by jfinkelstein on May 20, 2010 – 9:48 am
Filed under APIs, Tools & SDKs, Market Observations, Universal Location API

Yesterday, MG Siegler wrote a great piece on Google’s Latitude API. I can’t compliment enough anyone who helps evangelize the power of remotely locating mobile phones.

Remote, cloud-based location of mobile phones is an area of the LBS market that is just starting to heat up. Most people, when they think of “location”, immediately think about apps, apps, apps for iPhone and Android phones. But, Google’s Latitude API will hopefully bring well-deserved attention to a new class of apps that, IMHO, have as much (more?) upside as downloadable smartphone apps.

OK, so Google Latitude has 3 million active users. That’s pretty impressive, but its not exactly mass market. What if I told you that today, with RESTful APIs, you could locate over 150 MILLION mobile phones? That’s 50x what the Google Latitude API promises on a good day. And, you can access this location info without your end user having to download a client (Google Maps or otherwise). LISTEN UP, DEVELOPERS – no, I am not kidding, you can do this today with the Veriplace® Platform (re-named the Universal Location Service in June 2010).

Already, there are folks building fraud detection apps (phone confirms that user was where financial transaction happened), mobile betting apps with built-in compliance (confirming you’re in Vegas), and apps that auto-update your location to your twitter feed (check out mine @locationjason or Tasso’s @tassor). Remote cloud-based location access will also mean that roadside assistance calls will be auto-located so callers don’t need to describe where they are to the dispatcher. In fact, 1,000+ developers are building these kinds of services right now.

Maybe someone should build an SMS check-in service that let’s end users with feature phones get into the check-in game? We have some ideas on this… developers, take this idea and run with it. Just let us know how we can help you get this done.

In both cases, Google and Universal Location Service [ULS] APIs, end user permission is required. This is critical. As an end user, you need total transparency about how your location information is being used. While there are some tradeoffs between privacy and UX, a straight forward SMS-based opt-in model should do the trick and not interfere. ULS has given lots of thought to this and continues to make improvements.

Thanks again, Google and MG!

@locationjason

Real Mass Market Location-based Services

0
Posted by jfinkelstein on May 10, 2010 – 12:50 pm
Filed under APIs, Tools & SDKs, Location-as-a-Service, Market Observations, Universal Location API

There’s been a lot of attention focused on location-based services in recent months. Mostly, the hype has focused on popular consumer apps like MyTown, Foursquare, Gowalla, and Brightkite (just to name a few), not to mention Twitter and Facebook jockeying for position in the LBS game. But, how are these companies going to make money on location?

There is very clearly usage of these services. While eyeballs and engagement certainly can be monetized, it’s going to be a challenge for these smaller companies to create profitable revenue models. That’s not to say it can’t be done, but they have their work cut out for them.

To generalize, you could group these apps into several categories including social networking, and eventually location-based marketing and advertising. At least, marketing and advertising are where the revenue generation for many of these services is going to come from.

When you think of “location”, undoubtedly you think of a consumer-facing use case whereby the end user is engaged with an app on their phone… that is, for example, they open up the Yelp iPhone app, and search for “burritos” near their current location and get shown a handful of Mexican restaurants within a few blocks.

Consider this. Location is widely available to smartphone developers for their downloadable apps. But, smartphones are only a little more than 1/5 of the US market. And, for those of you that live in New York and California, no, 95% of the country does not have an iPhone, Android phone, or Blackberry. So, what are some truly mass market location-based services? I mean services that take advantage of location on all phones, including smartphones and feature phones.

There’s a fascinating category of apps that actually require no engagement with the phone. These apps are truly mass market and device agnostic. The idea is that the “app” leverages the end user’s phone location as a proxy for the end user’s location.

Where do you usually keep your phone? It’s usually in your pocket or purse right next to your wallet.

Let’s say every time you use your credit card or take $ out of an ATM machine that your phone is located. Well, wouldn’t it make sense that if your phone isn’t in the same city or neighborhood as where your credit card or ATM card is being read that it’s treated as a red flag for a fraudulent transaction? So, maybe the transaction is denied or more information is requested. Or maybe a pattern of usage is identified over several transactions and then vetted after the fact to auto-detect and prevent further fraud.

This simple two-factor authentication could be used to help curb the more than $191 BILLION in fraud losses incurred each year by U.S. merchants.

You could envision the same verification method being used for monitoring access to secure buildings like hosting facilities or government offices. In this case, the electronic key card is the first factor of authentication, and the location of the person (their phone) who belongs to the key card is the second factor.

How about location-enabling voice calls? Emergency roadside assistance is a fantastic example. Your car breaks down in the middle of nowhere, you call AAA, and tell them to come get you. Here’s how the conversation goes today:

Caller: Hi AAA, I’m broken down, come get me.
AAA: OK, where are you?
Caller: I have no idea where I am.
- Awkward silence -

Then, you could spend 5-10 minutes trying to describe where you are. Here’s how the conversation should go:

Caller: Hi AAA, I’m broken down, come get me.
AAA: OK, I see your phone # is 415-555-6789. OK if I locate your phone?
Caller: Sure.
AAA: OK, I see you’re located within 100 yards of at 125 Oak St, near the intersection of Maple in Smallville. We’ll send a truck out to you immediately. It should take about 25 minutes.

Now that’s customer service. The caller isn’t left frustrated and anxious, and the AAA call center has saved several minutes in call time… and time is money.

Then, there’s SMS. There were over 1 trillion text messages sent in 2009.  Twitter alone processes over a billion SMS tweets per month, yet let’s you attach real-time location to your tweets only if you’re tweeting from a phone with GPS.

Why not attach location to SMS? For all the free ad-supported SMS services out there, just think about the bump in CPMs for sending location targeted ads in the SMS response.

Yes, this sort of thing is possible today.

I’m looking forward to seeing more services like this launch as access to mobile phone location becomes more pervasive. I’m hoping to see app developers think in new directions… ones that are not limited to only iPhones or downloadable apps. Ignoring 80% of the market seems wasteful. The opportunity is there.

2010 is the year when these kinds of services will start to see adoption. Developers? I’m looking at you!

@locationjason

Evaluation Criteria for Location Privacy

0
Posted by sahotes on April 22, 2010 – 8:52 am
Filed under General & Administrative

I ran across an interesting study the other day out of the U.C. Berkeley School of Information. The study considered the privacy provisions laid out in the W3C Geolocation API, and recommendations for its improvement. The Geolocation API is a part of the HTML5 specification, and as such will play an important role in location-based mobile web applications as mobile devices continue the rapid adoption of HTML5.

While the conclusions of the study were certainly excellent, I found most interesting the list of privacy-related criteria that were derived after considering a range of existing frameworks and standards. These are reprinted here:

  1. Appropriateness: Is the collection of location information appropriate given the context of the service or application?
  2. Minimization: Is the minimum necessary granularity of location information distributed or collected?
  3. User Control: How much ongoing control does the user have over location information? Is the user a passive receiver of notices or an active transmitter of policies? Are there defaults? Do they privilege privacy or information flow?
  4. Notice: Can requesters transmit information about their identity and practices? What information is required to be provided to the user by the requesting entity? What rules can individuals establish attach to their location information and transmit? Is there a standard language for such rules?
  5. Consent: Is the user in control of decisions to disclose location information? Is control provided on a per use, per recipient or some other basis? Is it operationalized as an opt-in, opt-out or opt model?
  6. Secondary Use: Is user consent required for secondary use (a use beyond the one for which the information was supplied by the user)? Do mechanisms facilitate setting of limits or asking permission for secondary uses?
  7. Distribution: Is distribution of location information limited to the entity with whom the individual believes they are interacting or is information re-transmitted to others?
  8. Retention: Are timestamps for limiting retention attached to location information? How can policy statements about retention be made?
  9. Transparency and Feedback: Are flows of information transparent to the individual? Does the speci cation facilitate individual access and related rights? Are there mechanisms to log location information requests and is it easy for individuals to access such logs?
  10. Aggregation: Does the standard facilitate aggregation of location information on specific users or users generally? Does the specification create persistent unique identifi ers?

When designing Veriplace, we considered these very same questions. In some cases (such as appropriateness and minimization) the application developer is largely in control of managing these issues. Veriplace addresses these cases by working with the developer, ensuring that guidelines such as these are followed. In other cases (such as user control, consent and transparency) Veriplace is more actively involved, building these requirements and safeguards directly into the platform architecture.

Taken together, this is a great list, and expands in important ways on existing guidelines, such as the CTIA Best Practices and Guidelines for LBS. Although perhaps an implementation detail, I might add one item: Uniform Privacy Management Interface. As LBS services proliferate, it will become more difficult for the end user to effectively manage location privacy. Providing a unified, consistent interface for managing access to location across services will be critical to ensuring the simplicity and transparency necessary to safeguard user privacy.

-@sahotes