I was doing an internship at a big semiconductor company the summer announced iBeacon. They had something very similar in the works (presumably started about the same time as Apple), and called them beacons - they certainly worked by exactly the same method.

Absolutely ... this wasn't an entirely new "invention," although Apple's technique of cramming their metadata in the spec is definitely novel, although nonstandard.

Mmm, I'm not so sure. If you read the Bluetooth 4.0 spec [1], it's very obvious on page 1047 (numbered 801 in the pdf) the exact advertising format, with its block of bytes for sending data. Sending a UID would be exactly what you would do, as a first approximation. There are actually much more interesting schemes that can be used - say if you don't want your competitors to be able to derive any information of their own from your beacons.

[1] - https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?d...

Around 2003/2004 a local magazine called NAG (http://www.nag.co.za/) had an opinion piece at the end in which the author theorized using beacons for an inverse purpose: attach Bluetooth fobs/beacons to your keys and then triangulate given how your phone scales the signal strength of the BT signal. IIRC it would have only worked with Nokias because no other brand implemented this Bluetooth power consumption optimization spec. I do remember the article indicating that such beacons could be found with a little bit of effort.

The only piece missing from the puzzle was that phones only have one Bluetooth aerial, so triangulation would have been impossible. It would still be possible to determine unitless distance.

The handheld phone is moving, the accelerometers track it, it's no problem; since beacons happen only every 10s, you should make kale juice and do stretches then look, or wait for the drone to spam light near them (because they're still black keys.) It's not an instant joy and the antenna gain to make it so...

It rarely matters who is first.