EP3272062A1

EP3272062A1 - System for anti-spoofing beacon network and cloud based administration of related content

Info

Publication number: EP3272062A1
Application number: EP16769507.1A
Authority: EP
Inventors: Richard C. Graves; Chris BLANZ; Beat Zenerino; Kevin Huber; Greg THORNTON
Original assignee: Bkon Connect Inc
Current assignee: Bkon Connect Inc
Priority date: 2015-03-20
Filing date: 2016-03-21
Publication date: 2018-01-24
Also published as: EP3272062A4; WO2016154129A1; CA2980498A1

Abstract

A distributed beacon network and cloud-based management system (100) are disclosed. The beacons (102) are each configured to transmit wireless messages comprising a unique identifier generated using respective asymmetric key pairs. An administrator is enabled via a hosted web portal to remotely designate content in association with beacons, as well as proximity settings, content tags, etc. A mobile device (104) proximate to one or more beacons receives their messages via an open browser and forwards an associated content request to a hosted server. The server authenticates the beacons by retrieving and implementing the respective asymmetric key pairs. Upon authentication, the server provides access via the device browser to content designated for one or more of the beacons, and corresponding to the proximity settings and content tags. Content is provided via hosted web portals, or by redirection of the browser to third party URLs designated via the administrator interface.

Description

DESCRIPTION

SYSTEM FOR ANTI-SPOOFING BEACON NETWORK AND CLOUD BASED

ADMINISTRATION OF RELATED CONTENT

TECHNICAL FIELD

[0001] The present invention relates generally to wireless radio signal transmissions. More particularly, this invention relates to systems and methods for the deployment and management of Bluetooth Low Energy ("BLE") beacons.

BACKGROUND ART

[0002] The emergence of BLE beacons is one of numerous recent technological factors wherein consumers are increasingly enabled to interact directly with their surroundings, discovering new content, retrieving information "served up" because of its contextual relevance, and responding with their feedback and desires. [0003] There are several protocols in the market over which BLE beacons operate, including for example Apple's iBeacon protocol, which consists of a fixed length bit package (UUID / Major Identifier / Minor Identifier) that is in turn interpreted by compatible mobile Apps. However, in order to truly unlock the potential for interaction with any "smart device" upon demand, it would be desirable to reduce or eliminate the need for users to download an app associated with each respective group of devices. In keeping with the objective of rapid expansion of the Web into the physical world, it is therefore desirable to make the process of adding an element just as simple as adding a new web page.

[0004] The UriBeacon protocol is an alternative and open source protocol introduced by Google. One premise of the UriBeacon protocol is that beacons broadcast a Uniform Resource Locator ("URL"), which is the address of a web site. The UriBeacon has been promoted as a primary link between the physical world and the Internet, where places and things in can communicate via web sites. Much like QR codes, UriBeacons will be universally accessible, and will not require a custom App, as are required by for example the iBeacon protocol.

[0005] The conventional mode of operation is straightforward. With an administrative App designed to configure beacons, and when physically near to the target beacon, one can connect with a "UriBeacon" and program it with the URL of a destination web site. The field that is programmed with the URL is called the Universal Resource Identifier (URI) because it uses some abbreviations for the URL it broadcasts. The target beacon references this URI to broadcast the desired URL. A special browser executable from a client device is configured to read the URI broadcast from that beacon and connect to the destination URL in the normal way.

[0006] However, in order to connect to a UriBeacon and change the URL which it advertises, the user must be physically near the beacon, because the process is accomplished over a Bluetooth low energy link, which has a limited range. This proximity requirement can be particularly problematic where the user wishes to implement and provide periodic updates for numerous beacons across an inconveniently large area, or otherwise make appropriate range settings for a suitable user experience. The associated need for an unfamiliar, and sometimes awkward, programming task (e.g., taking the beacon's batteries out, or pushing a button) inhibits an otherwise familiar and straightforward process. This task is made unmanageable for widely dispersed installations by the requirement to have to handle each beacon in order to adjust its settings. [0007] Further, another limitation of the UriBeacon protocol is that the maximum size of the advertisement data field is 18 characters (at present), so for example:

www.xxxxYYYY.com

fits fine, whereas:

https://github.com/google/uribeacon/tree/master/specification will not fit.

[0008] For this reason, domain name shortening services are recommended and are commonly used with UriBeacons. In the above example, if the second URL were plugged into the "Goo.gl" domain shortening application, the user would obtain http : //goo . gl/Du29uS . If the user clicks on this link, he/she will be directed to the original link, but first must go to http://Goo.gl. where the link will be translated before redirection to the correct site. It would therefore be desirable to eliminate not only the step of interacting directly with the beacon, but further or at least in the alternative to eliminate the requirement of domain shortening for destinations having more than 18 characters.

DISCLOSURE OF THE INVENTION

[0009] Exemplary systems or methods according to the present disclosure provide a unique model of operation that tightly couples a beacon device such as a UriBeacon with a cloud based server (e.g., URI Management Server or "UMS"), thereby providing several major advantages over the traditional model.

[0010] In various embodiments, a system as disclosed herein includes a plurality of distributed beacon transmitters, each of which are configured to continuously broadcast messages including a URL, and with the URL having a host domain address and an identifier unique to the respective beacon embedded therein. Client devices proximate to one or more of the beacons, and having appropriate browser applications executed thereon, are able to receive the broadcast messages and subsequently transmit content requests to the host server associated with the URL. The host server is further configured to identify the beacon from the unique identifier, and return an appropriate destination URL to the client device for user selection, at which point the browser may for example be redirected to a content server associated with the destination URL for content presentation. The system may further include a hosted and administrator-facing web portal wherein at least destination URLs associated with the respective beacons may be remotely designated.

[0011] By making use of the cloud based server system to deploy beacons, one may mail them out to the field, even to hundreds of different locations, and later set up and manage all of the above functions from a hosted web portal, all without ever interacting directly with any of the beacons.

[0012] In one aspect as disclosed herein, by abstracting hardware management tasks to a server, the tasks of incorporating new objects into an interactive network (e.g., the Physical Web) can be radically simplified. Another benefit is that the use of human readable identifiers on beacons vastly simplifies human management of these devices, and simply fits them into existing management and inventory systems.

[0013] In one aspect, embodiments of a hosted system or method as disclosed herein enable simplified administration. Rather than using an administrative app in near proximity to the target beacon to reprogram the beacon to point to a different destination URL, customized UriBeacons (or otherwise a closed network of UriBeacons) may be redirected from a cloud server. For someone managing numerous beacons in dispersed locations, this is an important feature, as all beacons may be reprogrammed from a central location, as opposed to being required to visit each beacon.

[0014] In another aspect, embodiments of a hosted system or method as disclosed herein provide anti-spoofing functionalities. Because beacons generally broadcast an open air wireless message, their signal may be captured, mimicked, and rebroadcast from a different device and from a different location. This is typically called "spoofing". UriBeacons within the hosted and closed network according to the present disclosure may be prevented from being spoofed because each of them may broadcast a continuously changing unique identifier, which is recognized by the host server. Even if multiple beacons point to the identical destination URL, they all still appear unique to the host UMS server.

[0015] In another aspect, embodiments of a hosted system or method as disclosed herein detect the presence of users. When web sites are accessed through a link broadcast by a hosted UriBeacon, the host or other authorized client user or administrator is able to provide positive confirmation that the person accessing the web site is in the near proximity to that beacon. While web pages may be generally accessed from any Internet connected device, the ability in this system to recognize the current validity of a beacon's unique identifier allows one to know if access to the web site came from someone in the immediate or very recent proximity to that target beacon, or from someone accessing the web site either from a different location or at a later time. In an embodiment, this presence detection function is also based upon the host's ability to positively identify its beacons by their keyed pairing with their cloud server. [0016] In another aspect, embodiments of a hosted system or method as disclosed herein enable users to take secure ownership of a beacon, such that it cannot be reprogrammed by a third party, without ever interacting directly with the beacon. By taking ownership of the public beacon identifier in the cloud based UMS, the user is simultaneously securing the physical beacon with the matching identifier.

[0017] In yet another aspect, embodiments of a hosted system or method as disclosed herein provide unique device identifiers for each beacon in a hosted or otherwise closed network. The UriBeacon protocol offers an alternate transmit mode, where rather than a URI, the beacon broadcasts a UID (a unique identifier). As such, traditional UriBeacons must be directly programmed to either broadcast a URL or a UID. As beacons in a hosted or otherwise closed network as described herein are always uniquely recognized, their fixed broadcast may be used simultaneously as a URI and as a unique device identifier, or the hosted server can translate the URI into a secure UID rather than into a destination URL. The hosted identifier has the still further additional advantage of being secure from spoofing.

[0018] In still another aspect, embodiments of a hosted system or method as disclosed herein provide network trigger points. Because hosted beacons as disclosed herein may typically have a unique broadcast ID, which cannot be copied or spoofed, they may be used as triggers for other applications, or as highly reliable location identifiers.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Fig. 1 is a flow diagram representing an embodiment of a hosted beacon web server system according to the present disclosure. [0020] Fig. 2 is a flowchart representing an exemplary embodiment of a process for directing beacon-specific content to a device browser as implemented by the system of Fig. 1.

[0021] Fig. 3 is a flowchart representing an exemplary process of beacon authentication according to as disclosed herein.

[0022] Fig. 4 is a graphical diagram representing an embodiment of a hosted user interface according to the present disclosure.

[0023] Fig. 5 is a perspective diagram representing an embodiment of a hosted beacon according to the present disclosure.

BEST MODE FOR CARRYING OUT THE INVENTION

[0024] Referring generally to Figs. 1- 5, various exemplary embodiments of an invention may now be described in detail. Where the various figures may describe embodiments sharing various common elements and features with other embodiments, similar elements and features are given the same reference numerals and redundant description thereof may be omitted below.

[0025] Referring first to Fig. 1, an exemplary embodiment of a system 100 as disclosed herein may include a hosted beacon 102 that is configured to support some or all of broadcast options including but not necessarily limited to a traditional iBeacon protocol, a standard editable UriBeacon protocol, a hardcoded UriBeacon beacon protocol, and the like. Broadcast messages from any one or more of a plurality of beacons may be transmitted to proximate mobile computing devices 104 such as for example phones, tablets or the like. A hosted web server 106 is further communicatively linked to the device or otherwise accessible via a communications network. The server is configured to direct the browser to content via for example a destination URL 110, with the content corresponding to a particular beacon 102 being designated in various embodiments by an administrator or the like via a hosted user interface 108.

[0026] In a particular embodiment, a hardcoded URI may be used with a UMS hosted domain (e.g., http://YYY.net or http://ZZZ.biz) as the base link for this URI, followed by a unique beacon identifier, that is a 6-character alpha identifier in the initial implementation, but may be alphanumeric and may also use less or more than 6 characters for the identifier. Because the beacon identifiers may typically be assigned at manufacture or at beacon setup by the host and managed by the corresponding cloud based UMS, they are guaranteed to be unique, and the field length will be expanded if necessary. An example would be: http ://YYY.net/AkfGGy. where the identifier/serial number for that beacon would be "AkfGGy". This identifier may in certain embodiments be physically printed on or otherwise visibly discernable with respect to the beacon and/or its packaging, and the default setting of the beacon may be to broadcast this fixed URI (http : //YYY. ne t/Akf GGv) .

[0027] As previously mentioned, one critical user advantage to various embodiments of a system and method as disclosed herein is that those who set up hosted beacons 102 do not have to interact directly with beacons with a configuration App to program their destination URL. Setting or changing a beacon's destination URL can be accomplished without ever having to connect with the target beacon over the traditional Bluetooth connection, which requires one to be physically present with the beacon. Users simply have to read the beacon's Unique ID, which is printed on the beacon, go to the web portal 108 for the UMS, and enter the destination URL there in a field associated with the beacon's identifier. [0028] In an embodiment, a system 100 as disclosed herein may incorporate a functionality in the cloud based URI Management System (UMS) that translates a beacon's fixed URI into a desired URL link. As but one example, if beacon 102 with identifier # AkfGGy is to be directed to point to a web site with the URL of www.Xyz.com, a user is not required to be physically near the beacon itself in order to edit the beacon's URI field, but instead may simply go to the UMS web portal 108 which enables the user to associate the beacon having identifying sub-directory http:/ YYY.net/AkfGGy to destination URL www.Xyz.com.

[0029] In one example of a typical beacon operation, when a user with a browsing mobile device 104 selects the destination web site, the link will go to the host's UMS cloud server 106, whereupon the host will either directly host the desired web content, or the browser will link to the web site 110 associated with the destination URL as entered in the server by the beacon's administrator.

[0030] Referring next to Fig. 2, an exemplary method 200 as disclosed herein for providing some or all of the aspects referenced above may be described as follows. As disclosed herein, various embodiments of a system and method may facilitate a novel interaction between the server and a browser to accomplish a more complete abstraction of beacon hardware from the need for any physical interaction.

[0031] Depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

[0032] The various illustrative logical blocks, modules, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

[0033] The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. [0034] The steps of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of computer-readable medium known in the art. An exemplary computer- readable medium can be coupled to the processor such that the processor can read information from, and write information to, the memory/ storage medium. In the alternative, the medium can be integral to the processor. The processor and the medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the medium can reside as discrete components in a user terminal.

[0035] The method 200 may be characterized in part wherein each of a plurality of beacon transmitters are configured to implement a first step 201 of transmitting wireless messages comprising a unique identifier.

[0036] The method 200 may continue with a second step 202 wherein a mobile device proximate to one or more of the beacons receives corresponding messages, and further generates a content request for transmittal to a host web server, for example via a client web browser executed on the device.

[0037] The method 200 may continue with a third step 203 wherein the host server receives the content request from the mobile device and authenticates the beacon corresponding to the content request according to the unique identifier provided therein. [0038] The method 200 may continue with a fourth step 204 wherein the host server directs the mobile device browser to content designated for the respective beacon in the context of a destination URL.

[0039] The method 200 may continue with a step 206 wherein the host server is configured to determine a location of the mobile device as proximate to one or more of the networked beacons. This step may be distinguished from a determination of distance from a particular beacon, or a direction from the mobile device to said beacon, but rather relates to a determination that the mobile device and by extension an associated user is physically present in proximity with said beacon. Accordingly, the host server is able to provide positive confirmation, for example to the beacon administrator or simply for internal analytics, that the person accessing the destination website is in near proximity to that beacon at that particular time, as opposed to general access as may be obtained from any Internet connected device regardless of location or for example at a later time. In an embodiment, this presence detection function is also based upon the host's ability to positively identify its beacons by their keyed pairing with their cloud server.

[0040] Referring now to an exemplary process 300 for beacon authentication as illustrated in Fig. 3, two unique codes may be embedded in the firmware of each beacon at the point of manufacture. Because these codes are issued and are managed by the UMS, they are always guaranteed to be unique and they are also stored in a corresponding file on the hosted cloud UMS server permanently associated with the target beacon.

[0041] In an embodiment, the unique codes are public and private keys in an asymmetric key pair as may be implemented for server-side authentication of broadcasts for a respective beacon. The first code may be the beacon's unique ID, which is its public ID. It is this code that is printed on the beacon, and it is this same code that one uses to access the associated file in the hosted server where the destination URL is entered (or where web content is directly hosted). The second code is the private passkey that is never exposed, and which is used in conjunction with an encryption algorithm to confirm to the host's cloud server the unique identity of each beacon.

[0042] While the private passkey could be the beacon's unique MAC address, such an implementation is not recommended for reason that it complicates manufacturing by necessitating the recovery of the MAC address associated with a beacon ID during the manufacturing process for use in the UMS, if one is to avoid having to pair with the target beacon during deployment.

[0043] With respect to the aforementioned process 300, the algorithm references a beacon's private passkey to continually change its identifier (step 301), which pattern can be uniquely recognized by the hosted server (step 302) because it has the beacon's passkey. In an embodiment, the system may for each respective broadcast generate an authentica table message with a new identifier/ security key, the respective identifier having been generated via encryption techniques using the private passkey. In one embodiment, the host causes its beacon to broadcast the respective security key as a dummy sub-directory of the URL being broadcast, as data following a "#" separator, or the like.

[0044] For example, if the beacon ID is "KLtHbr" and its momentary security key is "6H8k9", then the URI that the beacon will broadcast will be www . KLtHbr/6H8k9. The hosted server will use the "6H8k9 sub-directory" to identify the beacon and then will discard this identifying sub-directory (step 303). In alternate embodiments, the system may use a separator such as for example a "#" or equivalent alternative between the public beacon identifier and the security key, or no separator at all, where the UMS server knows the field length of the ID and the Key. Finally, the server (step 304) authenticates the beacon by implementing the asymmetric key pair and identifying the beacon in the network.

[0045] In another exemplary aspect of a system according to the present disclosure, a monitoring feature for the beacon power supply (e. g., internal battery) may be added within the framework previously described. Because the beacon is broadcasting a URI that might look like: http : I hp hy. net/HYHKuu#278iM. with the last field being the changing security key based upon the private key embedded into each beacon, we can easily have the beacon also send a reading of its battery's voltage level in the same field, which will allow the host server to interpret and thus monitor battery state. Similarly, beacons may include many different sensors and the sensor data form any of these beacons may be transmitted in the additional transmitted data.

[0046] Alternatively, depending upon the number of characters required to implement security, the security key may be transmitted in alternate broadcast from the sensor data to allow both to be transmitted.

[0047] In one particular example as provided herein for further illustration, the server has received the above URI: http ://phy. net/HYHKuu#278iM. The server interprets the key "278iM" for security and battery state, and then discards the number. Typically, it would then return the destination URL (http://destinationwebsite.com) to the requesting browser so that the browser may then view the requested web page.

[0048] In an embodiment, the server as disclosed herein may further provide additional information about the desired operation of the beacon hardware, which will improve the customers' experience. This may be accomplished by providing coded information in addition to the destination URL. An exemplary transmission from the server to the browser may look like or equivalent to the following: http://demo- url.com#8NJHRF, where additional information about the desired user experience is added after a "#" separator (or other character, which separator will serve to introduce the coded information). Alternatively, the UMS may transmit a file to the browser, which includes the additional information.

[0049] In an embodiment, the first information provided by the server to the browser is the desired viewing range. Using an example of an art gallery to describe the problem being solved, if one were in a gallery room, with six pieces of art on each of four walls, and each piece had a UriBeacon attached, then a consumer would typically see all twenty-four pieces of art with her web browser, and possibly a few more from adjacent rooms. This makes it harder to identify and select the one piece of art in front of which the viewer is standing. Today one can mitigate this problem by individually turning down the transmit power of the radios in each of the beacons, which is a cumbersome task at least for the reason that again, it required one to be near to and to "pair" with the beacons to be adjusted.

[0050] By utilizing systems and methods as disclosed herein, and with further reference to Fig. 4, one can set the desired viewing range by simply checking a box indicating at a hosted administrative web portal 400. This is the same portal where the destination URL 405 may be set. The user interface might work for example where a beacon having ID# Ah8unT 402 is pointed toward destination URL http://demo-url.com and has a designated viewing distance 404 of "IMMEDIATE", which would cause one to see this URL on a hosted web browser if one is within about approximately three feet of the piece of art.

[0051] By using this method, the user is not adjusting the transmit power of the beacon, but instead is passing back to the viewing browser the range at which it should display the web site (in the coded message #8NJHRF), such that the browser, which can measure range because of its ability to monitor the beacon's signal strength, can then make use of this preference to decide whether to display the web site, or alternately, how to rank it on the browser display.

[0052] In another aspect according to the present disclosure, tagging options

403 may be facilitated in a similar way, where the user will be able to choose on the

UMS server portal the TAGs that should be associated with a web site.

[0053] In one example, the following tags may be listed in the host server administrative portal, and allow the user to check those that apply to the beacon's location, and further pass this information to the browser in the coded message after the "#" or other separator, wherein the browser can use these tags to filter and rank content:

--FOOD

-DRINK

-RETAIL

-DEALS

-ARTS

-ENTERTAINMENT

-TRANSPORTATION

-SPORTS

-HISTORY --POINTS OF INTEREST

-VEND

-INFORMATION/DIRECTIONS

-PEOPLE

-REAL ESTATE

-HELP WANTED

-FOR SALE

-COMMERCIAL

-UNIQUE

[0054] For example, if a beacon is located at a restaurant, and is alternately pointed to either the menu or to a promotional deal, then one might check the "FOOD" tag and the browser would know to show this content first if the consumer was looking for food, while similarly not ranking highly the apartment for rent above the restaurant tagged as "REAL ESTATE".

[0055] Various embodiments of systems and methods as disclosed herein therefore enable people who deploy beacons to be able to simply enter basic information about those beacons, including viewing range and location description, and to be able to automatically present this information as an addition to the destination URL, so that the browser can use it to display information in a manner most relevant to a consumer.

[0056] One additional benefit of this approach is that the UMS administrative portal will also allow one to set up and pre-designate alternate destination web pages for a beacon and simply swap between them, or to automatically swap between them according to a predetermined schedule.

[0057] For example, again by reference to a portion 406 of the user interface 400 in Fig. 4, a first destination URL (e.g., http:/myp age. com/breakfast) may be designated for content requests from a client device browser occurring between 7:00am and 11:00am, while a second destination URL (e.g., http:/m ypage.com/lunch) may be designated for content requests from a client device browser occurring between 11:00am and 3:00pm, and a third destination URL (e.g., http:/mypage. com/dinner) may be designated for content requests from a client device browser occurring between 5:00pm and 8:00pm, etc.

[0058] In another aspect, various embodiments of a system and method as disclosed herein may provide additional service enhancements when one makes use of a host web server to enhance, translate and augment the information broadcast by a UriBeacon. For example, in one embodiment a user may manage favicons, titles and descriptions at the host server level. The host server could return these selections to the browser.

[0059] The server may further or otherwise return more than one URL to the browser, thus acting as more than one Uribeacon. For example, a parking sign broadcasting a URL with parking information could also return a second URL for "neighborhood notices". Restaurants could have one URL for the menu, and a second for specials. The alternate URL could even be "leased".

[0060] Throughout the specification and claims, the following terms take at least the meanings explicitly associated herein, unless the context dictates otherwise. The meanings identified below do not necessarily limit the terms, but merely provide illustrative examples for the terms. The meaning of "a," "an," and "the" may include plural references, and the meaning of "in" may include "in" and "on." The phrase "in one embodiment," as used herein does not necessarily refer to the same embodiment, although it may.

[0061] As defined herein, the term "beacon" may at least refer to devices with short range communications, configured to transmit wireless signals detectable by mobile devices proximately located thereto. Examples of such beacons may typically include, but unless otherwise stated are not expressly limited to, radio frequency (RF) beacons (e.g., those configured to transmit Bluetooth™ Low Energy (BLE) signals), and may further be configured for fixed application (e.g., a battery powered beacon mounted to a known location), or for mobile application (e.g., a USB beacon mountable to a mobile device).

[0062] With reference to Fig. 5, an exemplary beacon 102 may be configured with one or more condition sensors 112 such as for example battery power as further described below, and may further store information corresponding to an asymmetric key pair 114 or the like for beacon authentication, also as further described below.

[0063] The term "user interface" as used herein may unless otherwise stated include any input-output module with respect to the hosted server including but not limited to web portals, such as individual web pages or those collectively defining a hosted website, mobile applications, desktop applications, telephony interfaces such as interactive voice response (IVR), and the like. Such interfaces may in a broader sense include pop-ups or links to third party websites for the purpose of further accessing and/or integrating associated materials, data or program functions via the hosted system and in accordance with methods of the present invention.

[0064] The term "communications network" as used herein with respect to data communication between two or more parties or otherwise between communications network interfaces associated with two or more parties may refer to any one of, or a combination of any two or more of, telecommunications networks (whether wired, wireless, cellular or the like), a global network such as the Internet, local networks, network links, Internet Service Providers (ISP's), and intermediate communication interfaces.

[0065] Conditional language used herein, such as, among others, "can," "might,"

"may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.

[0066] The previous detailed description has been provided for the purposes of illustration and description. Thus, although there have been described particular embodiments of a new and useful invention, it is not intended that such references be construed as limitations upon the scope of this invention except as set forth in the following claims.

Claims

1. A system comprising:

a plurality of beacon transmitters, each of said transmitters configured to broadcast wireless messages comprising a Uniform Resource Locator (URL), the URL comprising a host domain associated with a host and an identifier for the respective beacon transmitter;

one or more servers configured to

generate a hosted user interface enabling designation by an authorized user of content to be accessed by client devices proximate the respective beacon transmitter, and

responsive to a content request from a client device comprising the URL with its unique identifier for the respective beacon transmitter, to provide access via a browser executed by the client device to content designated for the respective beacon transmitter.

2. The system of claim 1, wherein each of said transmitters comprises a respective asymmetric key pair, and is further configured to continuously generate different unique identifiers using the asymmetric key pair.

3. The system of claim 2, wherein the one or more servers are configured to

authenticate one or more beacon transmitters in accordance with a content request from a client device comprising respective ones of said unique identifiers, by retrieving and implementing the asymmetric key pairs associated with the respective beacon transmitters, and

responsive to the authentication of the one or more beacon transmitter, to provide access via the client device browser to the designated content.

4. The system of claim 3, wherein the asymmetric key pair comprises a public key and a private key stored in association with the one or more servers.

5. The system of claim 3, wherein the hosted user interface enables designation by an authorized user of content to be accessed by client devices in accordance with a destination URL.

6. The system of claim 5, wherein the one or more servers are configured to provide access to content designated for the respective beacon transmitter by generating a return message to the client device including the destination URL, and

wherein the one or more servers are further configured to enable an administrative user via the hosted user interface to define a proximity setting and one or more content tags for one or more of the transmitters.

7. The system of claim 6, wherein the one or more servers are further configured to process one or more information tags appended to the host URL in the content request, and to include one or more of the information tags to the destination URL in the return message to the client device.

8. The system of claim 7, wherein the one or more servers are configured to provide access to content designated for the respective beacon transmitter by generating the return message to the client device including the proximity setting and the one or more content tags with the destination URL.

9. The system of claim 7, wherein the one or more servers are further configured to enable an administrative user via the hosted user interface to define favicons, titles or descriptions in association with the destination URL for a respective beacon,

wherein the one or more servers are further configured to generate the return message to the client device including the defined favicons, titles or descriptions along with the destination URL.

10. The system of claim 7, wherein the one or more servers are further configured to enable an administrative user via the hosted user interface to set up and pre-designate alternate destination web pages for a beacon and simply swap between them, or to automatically swap between them according to a predetermined schedule.

11. The system of claim 10, wherein access to the content is provided via a hosted web portal.

12. The system of claim 10, wherein access to the content is provided by redirection of the executed browser to a third party URL designated via the user interface.

13. The system of claim 1, wherein the plurality of beacon transmitters are further associated with one or more respective condition sensors, each of said transmitters configured to transmit the wireless messages further comprising data representative of one or more outputs from said condition sensors.

14. The system of claim 13, wherein one or more of said condition sensors is configured to monitor a battery state for the respective beacon transmitter.

15. A system comprising:

a plurality of beacon transmitters, each of the transmitters comprising an asymmetric key pair, and

each of the transmitters configured to

broadcast wireless messages comprising a Uniform Resource Locator (URL), the URL for each beacon transmitter comprising a host domain associated with a host and a unique identifier for the respective beacon transmitter, and

generate a different unique identifier for each broadcasted message using the asymmetric key pair.