Apple is cracking down on associations of Android devices with the iBeacon spec.
The move may hint at a larger war to own variations of the standards by which our phones ‘hear’ Bluetooth LE (BLE) beacons.
Vendors have started complying with guidelines set by Apple and have, as a result, been forced to ‘scrub’ their products of any references or connection between Android devices and their detection of iBeacon protocols. The net result is to create new difficulty in programming an Android device to hear an iBeacon…and a potentially growth of confusion in the market.
A Beacon is Still A Beacon if it Isn’t an iBeacon
To an outsider, the move probably seems obscure…or obvious. Why should an Android app be able to ‘hear’ an Apple iBeacon after all?
But an iBeacon is a device that transmits a signal using an open standard (Bluetooth) according to some specific criteria set out by Apple, and protected by all kinds of NDAs and trademarks. We know, for example, that a device which carries the iBeacon trademark is supposed to broadcast at a specific frequency.
But an iBeacon is still a Bluetooth device. In theory, any device with the right software and radio receiver should be able to ‘hear’ the signal.
For Apple, an iBeacon Isn’t *Just* BLE
But Apple clearly has a reason to think otherwise. Their moves seem to be saying:
- We have a standard for BLE transmission, and have certified devices and trademarked a name under which that standard is carried
- Association of that name and standard (iBeacon) with non-Apple products is a non-starter for Cupertino
This attitude may extend to the code. When Apple launched iBeacon with iOS7, they released SDKs to help developers detect beacons (and to turn any phone or tablet into a beacon). This code includes things like beacon ranging and distances….protocols whose algorithms are invisible to the developer. Apple may feel that their methodology for ranging beacons is also protected, and may be taking steps to avoid Android devices mimicking their approach. (This is, however, entirely speculative on my part).
Developers Forced to ‘Scrub’ Their Android Libraries
The increasingly closed-off nature of Apple’s iBeacon ecosystem came to our attention this week with a blog post by Radius Networks CEO Marc Wallace in which he announced that the company was taking down some of its products and documentation:
Prior to Apple introducing their iBeacon License Program, there were no clear guidelines from Apple on iBeacon trademark and intellectual property (IP) usage. Apple has since made great strides in formalizing their program and communicating the appropriate usage of iBeacon as a trademark and proper handling of iBeacon IP.
As a certified Apple iBeacon partner, we feel that it is important to respect the terms and spirit of our agreement. As a result, we have made the following changes:
- Removed documentation describing the technical details of iBeacon advertisements.
- Removed iBeacon-related libraries, SDKs and application implementations for mobile devices other than iOS devices.
We understand that you, our valued customers and partners, may be impacted by these changes. Please be assured that we also understand and appreciate how important it is to provide proximity solutions for multiple mobile device platforms, so we ask that you stay tuned, as we have additional exciting solutions that we will be introducing very soon. We believe that these new updates will ultimately create stronger and more robust solutions for our customers and our partners.
The post left the specific changes obscure. But the primarily deletion from the Radius product catalog was its ‘iBeacon library for Android’, shown in an older screen shot below:
By way of comparison, here is their current page:
Their GitHub repository shows the following:
Update: The Note From Our CEO is no longer active. See below.
Will Apple Pull Out the Patents?
At first, the iBeacon name was primarily window dressing for devices that transmitted signals according to the Bluetooth proximity specification.
Apple registered the iBeacon name, released the capacity to detect beacons with the launch of iOS 7, and then went mostly quiet. At the time, I speculated that Apple was either waiting to see how developers and manufacturers would use the capability before deciding on its own strategy, or perhaps didn’t realize how quickly the ‘becosystem’ would grow.
But they’ve slowly tightened up their claims to the iBeacon name and the IP that drives it.
The latest moves follow recent changes in their app approval process, in which the company started to reject apps in which the end consumer could input beacon UUID numbers. At the time, we speculated that Apple might be increasingly shifting to an attempt to “lock” its own version of beacons into its ecosystem:
But coupled with this change is another app approval policy that’s rarely noticed. Because while the specification of iBeacon would seem to suggest that Apple requires all beacons carrying the iBeacon trademark to have an “open” transmission, the reality is quite different.
Apple IS in fact allowing secure ‘coupling’ of app to beacon through the use of non-iBeacon protocols.
In other words, Apple is quietly allowing apps to securely “handshake” with an iBeacon, creating a secure connection between phone and beacon and preventing the UUID number from being publicly broadcast to any device other than phones with the requisite app.
These two things may lead to a fork between beacons that are configured to transmit to Apple devices and “open” beacons that, while vulnerable to hijacking, can’t even be ‘seen’ by Apple devices. If Apple makes further moves in the direction of closing off which beacons a device can listen for (and how) it’s possible that the iBeacon trademark (which is, for now, more of a branding benefit than an actual one) might soon represent a closed ecosystem of beacons that work with Apple devices and a parallel (and more open) system of transmission to Android phones.
But where might Apple go next?
The company owns a significant portfolio of patents related to iBeacon technology including some of the more common use cases. Patently Apple reports, for example, that:
Apple’s patent FIGS. 15A-G show embodiments of several different types of location-based content that may be provided to a media device in accordance with the principles of the present invention. FIG. 15A indicates various location-based content that may be provided in connection with a merchant that sells goods and articles of manufacture. For example, a user may access music (e.g., being freely broadcast by the establishment or for sale on content source), advertisements (e.g., coupon specials, video advertisements, and audio advertisements), event calendar (e.g., to learn of exciting new events that may be occurring at the merchant), virtual card information may be exchanged, podcast, general information on merchant (e.g., return policies), product information (e.g., graphics of products, reviews of products, etc.), or any other suitable information pertinent to the merchant.
The patents are primarily focused on communication of data wirelessly and so may be a narrow subset of current iBeacon use cases. But Apple clearly has ammunition in its patent armory should it choose to use it.
It’s Not the Device, It’s the Ecosystem
There was rampant speculation this week that Apple would launch its own iBeacon device. It arose from the discovery of an FCC filing for a USB-powered beacon.
I don’t personally see the device as anything much more than an internal tool at Apple….there’s nothing in its specification that hints at a mass market product.
The real moves that Apple is making aren’t around producing devices, they’re in a slow creeping enforcement of its specification, trademark and IP.
One Android “iBeacon library” has been scrubbed. What will follow?
The post at Radius has since been taken down, possibly to repost it to the main blog. We’ve reached out for comment. The full post is reproduced here:
Share Your Thoughts
Android “take-down”? Or simply a trademark enforcement measure? Is Apple making substantive moves to ‘close off’ iBeacon? I’d love to hear your thoughts and comments….some of this is shrouded in layers of shadow!!!