Bluetooth

BlueCasting is pushing unsolicited information to Bluetooth devices. BlueCasting is initiated by a Bluetooth client, and the information is pushed to a Bluetooth server. BlueCasting clients monitor for nearby Bluetooth devices, who intentionally or not advertise themselves, and once found, attempts to push whatever information. BlueCasting can be used for Mobile Marketing, and is being used in social network and dating products. But if wrongly used, it becomes SPAM, also referred to as BlueSpamming.

I recently read via the Pondering Primate blog about the idea of possible Guidelines for BlueCasting. There Scott refers to a good writeup by Lawrence Weber titled BlueCasting – The Next Marketing Faux-pas?.

As I look at this important problem, I would add that guidelines may be a good start, but are not sufficient to address this problem with unsolicited advertising or spam. Instead of guidelines, and interpretations, and vendor-specific solutions, there should be a method, controlled by the user, that is vendor independent, and that works consistently across handsets — and the most robust approach is a Bluetooth profile; for the purpose of this discussion let's call this the BlueCasting Profile (BCP).

Some background: Bluetooth profiles define uses for Bluetooth — this is, how Bluetooth should consistenlty behave under specific scenarios, and how it should be implemented. There are Bluetooth profiles for wireless handsets communication, for serial communication (RS-232 emulation that behaves like plain old serial cables), and for pushing objects such as vCard and vCalendar. A good summary of the currently defined profiles can be found here.

Now imagine the BCP, a profile that allows the user to define and have control of what is considered acceptable BlueCasting, what it is OK to be pushed, what the user cares about.

Related to this topic, the Mobile Marketing Association (MMA) has publised the Consumer Best Practices Guidelines For Cross-Carrier Mobile Content Services that anyone doing mobile marketing should read and follow. These guidelines cover Do and Don't for advertisment, opt-in/out and subscription. The BCP would enforce those guidelines:

  • The user can enable/disable pushes.
  • Allow any or specific pushes.
  • Allows the user to discover what BlueCasters are advertising, and then allow (or subscribe) those specific ones.
  • Allows the Bluetooth handset user to advertise what he/she cares about, maybe based on some kind of descriptor (or tag), that is used by the BlueCasters to discover what nearby users care about, and push if and only if a match occurs.
  • Allows the user to filter for specific things he/she cares about based on tags.
  • Allow the user to define for how long pushes or subscriptions are allowed.
  • ETC…

The BCP would probably extend the Object Push Profile, but there is no need to define a complete solution here — but you get the point. BlueCasting has potential, but it can be misused. No push should occur if the user/handsets don't care about the advertised information/objects. To address this, in a way that works well, that works consistently across handsets, that is vendor-independent, this advertise/push, allow/disallow use for Bluetooth must go much further than guidelines, and should be controlled from the bottom, as an enforceable Bluetooth profile.

To learn about programming Bluetooth on Java handsets see some of my articles:

ceo