CA3001062A1 - Beacon-implemented system for mobile content management - Google Patents

Abstract

A mobile content management system (100, 600) includes a plurality of distributed beacon transmitters (102, 602), each configured to continuously broadcast messages including a URL (604), the URL having a host domain address and an identifier unique to the respective beacon embedded therein. Client devices (610) 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.

Description

DESCRIPTION
BEACON-IMPLEMENTED SYSTEM FOR MOBILE CONTENT MANAGEMENT
TECHNICAL FIELD
[0001] The present invention relates generally to systems implementing wireless radio signal transmissions and mobile content management. More particularly, this invention relates to the deployment and management of location-based technologies in the context of mobile content management systems.
BACKGROUND ART

[0002] The emergence of Bluetooth Low Energy (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, e.g., 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, in some circumstances it may 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] Alternative and open source protocols such as UriBeacon and Eddystone-URL have been implemented, and may be referred to herein as Physical Web beacons, wherein the beacons broadcast a Uniform Resource Identifier ("URI") such as without limitation a Uniform Resource Locator ("URL") or uniform Resource Name ("URN"), in the context of accessing a network location such as a website address. As used herein, URI may refer interchangeably to a unique identifier associated with a beacon, a URN, or a URL, except in instances where the URL
is specified as including the unique identifier associated with the beacon (the URI). The Physical Web (PW) has been promoted as a primary link between the physical world and the Internet, where places and things in can communicate via websites. Much like QR codes, PW beacons will be universally accessible to compatible apps and browsers, and will not require a custom App, as are required by, e.g., the iBeacon protocol.

[0005] The conventional mode of operation with a PW beacon is straightforward.
One benefit of beacons that broadcast URLs rather than unique IDs is that any compatible application, collectively referred to herein as PW browsers, can retrieve the website associated with the URL broadcast by PW beacons. The most common use of a PW browser is that the user initiates a scan for nearby content, which displays a visual list of the metadata associated with nearby websites, whereupon the user selects one of interest and is directed to that website (URL). The experience is much like that from the common internet browser, which displays a snapshot of available websites based upon search terms, except that the user does not enter search term, but instead, the list of available websites is based upon proximity to the user.

[0006] With an administrative App designed to configure beacons, and when physically near to the target beacon, one can connect with a PW beacon and program it with the URI in combination with a network location and methodology of retrieving content from said destination ¨ in practical terms a URL. The target beacon references this URI to broadcast the desired URL. A special browser executable from a client device is configured to read the broadcast from that beacon and connect to the destination URL in the normal way.

[0007] However, in order to connect to current Bluetooth beacons such as a UriBeacon or Eddystone beacon 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 handle each beacon in order to adjust its settings. Therefore, it would be desirable to eliminate the requirement of locally and directly interacting with the beacon for configuration by enabling a network-based management platform for the plurality of beacons in a dispersed installation.

[0008] Further, another limitation of the Eddystone and UriBeacon protocol is that the maximum size of the advertisement data field is 17 or 18 characters respectively (at present), so for example:
www.xxxxYYYY. co m fits fine, as opposed to:
https://github.com/google/uribeacon/tree/master/specification.

[0009] For this reason, domain name shortening services are recommended and are commonly used with Eddystone beacons and UriBeacons. In the above example, if the second URL were plugged into the "Goo.g1" 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. This one-to-one short-URL to destination-URL relationship can be problematic because the beacon is only allowed to broadcast a single shortened URL in reference to a third-party domain shortening service. For example, no additional URL information can be appended to the shortened URL, such as battery state or other sensor information tags so as to be passed through the URL to the destination location for contextual determination purposes. 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 the need for third-party domain shortening applications for destinations having more than 18 characters, and to provide a methodology where contextual information appended to or embedded in a shortened URL by the beacon can be transferred to the associated destination URL.

[0010] Another problem in conventional applications is that websites currently have embedded content that is displayed by a browser upon search, commonly referred to as metadata. These typically include the website's title, its favicon, and its description.
Because this information is embedded in the website, it is not easily changed without making direct changes to the website.
For websites displayed on a beacon browser (e.g., PW browser) it would be beneficial if the website's metadata could be dynamically changed. For example, if a restaurant's menu is on a website to be accessed and reviewed by people near to the restaurant, then it would be desirable to the restaurant owner to be able to change the title for that website (as displayed on a person's browser) to say "Meatloaf Special today" or "2 for 1 PBR's" or "Free appetizer's for the next hour"
or whatever message the restaurant wants to broadcast in order to capture the attention of passing consumers when they scan for location-based websites, and it is preferred that this can be done without having to change the underlying website.

[0011] Still another problem with conventional techniques is that beacons currently broadcast content through simple strings including resource locators (e.g., URLs). As such, they are a powerful platform to make relevant content available to consumers in physical locations. However, if multiple beacons broadcast the same URL, then the source location of the user who accesses the beacons is lost. One reason for this is that many beacon browsers will retrieve the destination URL when the beacon is initially scanned, whereas that destination URL contains no reference to, or way of identifying, the originating location. Even if there is a code in the shortened URL, often all beacons use the same shortened URL to access the same destination URL, and because most Physical Web browsers do not make a second call to a server when that URL is actually selected by the user, they cannot relate the shortened URL and the common destination URL when the destination is selected. It would therefore be desirable that when location based content is accessed, and when more than one location is associated with that content, that the point of origin of each access can be accurately identified.

[0012] Yet another problem with conventional Bluetooth beacon protocols such as iBeacon is that traditional beacons broadcast a static, unique ID associated with the broadcasting beacon. This static identifier creates security and privacy risks, as unauthorized individuals can easily obtain the beacon ID and "hijack" or "spoof" the beacon. This allows unauthorized users to duplicate the ID
to fool other users or to track the location of a moving beacon by monitoring the proximity to the static beacon ID. It is therefore desirable to eliminate the need to for a static beacon ID in the beacon protocol, thereby improving network security and user privacy.

[0013] It would still further be desirable to be able to gather context from any one or more of a broadcasting beacon, a beacon browser and a server-based platform, to render more relevant content to users.
DISCLOSURE OF THE INVENTION

[0014] Exemplary systems or methods according to the present disclosure provide a unique model of operation that tightly couples a beacon device, such as a Physical Web beacon, with a cloud based server (e.g., URI Management Server or "UMS") and in some embodiments a mobile client utilizing a hosted software development kit, thereby providing major advantages over the traditional model.

[0015] 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 mobile applications executed thereon and as configured for beacon interaction, 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 mobile application may for example be redirected or enable redirection 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 respective beacons may be remotely designated.

[0016] One aspect of a cloud based web server system as disclosed herein is that it works within the familiar architecture of the web, fitting seamlessly into the existing architecture of common web pages and physical web browsers. The present invention may offer powerful capabilities as centrally situated to monitor traffic between and among browsers interacting with its associated beacons and their destination web pages. The unique and central positioning with respect to a customer scan of his surroundings and the subsequent selection of a website, combined with previously unknown capabilities for location knowledge, enables the present invention to add critical intelligence to a transaction, unachievable in normal web interactions, benefiting both the consumers and creators of content.

[0017] In another aspect, 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.

[0018] In another 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 Physical Web beacons (or otherwise a closed network of Physical Web beacons) 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.

[0019] 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". Physical Web beacons within the hosted and closed network disclosed herein may be prevented from being spoofed because each of them may broadcast a continuously changing unique identifier, which is recognized by the host server.

[0020] In another aspect, embodiments of a hosted system or method as disclosed herein detect the presence of users. When websites are accessed through a link broadcast by a hosted Physical Web beacon, the host or other authorized client user or administrator is able to provide positive confirmation that the person accessing the website is in near proximity to that beacon. While web pages may be generally accessed from any Internet connected device, the ability in this system to validate a transaction's unique identifier allows one to know if access to the website came from someone in the immediate or very recent proximity to that target beacon, rather than 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.

[0021] In another aspect, disclosed embodiments 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.

[0022] In yet another aspect, disclosed embodiments herein provide unique device identifiers for each beacon in a hosted or otherwise closed network. The Eddystone protocol, e.g., offers alternate pluralities of frame type transmit modes, including Eddystone-URL, Eddystone-TLM, and Eddystone-UID, wherein the Eddystone UID is a unique identifier. As such, traditional Eddystone beacons must be directly programmed to either broadcast a URL or a UID, or to alternate between the two, which consumes battery life. 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.

[0023] In still another aspect, disclosed embodiments 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

[0024] Fig. 1 is a flow diagram representing an embodiment of a hosted beacon web server system according to the present disclosure.

[0025] Fig. 2 is a flow diagram representing an exemplary embodiment of a process as implemented by the system of Fig. 1.

[0026] Fig. 3 is a flow diagram representing an exemplary process of beacon authentication according to the present disclosure.

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

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

[0029] Fig. 6 is a block diagram representing an embodiment of an application-based hosted beacon web server system as disclosed herein.

[0030] Fig. 7 is a flow diagram representing an exemplary embodiment of a URL
interpretation and retrieval method according to the present disclosure.

[0031] Fig. 8 is a flow diagram representing an embodiment of a URL security method as disclosed herein.
BEST MODE FOR CARRYING OUT THE INVENTION

[0032] 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 broadcast messages including a hosted URL in any protocol that supports URL transmissions. Broadcast messages from any one or more of a plurality of beacons may be transmitted to proximate mobile computing devices 104 such as phones, tablets or the like, wherein such devices are capable of receiving the broadcast messages.
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 a browser or application of the mobile computing device 104 to content via, e.g., 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 in association with the hosted web server 106.

[0033] 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. net/AkfGGy).

[0034] As previously mentioned, one critical user advantage to certain systems and methods as disclosed herein is that those who set up hosted beacons 102 do not have to interact directly with (i.e., be in substantial proximity to) 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 physical proximity to the beacon. Users simply obtain or read the beacon's unique ID, which is printed thereon, go to the web portal 108 for the UMS, and enter the destination URL
in a field associated with the beacon's identifier.

[0035] 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 destination website 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 (wherein "YYY.net" represents the hosted UMS server address as described herein) to destination URL www.Xyz.com.

[0036] In one example of a typical beacon operation, when a user with a browsing mobile device 104 selects the destination website, the browser will automatically link to a website 110 associated with the destination URL entered in the UMS server by the beacon's administrator. Typically, the destination URL may be associated with a third party website, content management system, and the like. In some contexts, the destination URL may direct the browser to a hosted content server, whereupon the host will directly present the desired web content.

[0037] In certain embodiments, additional information may be embedded into the desired URL link to add contextual information to be processed by one or more of an application upon the mobile device 104, by the UMS cloud server 106, or by the content server of the destination URL. For example, the UMS may add in addition to the unique, fixed URI a proximity component which informs the mobile device 104 of the range at which the mobile device should display the content of a nearby beacon 102. As another example, the beacon itself may embed not only its unique identifier, but also additional information such as an indicator of battery state and/or other sensor outputs. The UMS upon receiving an associated message (content request) from the mobile device may then extract the embedded battery state variable, update its management database, and then discard that variable or otherwise add/embed it to the destination URL if desired.

[0038] In certain embodiments, other sensory data may be embedded in the initial URL as broadcast by the beacon via information tags such as, but not limited to:
movement detection, sound detection, temperature, and light level. The UMS cloud server 106 may process these information tags in accordance with instructions and provide the beacon administrator information via the UMS web portal 108. The UMS cloud server may identify a destination website 110 to be returned to the browser from among a plurality of options based on the contextual information provided via the URL-embedded information tags. In embodiments wherein the UMS
is also the content server, it may populate certain content upon user selection of the associated website 110 with different information based on the contextual information provided via the URL-embedded information tags.

[0039] The mobile device may further add contextual information regarding, e.g., the mobile app and/or associated user, wherein this additional information from the beacon and/or mobile device is added to the original URL with the domain of the UMS. The relevant additional information and/or associated contextual variables, as appended to or otherwise embedded within the URL
received by the UMS, may subsequently be transferred to the destination URL by the UMS.

[0040] 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, 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.

[0041] 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., it may be not all described acts or events are necessary for the practice of a given process or 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.

[0042] 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 without thereby causing a departure from the scope of the disclosure.

[0043] 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.

[0044] 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. The processor and medium can reside as discrete components in a user terminal.

[0045] The method 200 may be characterized in part wherein each of a plurality of beacon transmitters are configured to implement a first step 201 wherein the beacons transmit via a wireless protocol messages including at least a unique identifier. The unique identifier may take the form of any identification component sufficient to uniquely identify the beacon. The message may in certain embodiments be a URL, wherein the URL contains the unique identifier. In further embodiments, the message may be a shortened URL of 18 characters or less in accordance with for example Eddystone-URL and UriBeacon limitations.

[0046] The method 200 continues with a second step 202 wherein a mobile device proximate to one or more of the beacons receives the one or more corresponding transmitted messages, further generates a content request in association with the received messages, and transmits the content request via a communications network to a UMS cloud server. In an embodiment wherein the received message is a URL, the mobile device's generated content request may take the form of the same received URL to be submitted via a browser on the mobile device. In alternative embodiments, the mobile device's generated content request may append, modify, or substitute the received URL with additional tags or other information to provide added context to the originally received message. For example, upon receiving a URL from the beacon, the mobile device may append to the URL information tags which convey information about the device's user, phone state or phone sensor data.

[0047] In certain embodiments, the mobile device may generate a content request from the message via an application installed on the mobile device, wherein the application appends, modifies, or substitutes information to the received message in accordance with application-specific parameters. For example, an application may add information tags sufficient to identify user, the application, the mobile device being used, the type of mobile device being used, information specific to or received by the mobile device, user-inputted information, and the like.

[0048] The method 200 continues 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 and relative to the beacon's unique identifier. In an embodiment, the beacon may be authenticated wherein the unique identifier includes or embodies a public key and a derivative of a private key, wherein the derivative of the private key is authenticated in accordance with a server-stored private key, the two keys forming an asymmetric key pair for server-side authentication.

[0049] In certain embodiments, the server may fail to authenticate the beacon in accordance with a unique identifier, such as if the beacon's unique identifier does not comply with the server-stored key. Such instances may occur where an insecure beacon "spoofs" a secure beacon and attempts to deliver a message reserved for the secure beacon. In such instances, the server may reject the content request and terminate at this step, or alternatively continue to step 204 wherein the content to which the device browser is directed is designated for unauthenticated beacons.

[0050] In an embodiment, the host server may receive and process certain information in the content request in accordance with analytical information unrelated to the destination address and associated content to be designated in step 204. For example, the content request may contain non-content information including the battery state of the beacon, sensory data, and other contextual information which may be useful for marketing analytics or for other purposes.

[0051] The method 200 continues with a fourth step 204 wherein the host server directs the mobile device browser to content designated for the respective beacon in the form of a destination URL. In an embodiment, the server may direct the device browser via a URL
redirection, wherein the URL transmitted via the content request is processed by the server and then associated with a destination URL. In other embodiments, the server may determine content in association with a device application as opposed to a browser, wherein the content designated is to be populated in the mobile device application. In other words, because a system as disclosed herein is based on a first (hosted) URL as broadcast by the beacon transmitter and a second (destination) URL
generated by the host server, users can access content either through compatible browsers or device applications, thus making content more universally accessible.

[0052] In relevant embodiments, the server may determine the destination URL
designated for the unique beacon based in part on the additional informational tags included in the content request.
The server may further append or include information tags to the determined destination URL
based in part on designated inputs from the beacon administrator via the hosted web portal. For example, the server may direct the mobile device browser or application to presentation of the destination URL in accordance with satisfaction of administrator-designated threshold parameters as further may be determined by the mobile device browser or application itself, based on tags including without limitation: user proximity to the beacon, user identity, application type, phone type, time of day, user search query, etc. As a more specific example, one set of content may be designated for authorized users proximate to a beacon, whereas another set of content may be designated for unauthorized users proximate to the same beacon. In another example, users of one client application will access one set of content while users of a general browser or of a different client application can access different content.

[0053] The method 200 continues with a fifth step 205, wherein the host server may direct the device browser to the designated content via a third-party URL (205a) or alternatively via a hosted web portal (205b). In step 205a, the server may redirect to content hosted via a third-party, which will be identified by its URL. In certain embodiments, the server may generate a third-party URL
including URL tags such as UTM information, the beacon ID, a mobile device supplied user ID, or queries by which the third party website can process information and display content in association with the content designation of the server upon the mobile device.
Alternatively, in step 205b, the server may provide a destination URL associated with a hosted content server, wherein the device browser may be selectably redirected to hosted content thereby.

[0054] The method 200 continues 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.

[0055] 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 of a plurality of hosted beacons 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.

[0056] 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 publicly associated with (e.g., affixed to, 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.

[0057] While the private passkey could be the beacon's unique MAC address, such an implementation may typically not be 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.

[0058] 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 generate authenticatable messages with each 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.

[0059] 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.phy.net/KLtHbr/6H8k9.
Pursuant to a content request associated with said broadcast, the hosted server will use the "6H8k9 sub-directory" to validate 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 retrieving and validating the asymmetric key pair and identifying the beacon in the network.

[0060] 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://phy.net/HYHKuu#278iM, with the last field being the changing security key based upon the private key embedded into each beacon, the beacon may 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 from any of these beacons may be transmitted in the additional transmitted date. 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.

[0061] 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.

[0062] In an embodiment, the server as disclosed herein may further provide any amount of additional information to 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).
Although the additional coded information here is represented with six alphanumeric characters, it should be noted that in this context the coded information is not limited to the same, and may be substantially more complex or lengthy as desired. Alternatively, the UMS may transmit a file to the browser, which includes the additional information.

[0063] 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 Physical Web beacon 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.

[0064] 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 a certain proximity such as, e.g., approximately three feet from the piece of art.

[0065] By using this method, the administrator is not adjusting the transmit power of the beacon, but instead is passing back to the viewing browser the range at which it should make the website (in the coded message #8NJHRF) available for user selection. The browser, which can measure range because of its ability to monitor the beacon's signal strength, can accordingly receive the appended destination URL and then make use of this preference to decide whether to display the website, or alternatively how to rank it on the browser display.

[0066] In another aspect according to the present disclosure, tagging options 403 may be facilitated in a similar way, where the user (content administrator) will be able to choose on the UMS server portal the TAGs that should be associated with a website.

[0067] 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

[0068] In various embodiments, these tags may also be returned as query codes.

[0069] 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".

[0070] Various embodiments of systems and methods as disclosed herein therefore enable people who deploy beacons to simply enter basic information about those beacons, including viewing range and location description, and 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. As noted otherwise herein, one of skill in the art may appreciate that the information conveyed may be about more than the beacon, and may be about or otherwise facilitate personalizing the experience by providing information that influences what content is rendered on the destination web page.

[0071] 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.
For example, again by reference to a portion 406 of the user interface 400 in Fig. 4, a first destination URL (e.g., https:/mypage.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., https:/mypage.com/lunch) may be designated for content requests from the browser occurring between 11:00am and 3:00pm, and a third destination URL (e.g., https:/mypage.com/dinner) may be designated for content requests from the browser occurring between 5:00pm and 8:00pm, etc.

[0072] Additional service enhancements may be provided when one makes use of a host web server as disclosed herein to enhance, translate and augment the information broadcast by a Physical Web beacon. For example, in one embodiment a user may manage destination website metadata (e.g., pertaining to images, favicons, titles, descriptions and the like) at the host server level. The host server could return these selections to the browser in place of the metadata embedded in the destination web site, thus allowing the administrator to make easy changes to the information that will appear on the consumer's app or browser search display to describe the destination website.

[0073] The server may further or otherwise return more than one URL to the browser, thus acting as more than one Physical Web beacon. 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".

[0074] As previously noted, one problem with conventional applications is that where multiple beacons broadcast the same URL, the source location of the user who accesses the beacons is lost.
Various embodiments of a hosted system as disclosed herein address this problem by routing all beacon traffic through a central hosted server (e.g., PHY.net), which is thereby in a position to add source information back into the transition, thus allowing content providers to know exactly which beacon originated the beacon scan. This feature is further enabled by the presence of a unique identifier for each of the associated beacons.

[0075] In one particular example, a beacon in accordance with the present disclosure broadcasts its unique identifier in a format such as follows:
http://phy.net/ABC123, where "PHY.net" can be used by the beacon browser in accordance with the hosted server to translate this identifier into a destination URL or the like in accordance with for example a user (content owner) designation.

[0076] The hosted server may further coordinate with the beacon browser to generate a "source identifier" including a beacon's unique identifier with the destination URL as either a hash extension, or as a query variable, with the preferred implementation being a query variable. In one example, the respective beacon may broadcast:
http://phy.net/abc123, wherein the desired destination URL as for example designated by the content owner is:

http://discountcoupon1x1.com, and further wherein the hosted server returns a message string including the destination URL and an exemplary query variable as follows:
http://discountcoupon1x1.com/?physource=abc123

[0077] By adding the original unique beacon identifier as a query variable to the end of the destination URL, through a variable ("physource"), the hosted server and by extension authorized users are able to associate the point of origin to the access of the destination URL (i.e., website). As such, the server hosting the website can use this information through its own database to determine the source location of the access, or the query variable ("physource") may be used via a hosted server API to retrieve information about the source location from the hosted server.

[0078] For illustrative purposes, consider the example where a merchant user associated with convenience stores implements the hosted server to bulk edit (building on features as previously noted herein) 1,000 beacons in 1,000 different stores all to point to the resource locator "https://beer-ad.com". As this website is accessed through beacons across the country, the merchant will of course know general statistics about the success of their promotion. However, through further implementation of a source identifier feature as disclosed herein, each click-through will arrive with a unique beacon ID appended to each access that not only gives confirmation that the access originated from a beacon, it provides the exact origin of each access.
With the feature implemented, the destination URL looks like:
https://beer-ad.com?physource=abc123 for access through one beacon, and:
https://beer-ad.com?physource=xyz456 for access from another. With such information, the retailer will be able to see which store has the most accesses, or which areas of the country.

[0079] In embodiments as disclosed herein, a system and method may enable or provide for additional extensions or query variables, as may be of value to a retailer or other content source.
As one example, the hosted server may coordinate with beacon browsers to implement a GMT
date/time stamp (e.g., using a query variable "phytime") of the initial beacon scan. Accordingly, a retailer may be able to calculate the time delay between a person's initial scan of a URL (i.e., when they were known to be present at the beacon location) and their actual selection and access to the destination URL. A lengthy delay will typically indicate saved or shared access to a URL, which is valuable marketing information when combined with the location of the original access.

[0080] In an embodiment, the combination of a source identifier (e.g., using query variable "physource") and a time identifier (e.g., using query variable "phytime") may be used to create a unique transaction identifier. This unique transaction identifier may be stored in association with the hosted server and may for example be implemented to stop multiple consumers from getting the same promotion, or forwarding a link to a promotion to consumers that are not present and otherwise eligible for a promotion. If a promotion is of real value, a user may request the website to validate their transaction identifier (e.g., "physource+phytime") via the host API, wherein if the transaction identifier does not exist in the historical record (or if it has already been used), then they are denied. Effectively, through the addition of these query variables, the host system has been able to transfer intelligence to a hosting web server through the URL, including the states of Location and Presence.

[0081] In certain embodiments, where for example it may be the case that more than one person is near the same beacon, and scan in the same second, the host server may itself or otherwise in coordination with a beacon browser add a minimal amount of time or merely a number of additional decimal places (e.g., .000 ms) to the time (or a duplicate counter) such that a unique transaction identifier is made available for each and every scan transaction.
Multiple appearances of the same transaction identifier, at times increasingly distant from the original access, may be used to track the later reference or sharing of a resource locator such as a web URL, as opposed to its access from someone physically present. When URLs which contain this transaction identifier are accessed, then multiple later accesses from this original access can be tracked, thus potentially telling marketers which promotions are most shared.

[0082] As another example, a user selectable campaign identifier (e.g., query variable "phycampaignID") may be appended to a source identifier or the like. Content owners may accordingly be able to choose a campaign identifier variable to be appended to destination content messages associated with all beacons designated as associated with a campaign, so that they can quickly track those accesses in addition to the location of the originating access.

[0083] The hosted server may also or otherwise be configured to automatically generate a unique coupon (offer) variable (e.g., "phycouponID") for each access. Accordingly, when the coupon variable is required to be validated against the unique transaction identifier, the content owner or merchant may be assured that the offer can only be used by consumers who were actually present.
In an exemplary embodiment, the system for each instance of the URL being accessed with a unique coupon variable will be able to display that unique coupon code, and retailers will be able to know how many codes were issued and redeemed.

[0084] Generally stated, a hosted server and associated beacon browser (e.g., a conventional browser or SDK-implemented mobile app with browser capabilities) as disclosed herein leverages centralized administration of beacon transmissions and interactivity to add variables to content URLs that are valuable in their own right, and are more valuable when used in combination, or when used with the host API to retrieve additional user-designated and hosted information.

[0085] As previously noted, websites currently have embedded content that is displayed by a browser upon search. In an embodiment, a system as disclosed herein may further enable the implementation or creation of proxy (i.e., "shadow") websites which may be associated with one or more destination websites and reside on the hosted server. These proxy websites may be in a position to control a consumer's interaction with a website, at least up until the time that the destination website is actually selected. When a beacon browser (e.g., Google Chrome) scans a physical web beacon configured in accordance with or otherwise compatible with features and parameters as disclosed herein, it queries the hosted server. Originally, the hosted server would act as a redirect server, and would return the destination URL, whereupon the beacon browser would retrieve information (such as, e.g., the website's title, favicon, and description) from that destination website. Instead of the hosted server returning the destination URL, the shadow website on the hosted server in accordance with the exemplary embodiment disclosed herein may hold the connection and return dynamically set information (e.g., title, favicon, description) which are all easily updated by the customer on the host dashboard. When the shadow website is actually selected, the host will then redirect to the final destination URL (via, e.g., a JavaScript window location set, or via HTML5 http refresh with content set). In an embodiment, the host may be directed to return the URL of a proxy website to the browser, wherein upon that URL being selected, instead of the javascript initiating a redirect to a new URL, it will initiate an action such as launching an SMS client and prepopulating a message and destination telephone number.

[0086] There are other foreseeable advantages to this approach beyond enabling dynamic control of the information (e.g., title, favicon, description) associated with a proxy website, independent of the underlying destination website. One such advantage may be that the host will be able to report click-through statistics to the website owner, which otherwise may be unavailable for the reason that browsers do not conventionally make a second call to the host or administrator when a customer selects a scanned destination URL.

[0087] Another advantage is that a website owner may be able to clearly distinguish traffic generated from the hosted server and beacon network, as opposed to from other sources.

88 PCT/US2016/056427 [0088] Yet another potential advantage may be that a shadow website as disclosed herein can monitor browser activity or otherwise implement devices and objects such as cookies which enable control of the destination content based upon a user's profile.

[0089] In accordance with various embodiments as disclosed herein, the web browser may be configured to append information to the URL received from the beacon to be interpreted and acted upon by the UMS server. The appended information may include variables for adding contextual information about the beacon scanning event. For example, appended variables may include a unique customer identifier, an application identifier, user-selected preferences, etc.

[0090] In an embodiment, the beacon browser may add the appended variables to the beacon URL
to identify uniquely an associated application such as the beacon browser. For example, if a beacon URL is http://phy.net/abc123, the beacon browser may append a unique application identifier such as phyApp=377647a292333 (sample variable name and content), thereby generating a URL of http://phy.net/ABC123?phyApp=377647a292333.

[0091] In an embodiment, the core functionality of the beacon browser can be encapsulated in a Software Development Kit (SDK), which in turn, may be incorporated into a mobile app, thus giving that app the functionality of a beacon browser. Appended variables may be defined in and applied by the SDK, thereby allowing a plurality of applications and beacon browsers to interact with the UMS and the Physical Web in accordance with predetermined criteria, and thus making proximity content visible simultaneously in apps and browsers.

[0092] Various different variables can be appended by the beacon browser or SDK to add contextual information to be sent to the UMS server. For example, in a beacon interaction where a customer is purchasing tour tickets via a beacon interaction, the beacon browser may append "phyTour=child" (sample variable and content) to describe the type of tour the user has selected.
Other example variables may identify individual retail stores, identify specific users, indicate user application selections, indicate user-selected preferences on the beacon application, and the like. A
plurality of variables may be used, such as "phyTour=child" and "phyUser=VIP2A49." The beacon browser may combine a plurality of variables into a single, truncated URL
suffix such as "phySDK=Aj501fj3" that can then be interpreted by the UMS server as its constituent variable parts.

[0093] By appending browser-based variables, the beacon browser can send contextual information unique to the transaction to the UMS server, enabling greater intelligence in retrieving and returning personalized content. Whereas the URI from the beacon identifies a user's location and proximity, beacon browser variables identify the user and the user's selected preferences. This allows the UMS server to determine not only the user's proximity to a given beacon and query content based upon that interaction, but also to add all of this information to the destination URL
so as to allow customization of content based on user preferences set in the beacon browser application. Variables added to the beacon broadcast during the interval when that transaction is handled by a browser, as opposed to variables added at the beacon level or at the UMS level, are particularly valuable for their ability to identify the user of the app and the user's preferences, whereupon this information may be used by the UMS to determine the content returned to the customer, or these variables may be appended to the destination URL for further processing by a different content management system.

[0094] A user may specify preferred brands or specials at the browser/SDK
level, whereupon beacon-associated content can then be prioritized and returned in accordance with those preferences. For example, a user may specify that they are interested in promotions related to diabetes in an app making use of the SDK described herein, and that SDK can append the diabetes preference to the URL, thus enabling content so identified to be prioritized to that user.
Alternatively, information known about a customer may be automatically appended by the browser such as the user's device type. For example, for users of Android devices, content associated with or specified for Android devices may be returned instead of content associated with or specified for Apple devices (e.g. Google Play Store links as opposed to Apple App Store links). In a further example, a user who has specified a preference for food specials over drink specials may receive information pertaining to food specials and no longer receive content about drink specials.

[0095] After reading the beacon URL and appending application-specified variables, the beacon browser broadcasts the combined URL to the UMS server. The UMS server then interprets the beacon-based suffix string separately from the browser-based suffix string.
The UMS processes the browser-based suffix string to determine relevant information therefrom.
Relevant information may include instruction information associated with content retrieval, where the suffix string modifies the content that would otherwise be retrieved via the beacon URL. For example, the suffix string may request a different type of page be returned, whereby the UMS server will return a different URL than that it would have returned in accordance with the URL beacon standing alone. In certain embodiments, relevant information may include non-content-based contextual information such as transactional information or analytics, e.g. time, application state, phone state, transaction history, etc. This non-content-based contextual information may be valuable for content providers as consumer analytics.

[0096] The UMS server directs the beacon browser to or otherwise makes available for user selection a content server associated with the beacon URL and in accordance with any instructions provided via the browser-based suffix string. In certain embodiments, the UMS
server may retrieve the destination URL associated with the beacon URI component of the received URL and then append query variables onto the destination URL, and these appended query variables may be the variables added by the browser, thus transferring them to the destination content server. These embodiments are advantageous in part because when the destination URL is shared by the user with other individuals, the unique query variables are retained, allowing the UMS server to track how, when, by whom, and in some cases to whom the information was shared. Such granular information is particularly valuable to marketers in terms of tracking content popularity and visibility.

[0097] In some embodiments, information retrieval may be performed by the beacon browser in association with a combination of beacon URL information and user preferences.
For example, the beacon browser may cache information in advance based upon predefined or heuristic instructions, such as where a user frequents certain beacons or when proximity to one beacon instructs the application to cache certain information. This form of caching may be particularly useful where Internet access is spotty, weak, or nonexistent. For example, for a user who purchases a tour that goes through an area with poor data signal, the beacon browser may cache certain content associated with one or more beacons on the tour and in accordance with the specifications selected at the preliminary beacon. In said example, the user may have purchased a child's tour ticket, whereupon the beacon browser may cache tour information in advance and to be retrieved at certain beacons placed throughout the tour where internet access is known to be good. By caching this information, the beacon browser may return content based upon subsequent beacon proximities without having to send and retrieve information to and from the UMS.

[0098] Other actions that would be determined by the UMS server may be performed by the beacon browser. For example, the UMS may enable a beacon owner to change the distance at which the beacon becomes visible to consumers.

[0099] In an embodiment, a proprietary beacon browser may enable a user to access certain secure or private content associated with the proprietary beacon browser and not others. In this manner, users browsing via specific applications may receive unique content not accessible to other beacon browsers of a different type. For example, users of a branded retail application may receive content such as coupon codes or promotional specials not accessible to users of a generic beacon browser, and avoid viewing content not affiliated with the retailer. Because the beacon URLs are universally available, the same beacon message broadcast could return different content to an open browser than to a proprietary browser.

[00100] Proprietary browsers further allow for various types of Physical Web applications beyond dynamic web content access. In certain embodiments, the beacon browser may append a security key in addition to other variables. The appended key may be the same security key associated with the beacon or may be an independent key. For example, the security key may be appended in association with a particular user who has used login credentials with the beacon browser. Inclusion and detection of this key may enable the UMS server to return secured content.
A proprietary browser and key may enable an authorized user to access VIP
content not available to users accessing the same beacons without a security key. This content may be further secured by making the key single-use, such that copies of the information sent by the secure browser will not also return the private content a second time. In another example, a security guard may be able to check into locations automatically by walking near specific beacons with the proprietary browser enabled.

[00101] One problem with beacons of any type is that they are difficult to deploy and manage in scale. When there are hundreds or thousands of identically looking devices together in large groups, it is difficult to organize them. When they have individual, permanent ID's, it becomes easier to identify individual beacons, and to keep them organized. It also becomes possible to deploy them randomly and then have the individual installers set up their location and organizational information, thus distributing the organizational task across multiple installers. But there is still complexity to his task because the individual installers have to have log-in privileges to the installation app or management platform, and they have to have basic instruction on what data needs to be defined and recorded for each installed beacon. If, for example, 2,000 beacons were deployed to 2,000 different store locations in a retail chain, one would effectively need 2,000 different installers to have the capability of logging into an installation app, or to a platform dashboard to define the actual installed location and store number of each beacon in order to later enable unique metrics to be collected for that beacon or for its content to be properly managed. It would therefore be desirable to have a methodology for beacons to effectively "self-install", whereby the expense of dispatching trained installers can be avoided, and where the task of managing log in credentials of thousands of temporary installers can be avoided.

[00102] Embodiments of a system disclosed herein may enable a simplified deployment methodology for beacons where a beacon's broadcast are directed to self-install web pages, accessible by browsers. In such embodiments, the beacon is effectively announcing itself on an openly accessible web page and requesting that its location information be defined on that web page by someone nearby. Upon entry, this location information can be stored by the UMS, for later use for metrics or content management, and then the beacon can revert to broadcasting the content for its intended end users or the public at large. For example, if a beacon's ID is "ABC123", and the marketing entity deploying it wants to manage beacons and their marketing content by "store type" and "store number", then beacon "ABC123" can initially broadcast an installation web page titled "Beacon Number ABC123" followed by two requests for information, such as "please enter the store type (e.g. Target or CVS) ______________________________________ " and "please enter the store number _______________________________________________________________________________ _ ." With this approach, any store employee can place the beacon in a desired section of the store, and can access the beacon's self-install page with a browser, whereupon the critical information needed to manage the beacon is simply captured. This embodiment takes advantage of each beacon's unique ID, of the capability of an associated UMS to control the content broadcast by a beacon, and of the ability of that content to be accessed by a universal browser.

[00103]
In an embodiment, the UMS may add a simple security code to the self-install page, for example a 3-digit PIN, such that the store personnel installing the beacons will have to enter this PIN in order to be able to enter the desired installation information.
This simple security PIN
can be applied across all of the many beacons in a deployment to make sure that informed employees are entering the installation information.

[00104]
In another embodiment, these self-install web pages may be made dynamic, such that the information to be collected is defined in the UMS by the beacon owner, thus simplifying the installation process by only collecting only the exact information needed for each installation or promotion. For example, if all that is relevant to a deployment is the store number, then the self-install web page will only request this one piece of information.

[00105]
In another embodiment, the beacon's owner may be enabled to reinitiate the self-install feature at any time, either for groups or for single beacons. For example, if 1000 beacons are installed for a certain 90-day promotion, these beacons may be collected at the end of that promotion and then redeployed. A new instruction to self-install will cause the previous location information to be deleted and new self-install web pages will be generated for broadcast by the beacons to collect the location information needed for the new promotion.

[00106]
In another embodiment, the USM will be able to schedule a group of group of beacons to enter self-install mode, will be able to automatically lower the viewing range of beacon when in install mode to keep installation pages from being seen by distant persons, and to stop the collection of metrics during install mode to keep these accesses form skewing any collected marketing metrics.

[00107] In another embodiment, when beacons broadcast both iBeacon and Uribeacon protocols (including Eddystone-URL), a self-install web page could be used to self-install iBeacons, where the web page is used to associate unique iBeacon major and minor identifiers with the collected location information.

[00108] 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 herein, and may further store information corresponding to an asymmetric key pair 114 or the like for beacon authentication.

[00109] Referring to Fig. 6, an exemplary embodiment of a system 600 as disclosed herein may include a beacon 602 configured to broadcast a URL 604. The URL 604 may be comprised of at least a domain address component 606 and a unique beacon ID 608, wherein the beacon ID 608 is a unique identifier for the associated beacon 602. The URL 604 may comprise an access protocol and hosted server (e.g. http://YYY.net) as the domain address component 606 and a PhylD (e.g.
"ABC123") as the beacon ID 608, such that in combination the two form a complete URL (e.g.
http://YYY.net/ABC123).

[00110] The beacon 602 is configured to broadcast the URL 604 to one or more proximate client devices 610 configured to receive the broadcast. In certain embodiments, the client device 610 may be a mobile device such as a mobile phone, netbook, or laptop. In certain embodiments, the beacon 602 may be geographically fixed, whereas in other embodiments the beacon 602 may be geographically mobile. The broadcast may be in the form of various wireless radio transmission protocols such as Bluetooth, RFID, and similar broadcast forms and frequencies including even for example data encoded audio or light signals, which the client device can interpret in accordance with its radio sensors.

[00111] Upon receiving the broadcast, the client device 610 may in some embodiments be configured to append a suffix 612 to the URL 604, thereby generating an appended URL 614. The client device 610 may execute instructions from a browser or application, said browser or application configured to append a suffix to one or more URLs 604 broadcast by beacons 606. In some embodiments, the suffix 612 may comprise one or more information tags.
The information tags may embody additional contextual information to be added to the URL 604.
Additional contextual information may include, for example, software settings or sensory data such as: user ID, application ID, user query, user settings, software setting state, phone state, date and time, temperature, acceleration, direction, light levels, and the like. Each information tag may pertain to a single setting or multiple settings. For example, the browser or application may be configured to generate a string unique to a plurality of settings and append that string as the suffix 612 to create appended URL 614 (e.g., "http://YYY.net/ABC123/fj893H5jzXR"). In alternative embodiments, the browser or application may append information tags for each variable (e.g., http://YYY.net/ABC123/?PhyUser=john.doe&PhyApp=12843&query=vegan +menu +options"). In further alternative embodiments, the appended URL 614 may be the same as the URL 604 when the suffix 612 is empty or otherwise not added.

[00112]
Upon appending the suffix 612 the client device 610 queries the appended URL 614, wherein the appended URL 614 directs to a UMS server 616. The UMS server 616 interprets the submitted URL request and processes the constituent components of the appended URL 614. The UMS server 616 may determine the domain address component 606, the unique beacon ID 608, and the one or more information tags of the suffix 612 and interpret those components in reference with a content server 618. In some embodiments, the content server 616 and UMS
server 616 may be the same. In some embodiments, the UMS server 616 may process the information tags which pertain to logistical or metric information and remove those tags from the submitted URL request, thereby generating a new URL for accessing content associated with at least the hosted beacon 602 and, as determined by the UMS server 616, associated with the one or more suffix tags. For example, in an embodiment the UMS server 616 may reference a set of content associated with the beacon ID 608 and determine a subset of that content based upon one or more of the information tags of the suffix 612, where the information tags provide contextual information for the content.

[00113]
In response to a content request from a device, the UMS server 616 generates a destination URL 620, with the appended contextual variables, for the determined content on the content server 618 and delivers that destination URL to the client device 610.
The client device 610 may submit a plurality of content requests to the hosted server 616 where for example broadcasts from numerous beacons have been received by the device with respect to a single location. In either case, the hosted server 616 may return one or more destination URLs 620 to the device 610 in accordance with the one or more content requests. The destination URLs 620 may be presented via the device as a selectable list of tokens representing content options, in the common form of an internet search display, wherein upon selection of any one particular token/ content option, content may be accessed from the respective content server for that destination URL. The selectable tokens incorporate visual information for display on the search display, which may include for example destination website metadata (e.g., pertaining to images, favicons, titles, descriptions and the like), and may further comprise a hyperlink URL that is accessed when the user selects the associated token. This hyperlink may be third party or it may be at the hosted server.
Accordingly, the browser or application on the client device 610 receives contextually specific content via the destination URL 620 in reference to the proximate beacon 602.

[00114] In some embodiments, the UMS server 616 may include additional information tags on the destination URL 620 whereby the application or browser on the client device 610 is configured to read, interpret, and act upon the added information tags. For example, the destination URL 620 may contain information tags which provide instructions for rendering the content, which authenticate content in accordance with a security key, which instruct the application to perform certain actions, and the like.

[00115] In certain embodiments, the beacon ID 608 may comprise in whole or in part a rotating set of beacon IDs over time. In such embodiments, the beacon may be configured to periodically change the beacon ID, or in certain embodiments relevant portions of a beacon ID, to be broadcast in accordance with software instructions. For example, such a "dynamic beacon ID"
as referred to herein may be incremented or transformed periodically in accordance with a cryptographic algorithm, such as a hash, such that the hosted beacon 602 does not retain a singular beacon ID for more than a set period of time. In other embodiments, a plurality of beacon IDs may be associated with the device, wherein the beacon ID to be broadcast at a given time is algorithmically selected. In an embodiment, the beacon ID may be an eight-byte key. In certain embodiments, the dynamic beacon ID 608 may be supplemented with additional information such as for example a battery state for the hosted beacon 602 (i.e., producing a "dynamic beacon URL").

[00116] Referring now to Fig. 7, an exemplary method 700 as disclosed herein for retrieving content as referenced above and particularly in regard to Fig. 6 may be described as follows. The method 700 may be characterized in part wherein a client device is configured to perform a first step 701 wherein the client device detects a URL broadcast by a beacon. The client device may detect the URL broadcast via one or more various sensors such as proximity-based wireless protocols such as RFID, WiFi, Bluetooth, and the like, the client device sufficiently proximate to the beacon to detect the broadcast.

[00117] The method 700 may further be characterized in part by the step 702, wherein the client device, via an associated browser or application, appends zero, one, or more variables to the received URL in accordance with software instructions therein, thereby generating an appended URL. In some embodiments, the appended variables may embody contextual information about the client device or client state, or device user wherein the beacon URL transmits information pertinent to the beacon (e.g. PhylD, battery state, location) in the URL and the client device appends device-based information such as user settings, user input, device state, software state, and proximity to the beacon. In an embodiment, the client device may append a series of variables, wherein each variable corresponds to an individual quantum of information; alternatively, the client device may append a variable string, wherein the string represents a quanta of information.

[00118] The method 700 may further be characterized in part by step 703, wherein the client device queries a UMS server via the appended URL. The client device may be connected to the UMS server via a communications network. In some embodiments, the UMS server may be hosted at the location specified in the broadcast URL, whereby the appended variables provide the UMS
server information to be processed.

[00119] The method 700 may further be characterized in part by step 704, wherein the UMS
server identifies the constituent components of the URL and obtains contextual information therefrom. For example, the UMS server may identify the base URL link which directs the client device to the UMS server location on the communications network (704a). The UMS server may further identify the beacon ID (704b) and determine from a database the unique beacon, beacon location, and controlling account to which that beacon is assigned. In some embodiments, the beacon URL may contain information pertaining to the battery state of the beacon, whereby the UMS server identifies the battery level remaining in the beacon. The UMS
server may further identify a public security key (704c) and a continuously changing key which is based on a private security key stored upon the UMS server as an asymmetrical key pair verification method. In some embodiments, the public security key may be a component of or may be itself the beacon ID; in alternative embodiments, the public security key may be an appended variable.
The UMS server may further identify from the beacon ID the one or more appended variables (704d).

[00120] The method 700 may further be characterized in part by step 705, wherein a hosted content server or third party content server may use the components identified in step 704 to return more relevant content to the client device. In one embodiment, the UMS
server may internally process certain components (e.g., battery state) while appending or embedding other components with respect to a destination URL, wherein the appended variables may provide delimitations for the content server as to a subset of the associated content.
For example, where an appended variable states the browser type or designated application being used on the client device, the UMS server may pass the appended variable on to the content server to facilitate downstream content selection and delivery. In embodiments wherein the UMS
server is the content server, the UMS may use the appended variable to help determine an arrangement of content compatible for display via the stated browser. In some embodiments, the UMS
server may process certain components and/or variables irrespective of the content to be retrieved, wherein such components and/or variables provide non-content-based information such as marketing metrics.
For example, the UMS server may separately process a timestamp of the original access, a phone activity state, a user ID, or other such information which will not affect the selection, curation, or display of content to be retrieved.

[00121] The method 700 may further be characterized in part by step 706, wherein the UMS
server designates a destination URL for the content to be retrieved in accordance with the determinations made in step 705. The destination URL may in some embodiments be a unique URL
for the display of the specific set or subset of content determined. In some embodiments, the destination URL may direct to a third-party content management server. In certain embodiments, the UMS server may further append variables to the destination URL as contextual information to be processed by the third-party content management server. The appended variables may in some embodiments provide non-content information for purposes of marketing and metric information.

[00122] The method 700 may further be characterized in part by step 707, wherein the UMS
server redirects the client device's original URL request to the destination URL by returning the destination URL to the client device, thereby providing the client device the content determined in step 705. In some embodiments, the UMS server may further append variables to the destination URL as contextual information or instructional information to be processed by the client device's browser or application. In various embodiments, the variables appended to the original URL by the beacon or the browser can be transferred to the destination URL by the UMS, thus effectively transferring them to the content server where they have the greatest usefulness.

[00123] Fig. 8 may in some embodiments be interpreted in conjunction with Figs. 6 and 7. A
URL security method 800 begins at a first step 801 when a hosted beacon references an ID
rotation algorithm to dynamically determine a beacon ID to broadcast, the algorithm associated with the periodic rotation of beacon IDs. In certain embodiments, the ID
rotation algorithm may be partially or wholly defined by a beacon owner; for example, a beacon owner may be able to specify the periodic frequency by which an ID rotates. In an embodiment, the ID
rotation algorithm may be a cryptographic algorithm, such as a hash value, which securely increments the ID periodically in accordance with an algorithmic key. In an embodiment, the dynamic beacon ID
may be generated based upon a private key embedded into each beacon and known to the UMS, as previously discussed. The dynamic beacon ID accordingly includes or embodies an 8-byte public key, wherein the public key may be authenticated in accordance with the server-stored private key, the two keys forming an asymmetric key pair for server-side authentication from among a plurality of dynamic beacon IDs available to the respective beacon.

[00124] The method 800 continues in step 802 when the beacon determines in accordance with the ID rotation algorithm which beacon ID to broadcast for a specific duration and broadcasts that dynamic beacon ID. Each beacon ID in the series of beacon IDs to be broadcast over time may be temporarily broadcast for an algorithmically specified or fixed duration of time before proceeding to the next beacon ID in the series. The progression of beacon IDs may be preferably seemingly random, though algorithmically defined, such that a person cannot distinguish the incrementation method or identity of subsequent beacon IDs to be generated.

[00125] The method 800 continues in step 803 wherein the beacon generates and broadcasts a beacon URL which may take the form of a base URL and suffix, such as:
https://phy.net/EID_URL+Batt. For example, a dynamic beacon URL may be https://phy.net/A046G5SQBA35, wherein "https" is the transfer protocol, "phy.net" is the URI
base, A046G5SQ is the current beacon ID, and BA35 is the battery state. In said example, the beacon ID may change periodically in accordance with steps 801 and 802, and the battery state may change in accordance with the status of the battery (e.g. charge, capacity, health, etc.) of the beacon battery; accordingly, the URL broadcast by the host beacon changes periodically and continuously. Steps 801 through 803 may be performed continuously. In certain embodiments, it may be understood that variables associated with condition sensors such as for example the battery state may be optional in nature or simply unavailable for some applications.

[00126] In step 804, a proximate mobile device receives the broadcast beacon URL, interprets at least a portion of the beacon URL as a destination URL for a browser or software application, and queries the URL in said browser or software application. In certain embodiments, the host beacon may append suffix information to be used by the UMS and/or further appended by the mobile device's software application in accordance with Figs. 6 and 7 herein.

[00127] In step 805, the UMS receives the mobile device's URL query and identifies the constituent components of the beacon URL, including at least the dynamic beacon ID. In step 806, the UMS compares the dynamic beacon ID to a UMS-ID registry to validate the dynamic beacon ID
as authentic. If the received dynamic beacon ID matches a valid registry entry associated with a specific beacon, then the UMS will convert the dynamic beacon ID into a specific beacon ID (step 806). In certain embodiments, the UMS may continue in accordance with method 700. If the dynamic beacon ID does not match a valid registry entry, the UMS may redirect the browser or application to a URL, or direct the browser or application to content, associated with non-valid entries. For example, if an invalid or outdated dynamic beacon ID is received, the UMS may direct the browser to a page that states that the information a user is seeking has expired, or to a different, possibly limited set of content. In certain embodiments, the registry may be updated in accordance with beacon owner preferences such that changes to the beacon ID
algorithm for dynamic beacon ID key generation will be reflected in the registry key for comparative purposes. In an embodiment, a beacon owner may update the registry through a secure web portal to the UMS.
Said web portal may, for example, be the administrative web portal 400 as described in Fig. 4.

[00128] 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.

[00129] 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 BluetoothTM 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). The term "beacon" may indeed be attributed broader scope than normal with respect to one of ordinary skill in the art, but is intended herein unless otherwise expressly stated to incorporate alternative devices implementing equivalent location based technologies such as for example near field communication (NFC) protocol.

[00130] As used herein, the term "beacon browser" may at least refer to web browsers or SDK-implemented mobile applications operable with respect to a user computing device, and which are configured when enabled or otherwise operating on the computing device to continuously or user-selectably scan for and detect wireless messages including URLs transmitted by beacons proximately located thereto, in a manner understood by those of skill in the art. Such beacon browsers may typically be configured to display information corresponding to destinations, content and/or objects associated with the scanned beacons, and further to enable user selection, execution and/or linking to such destinations, content and/or objects. In some embodiments, the beacon browser may refer to a non-browser computer program such as a mobile phone application configured to display information on a display.

[00131] 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.

[00132] 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.

[00133] 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.

[00134] 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 (22)

1. A system comprising a plurality of beacon transmitters, each of said transmitters configured to broadcast wireless messages comprising a Uniform Resource Locator (URL) to client devices proximate to said transmitters and configured for interacting with the broadcast messages, and a hosted server, the system further characterized in that:
each of the beacon transmitters (102; 602) are configured to generate a unique identifier associated with the respective beacon transmitter, and to broadcast the wireless messages (604) with the URL comprising a domain (606) associated with the hosted server and the identifier (608);
the client device has a hosted SDK-implemented mobile application residing thereon, and configured upon receiving a broadcast message from a beacon transmitter to generate a request to the hosted server (202), the request comprising a URL with the unique identifier and one or more contextual information tags appended by the mobile application; and the hosted server is configured to generate a hosted user interface (400) enabling designation by an authorized user of a destination URL (405) comprising content to be accessed by client devices proximate a particular beacon transmitter, upon receiving the request from the client device, to process the one or more contextual information tags appended in the URL of the request, and to generate a return message to the client device comprising the designated destination URL (204) based at least in part on one or more of the contextual information tags.

2. The system of claim 1, wherein the hosted user interface enables designation by the authorized user of a plurality of destination URLs for a particular beacon transmitter, and wherein the hosted server is configured to generate the return message including visual metadata for display on the client device and associated with one or more hosted proxy websites further associated with the designated destination URLs, and wherein the user interface generated by the hosted server for the authorized user further enables dynamic adjustments to the visual metadata associated with the proxy website.

3. The system of any one or more of claims 1 and 2, wherein the contextual information tags appended by the mobile application comprise variables associated with unique user identification and user-selected preferences set in the mobile application, and wherein the hosted server is configured to generate the return message including one or more destination URLs based at least in part on one or more of the identified user and the user-selected preferences.

4. The system of any one or more of claims 1- 3, wherein the contextual information tags appended by the mobile application comprise a security key associated with a particular user having login credentials with the mobile application, and wherein the hosted server is configured to generate the return message including a destination URL with secured content, based on the identified user and the security key.

5. The system of claim 4, wherein each security key is single-use.

6. The system of any one or more of claims 1- 5, wherein the appended contextual information tags from the mobile application comprise a first set of appended contextual information tags, and the hosted server is further configured to append a second set of one or more contextual information tags to the destination URL in the return message to the client device, and the hosted SDK-implemented mobile application is effective to provide access to content based on one or more of the first and second sets of contextual information tags and the destination URL in the return message.

7. The system of any one or more of claims 1- 6, wherein the hosted server is further configured to enable an administrative user via the hosted user interface to define a proximity setting (404) and one or more content tags (403), 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.

8. The system of any one or more of claims 1- 7, wherein the hosted server is further configured to enable an administrative user via the hosted user interface to set up and pre-designate alternate destination URLs for a beacon and simply swap between them, or to automatically swap between them according to a predetermined schedule (406).

9. The system of any one or more of claims 1- 8, wherein access to the content is provided via one or more of a hosted web portal and redirection to a third party URL
designated via the user interface.

10. The system of any one or more of claims 1- 9, wherein the request comprises a first request from the client device, and wherein the hosted server is configured, responsive to the first request, to coordinate with the mobile application executed by the client device to generate a plurality of selectable tokens associated with content designated for the particular beacon transmitter, and responsive to a second request from the client device associated with a token selection, to provide access via the mobile application to the respectively designated content.

11. The system of claim 10, wherein each selectable token comprises a hyperlink to a destination URL that is accessed upon selection of the respective token and visual information associated with the hyperlink URL, and the user interface generated by the hosted server for the authorized user further enables dynamic adjustments to the visual information associated with the hyperlink URL.

12. The system of any one or more of claims 1- 11, wherein the hosted server is further configured, responsive to the request, to generate a message string to the client device comprising the destination URL and the unique identifier for the beacon transmitter, wherein the unique identifier for the beacon transmitter is appended to the URL as a query variable or a hash extension.

13. The system of any one or more of claims 1- 12, wherein the hosted server is further configured:
responsive to the request, to generate at least a first time stamp, wherein a time delay is calculated between an initial scan of the beacon transmitter and access to the designated destination URL, and to generate a unique transaction identifier for each first time stamp in combination with a respective beacon identifier.

14. The system of any one or more of claims 1- 13, wherein the user interface further enables designation by the authorized user of a campaign identifier associated with the designated destination URL, and The hosted server is further responsive to the request to generate a message string to the client device comprising the URL, the unique identifier for the beacon transmitter, and the campaign identifier.

15. The system of any one or more of claims 1- 14, wherein the user interface further enables designation by the authorized user of an offer identifier associated with the designated destination URL, and the hosted server is further responsive to the request to generate the message string to the client device comprising the URL, the unique identifier for the beacon transmitter, and the offer identifier, and responsive to a second request from the client device, to generate a unique offer variable for validation against the respective transaction identifier.

16. The system of any or more of claims 1- 15, wherein the hosted server is configured in a first mode to return the destination URL as a first destination URL in response to the wireless messages comprising the host URL and the identifier for the respective beacon transmitter, wherein the hosted server is configured in an installation mode associated with the unique identifier for any one or more of the plurality of beacons, and further responsive to a self-install content request including the unique identifier associated with the one or more respective beacons, to return a second destination URL for a hosted self-install interface requesting installation information, to capture installation information entered via the hosted self-install interface and displayed on a client device proximate a respective beacon in installation mode, and to revert to the first mode upon capture of the entered information by the server.

17. The system of claim 16, wherein the hosted server is further configured to remotely enable an administrative user via the hosted user interface to determine installation information to be captured during the installation mode, and to selectively re-initiate the installation mode for one or more of the plurality of beacons.

18. The system of any one or more of claims 1- 17, wherein each of the beacon transmitters are configured to dynamically generate a unique identifier associated with the respective beacon transmitter, and to broadcast the wireless messages with the URL comprising a domain associated with the hosted server and the dynamically generated identifier.

19. The system of any one or more of claims 1- 18, wherein the plurality of beacon transmitters are further associated with one or more respective condition sensors (112), each of said transmitters configured to broadcast wireless messages having a URL further comprising data representative of one or more outputs from said condition sensors.

20. The system of any one or more of claims 1- 19, wherein each of said transmitters comprises a respective asymmetric key pair (114), and is further configured to generate a different unique identifier for each broadcasted message using the asymmetric key pair (301), further wherein the hosted server is configured to authenticate one or more beacon transmitters in accordance with a 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 (302- 304).

21. The system of claim 20, wherein each of said transmitters is further configured to continuously generate different unique identifiers using the asymmetric key pair (801-806).

22. The system of any one or more of claims 1- 21, further comprising a presence detection function wherein the host server is configured to determine a location of a person accessing the destination URL as proximate to the particular beacon transmitter, and at a particular time.