Beacon cloud reputation service

A technique for determining the safety of the content of beacon transmissions. A user device extracts beacon identification information from a beacon transmission. The user device queries the beacon registry to obtain the targeted content. The user device provides the targeted content and beacon identification information to a validation service. The validation service evaluates the targeted content and the beacon identification information for safety. The validation service determines a score based on that evaluation and sends the score to the user device. The user device alerts the user or performs background actions such as suppression of transmission of beacon contextual data to other apps on user device based on the score.

TECHNICAL FIELD

Embodiments described herein generally relate to the identification of beacons and more specifically to the verification of the safety of the content transmitted by such beacons.

BACKGROUND ART

Bluetooth® low energy (BLE) was introduced as part of the Bluetooth® Core Specification version 4.0 adopted in June 2010. (“BLUETOOTH” is a registered trademark of Bluetooth SIG, Inc.) BLE was designed to support multiple profiles for wireless device communication. BLE was designed with the low power requirements, small size, low cost, and compatibility in mind.

One implementation of a BLE enabled device is a BLE beacon (beacon). Beacons are small devices that transmit via limited data payloads, serving various purposes. They are typically low-powered devices using BLE protocols, but as used herein, the term “beacon” can include other types of devices, including Near Field Communication (NFC) tags. Targeted applications include health and fitness, information presentation, and advertising. The devices present content in a payload to a client device, and the client device may act on that content.

Beacons interface with client devices by a well-defined protocol. The Eddystone™ protocol developed by Google Inc. is an example, as well as the iBeacon™ protocol developed by Apple Inc. These protocols define how to encode, decode, and transmit data from the beacon to the client device. Specific networking frames defined by the protocol specification contain different data. For example, the Eddystone protocol defines frames that contain Universal Identification (UID) information, which identifies the beacon. Eddystone also defines a frame type for Universal Resource Locator (URL) information, which includes information for determining the content the beacon is conveying or the content itself.

Beacon registries provide content for the client device upon receiving a BLE transmission from a beacon. Beacon registries are well known databases that contain content associated with a beacon. For example, upon receiving a beacon transmission, the client device may extract a UID associated with the beacon, and query the beacon registry using the UID as a key. The beacon registry queries content associated with that UID and transmits the associated content to the client device. Often the associated content takes the form of a website URL which is intended for use by the client device. Currently, the associated content is handled by the device without knowledge of the safety or the source of the transmission from the beacon. The beacon registry typically does not verify the content contained therein, so it is possible for the client device to access the content and be exposed to malicious data.

Expectations for the deployment of beacons are quite high due to the low cost of production and operation. Current projections predict that shipments of beacons will exceed four hundred million units by the year 2020.

DESCRIPTION OF EMBODIMENTS

As used herein, the term “a computer system” can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.

The term “machine readable medium” can refer to a single physical medium or a collection of physical media that together store data or instructions described as being stored on the medium.

FIG. 1depicts a block diagram100illustrating a system for receiving and determining the safety of beacon transmissions according to one embodiment.

Prior to the transmission of any beacon signals, the beacon114needs to be configured. A web app108typically provides an interface between the beacon114and a beacon registry104. The web app108provides the interface to input the beacon identification information into the beacon registry104, as well as to tie that beacon identification information to beacon content. One example would be for the beacon identification information to comprise a universally unique identifier (UUID) paired with a URL. The URL may be the address of a public or private beacon registry104. A public registry may take the form of a cloud based service, often administered by a different party than the one operating the beacon. The public registry provides an interface that is openly accessible by all beacon operators. A private registry differs from a public registry in that it has controlled access and only certain beacons, often defined by their UUID, may have access. Often the operator of the private registry is the same as the beacons seeking access. The combination with the URL with the UUID identifies a specific beacon114in the beacon registry104. Alternatively, the UUID may be used to identify a specific beacon114in a well-known beacon registry104if the URL is not present.

Upon creating an entry in the beacon registry104associated with the beacon114, the web app108may assign beacon content to the entry in the beacon registry104. Examples of the beacon content may include URL web links to product descriptions, advertisements, consumer surveys, etc.

Once the beacon114has been registered with the beacon registry104, the common usage pattern consists of a user device116receiving a transmission from a beacon114. The user device116extracts the beacon identification information, and queries the beacon registry104for the beacon content. The user device116then provides the retrieved beacon content to applications executing on the user device116. The beacon content is not verified for safety and exposes the user device to potentially malicious code.

The user device116may provide a level of safety from potentially malicious beacon initiated transmissions by utilizing a framework to support a validation service106.

Upon receiving a transmission from a beacon114, the user device116processes the beacon identification information in a validation agent112that operates with the validation service106. The validation agent112may operate as a part of the operating system (OS), middleware between the OS and the applications, or an application. The beacon identification information often includes raw information revealing hardware and firmware details of the beacon, telemetry information of the beacon, and manufacturing source. Additionally, the beacon identification information includes details used to derive data points about the beacon including data used to associate malicious data with the beacon, and data used to derive trustworthiness of manufacturing origin of the beacon. The validation agent112extracts the beacon identification information and utilizes one or more application programming interfaces110(APIs) to interface with the beacon registry104. In other embodiments, different beacon registries may use different APIs110. Similar to the web app108registering the beacon114with the beacon registry104, the APIs110interface with the beacon registry104. In some embodiments, the APIs110are utilized with the extracted beacon identification information, including UUIDs and URLs, to query the beacon registry104and retrieve the beacon content.

The beacon registry104, through the API110, sends the beacon content associated with the beacon identification information back to the validation agent112. The validation agent112acts as a verification gateway, and sends the resultant beacon content, beacon identification information, and contextual information to the validation service106. Contextual information includes a geo-physical location of the validation agent, the time the transmission was received, and a contextual location. A contextual location is further described by landmarks physically located nearby. For example, a beacon located in shopping mall, might have a contextual location of a mall, which implies that the beacon is contextually located in a retail environment. Contextual location may be determined by the validation agent112at the time when the transmission is received based at least in part on the geo-physical location, and previous beacon transmissions received.

The validation service106maintains a record of beacons114that have interfaced with user devices116executing the validation agent112. The validation service106catalogs information related to the beacon114. The validation service106may also catalog whether the beacon occupies a well-known geo-physical location, and any known historical activity with the beacon. If the beacon identification information does not exist in the validation service106catalog, it is added along with any beacon content and contextual information. In the querying of the catalog, the validation service106may maintain data relating to how many times a specific beacon is interfaced, and keep a safety history. In some implementations, historical activity of the beacon may age off, and a beacon's past malicious behavior may be purged.

The validation service106may compare the manufacturing origin as well as hardware and firmware versions may be used to determine trustworthiness of the beacon. For example, if a beacon is detected to be from a well-known manufacturing origin, however the firmware details appear suspect, the validation service106may record that data point.

The validation service106also may evaluate the beacon content. This involves evaluating the beacon content itself, and any additional content the beacon content may reference. For example, if the beacon content is a URL, the validation service106evaluates the URL character string itself, as well as the content of the website to which the URL points. The validation service106examines any content returned from the URL request searching for any potentially malicious code.

The validation service106also determines a beacon safety score. Alternately, in other embodiments, the beacon safety score may be implemented as a beacon danger score, where the scores are interpreted differently. In one embodiment, the score is a numerical value determined by the combination of results assigned to the evaluation of the content, as well as metrics derived from historical interactions with the beacon as logged in the catalog. For example, if a beacon has been accessed by many devices and developed a safe history in conjunction with a currently favorable evaluation of the beacon content, then the beacon safety score would be high. Alternatively, if the known safety history is low in conjunction with a current evaluation of the content as malicious, the beacon would receive a low beacon safety score. Finally, if a beacon has no known history in conjunction with a current evaluation as non-malicious, the beacon safety score may be midlevel, indicating caution to the user.

The validation service106stores any resultant beacon safety score in the catalog as a data point for future reference. The validation service106returns the beacon safety score to the validation agent112.

The validation service106may include at least one server118which facilitates the sending and receiving of information from the user device116, as well as the evaluation of the content provided to the validation service106from the user device116.

Coupled to the server118, is a database120. The database facilitates the historical data necessary to build a beacon safety history. Implementation of the database may vary from off the shelf database packages to custom developed systems.

The validation agent112may present the user with a notification indicative of the beacon safety score. For example, ranges of beacon safety scores may be represented by the validation agent112using colors similar to a traffic light, where green indicates safe, yellow indicates uncertainty or caution, and red indicates safe. Any desired threshold between ranges of score values may be used as desired, and may be configurable. Other techniques may be used to represent the beacon safety score, and do not have to be visual in nature. Audio notifications may be used to indicate the beacon safety score.

FIG. 2depicts a flowchart200illustrating a technique for receiving and determining the safety of beacon transmissions according to one embodiment.

Flowchart200represents a way of determining the beacon safety score as calculated by the validation service106.

The validation service106receives beacon identification information and the beacon content210. Generally, in its most simple form, this is information that is likely to uniquely identify a beacon. For example, a UUID extracted out of a beacon transmission and a URL for a corresponding beacon registry104may compose beacon identification information. It may also include additional contextual information as described above as well. The beacon content is the output from the beacon registry104query.

The validation service106identifies whether the beacon identification information identifies a known beacon220. In one embodiment, a database indexed on the UUID value may be used as a key. Upon querying the database with the UUID, the database returns an entry for the beacon if it is known, or optionally returns nothing or an indication that the beacon is unknown. The entry for a beacon may also contain other information relating to past queries for the beacon. The entry may include past beacon safety scores, times of queries, location of the beacon, and the beacon content itself.

The validation service106determines a safety level of the beacon content230. The beacon content string may be parsed to evaluate correct syntax. If the beacon content is a hyper transport protocol (HTTP) URL, it may be traversed in a web browser and the content of the HTTP response may be parsed to identify malicious scripts embedded in the response. In the case that the beacon content is not a web based URL, the validation service106may use an appropriate mechanism to evaluate the beacon content. For example, if the URL is a file transfer protocol (FTP) address, the validation service106may use a (FTP) application to evaluate the beacon content. The beacon content traversal may be executed in an isolated environment for safety purposes. The isolated environment may include a Trusted Execution Environment (TEE).

Additionally, the validation service106evaluates the beacon content for privacy concerns. The validation service106may evaluate content that would allow downstream beacon transmission applications to collect unauthorized private information. For example, this could include beacon content directing users to URLs that are not malicious on their face, however setting session cookies for user tracking. Subsequent applications may then utilize the session cookies to obtain unauthorized user information and profile a user. Another example would be the detection by the validation service106of beacon content indicative of an attempt to supply applications with beacon content designed to assist in the reset of the device's advertisement ID, or augment data associated with the device's advertisement ID.

The validation service106then generates a beacon safety score240. The beacon safety score may be a numerical value. In one embodiment, the numerical value is representative of whether the beacon is a known safe beacon combined with the evaluation of the beacon content. For example, if the beacon has a history of generating safe beacon safety scores, it may have a high value for the known safe beacon component. Additionally, if a beacon has a trusted manufacturing origin, and/or well reputed geo-physical location it may also be a known safe beacon. A well reputed geo-physical location is a location, as reported by the user device116, where beacon information stored in the validation service106indicate that surrounding beacons in the same geo-physical area are safe. If the beacon content associated with that beacon also is evaluated safe, then the beacon safety score would be the combination of those two high values. Alternatively, those two components may be returned to the validation agent112, where the validation agent112makes the determination on how to apply those values to alert the user to beacon safety. In another embodiment, the validation service106may store the beacon safety score as another metric for future evaluations of the beacon safety score or be used to modify an existing score, as keeping a running average beacon safety score.

Additionally, the validation service may store various metrics of beacon performance including rate of transmission individually or as an aggregate over multiple validation agents112.

The validation service106then transmits the beacon safety score back to the requestor250who originally sent the beacon identification information and beacon content at block210.

FIG. 3depicts a flowchart300illustrating a technique for generating a beacon safety score according to another embodiment.

Flowchart300represents a way of receiving a beacon transmission by a user device116and the processing of that transmission.

A user device116receives a transmission from a beacon in block310. This occurs across a beacon protocol (e.g. Eddystone). The transmission should include enough information to uniquely identify the beacon114and any beacon registry104with which the beacon may be associated.

The user device116extracts the beacon identification information from the beacon transmission in block320. Extracting beacon identification information involves processing the frames of the transmission and identifying which portions of the transmission identify the beacon. For example, UID and URL frames for the Eddystone protocol include information identifying the beacon and the beacon registry. Processing of the frames would require that the user device116extract a unique beacon identifier and registry information. In the Eddystone example above, the registry information would correspond to the URL frames. In the iBeacon case, the registry information would be a statically defined by the APIs110. Registry information may address both private and public registries. Additionally, the user device116computes additional contextual information around the reception of the transmission. This contextual information may include the geo-physical location, the time that the transmission was received, and the contextual location.

The user device116sends the beacon identification information to the beacon registry in block330. Utilizing the information extracted at block320, the user device116may properly identify the associated beacon registry104. The validation agent112may interface with beacon registry APIs to address and access the beacon registry104. For example, the URL frame mentioned above may contain the appropriate information to address a beacon registry104and the API would facilitate the query for the beacon based on the information from the UID frame.

The user device116receives the beacon content from the beacon registry in block340. The beacon content consists of the data that the beacon was implemented to convey. The beacon content may take the form of a URL to a desired website. For example, a beacon may be placed in a grocery store near a specific brand of soups. The beacon content returned by the beacon registry104would then be a URL directing the user device116to display a web page with more information on the specific brand of soups.

The user device116sends the beacon content and the beacon identification information to the validation service in block350. Upon reception of the beacon content, the user device116through a validation agent112currently executing, transmits the beacon content and the beacon identification information to the validation service106. As the validation agent112is the agent of the validation service's framework, the addressing as well as the mechanism for transport for the validation service106may be incorporated into the validation agent112. If the mechanism for transport fails, the validation service106, may not be available, which may necessitate the validation agent112to notify the user.

The user device116receives a beacon safety score from the validation service in block360. The validation agent112acts as an agent for or client of the validation service106and receives the beacon safety score. The user device116may now use the beacon safety score to indicate to the user the safety of the beacon. In one embodiment, the safety score may be used to implement a “traffic light” system indicating green for safe, yellow for caution, and red for unsafe. Alternatively, or in combination, the user device116may suppress any beacon transmissions with beacon safety scores not meeting a predetermined safety threshold. The validation agent112may additionally store transmission data from receiver applications, as beacon transmissions are forwarded to other applications.

FIG. 4depicts a flowchart400illustrating a technique for suppressing beacon transmissions according to one embodiment.

Flowchart400represents a way of receiving a beacon transmission by a user device116and the suppression of that transmission based on criteria.

A user device116receives a beacon transmission from a beacon410. This occurs across a beacon protocol (e.g. Eddystone). The transmission should include enough information to uniquely identify the beacon114and any beacon registry104with which the beacon may be associated. Alternatively, the transmission may include only enough information to identify the beacon, as long the registry information may be retrieved from the registry APIs110.

The user device116extracts the beacon identification information from the beacon transmission420. Extracting beacon identification information involves processing the frames of the transmission and identifying which portions of the transmission identify the beacon. For example, UID and URL frames for the Eddystone protocol include information identifying the beacon and the beacon registry. Processing of the frames would require that the user device116extract a unique beacon identifier and registry information. In the Eddystone example above, the registry information would correspond to the URL frames. Registry information may address both private and public registries. Additionally, the user device116computes additional contextual information around the reception of the transmission. This contextual information may include the geo-physical location of the user device116, the time that the transmission was received, and the contextual location.

The user device116sends the beacon identification information to the validation service430. Utilizing the information extracted at block420, the user device116may identify the associated beacon registry104. The user device116may interface with APIs to address and access the beacon registry104. For example, the URL frame mentioned above may contain the appropriate information to address a beacon registry104and the API would facilitate the query for the beacon based on the information from the UID frame.

The user device116receives data about the beacon from the validation service440. In this embodiment, the user device116may receive data about the beacon, including the beacon safety score. This data describes the content that the beacon is directing the user device116to view. Beacon types may be included in the data. Age restrictive information may be included in the data as well. For example, the data may indicate that the beacon is promoting products, or that the beacon is presenting information not intended for children.

The user device116suppresses the propagation of the beacon transmission to other applications running on the user device116based on that data450. Based on the data received at block440and a set of user preferences, the user device116determines if the beacon transmission should be suppressed. The set of user preferences may indicate acceptable types, times, and locations to receive beacon transmissions. For example, if the user preferences block all media content rated higher than PG and the received data indicates the beacon is directing the user to a media website with content rating of R, the user device116will suppress that transmission. Likewise, if the user preferences block all unsolicited advertisements, any beacon directing the user to advertising websites will be suppressed. Additionally, the user device116may reset time to live (TTL) affected networking components in order to remain anonymous to the transmitter. Furthermore, the user device116may alert the user that data transmitted may be used to pinpoint the location or path traversed by a user.

Referring now toFIG. 5, a block diagram illustrates a programmable device500that may be used for implementing the techniques described herein in accordance with one or more embodiments. The programmable device500illustrated inFIG. 5is a multiprocessor programmable device that includes a first processing element570and a second processing element580. While two processing elements570and580are shown, an embodiment of programmable device500may also include only one such processing element.

Programmable device500is illustrated as a point-to-point interconnect system, in which the first processing element570and second processing element580are coupled via a point-to-point interconnect550. Any or all of the interconnects illustrated inFIG. 5may be implemented as a multi-drop bus rather than point-to-point interconnects.

As illustrated inFIG. 5, each of processing elements570and580may be multicore processors, including first and second processor cores (i.e., processor cores574aand574band processor cores584aand584b). Such cores574a,574b,584a,584bmay be configured to execute computing instruction code. However, other embodiments may use processing elements that are single core processors as desired. In embodiments with multiple processing elements570,580, each processing element may be implemented with different numbers of cores as desired.

Each processing element570,580may include at least one shared cache546. The shared cache546a,546bmay store data (e.g., computing instructions) that are utilized by one or more components of the processing element, such as the cores574a,574band584a,584b, respectively. For example, the shared cache may locally cache data stored in a memory532,534for faster access by components of the processing elements570,580. In one or more embodiments, the shared cache546a,546bmay include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), or combinations thereof.

WhileFIG. 5illustrates a programmable device with two processing elements570,580for clarity of the drawing, the scope of the present invention is not so limited and any number of processing elements may be present. Alternatively, one or more of processing elements570,580may be an element other than a processor, such as an graphics processing unit (GPU), a digital signal processing (DSP) unit, a field programmable gate array, or any other programmable processing element. Processing element580may be heterogeneous or asymmetric to processing element570. There may be a variety of differences between processing elements570,580in terms of a spectrum of metrics of merit including architectural, microarchitectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity amongst processing elements570,580. In some embodiments, the various processing elements570,580may reside in the same die package.

First processing element570may further include memory controller logic (MC)572and point-to-point (P-P) interconnects576and578. Similarly, second processing element580may include a MC582and P-P interconnects586and588. As illustrated inFIG. 5, MCs572and582couple processing elements570,580to respective memories, namely a memory532and a memory534, which may be portions of main memory locally attached to the respective processors. While MC logic572and582is illustrated as integrated into processing elements570,580, in some embodiments the memory controller logic may be discrete logic outside processing elements570,580rather than integrated therein.

In turn, I/O subsystem590may be coupled to a first link516via an interface596. In one embodiment, first link516may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another I/O interconnect bus, although the scope of the present invention is not so limited.

As illustrated inFIG. 5, various I/O devices514,524may be coupled to first link516, along with a bridge518that may couple first link516to a second link520. In one embodiment, second link520may be a low pin count (LPC) bus. Various devices may be coupled to second link520including, for example, a keyboard/mouse512, communication device(s)526(which may in turn be in communication with the computer network503), and a data storage unit528such as a disk drive or other mass storage device which may include code530, in one embodiment. The code530may include instructions for performing embodiments of one or more of the techniques described above. Further, an audio I/O524may be coupled to second link520.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture ofFIG. 5, a system may implement a multi-drop bus or another such communication topology. Although links516and520are illustrated as busses inFIG. 5, any desired type of link may be used. In addition, the elements ofFIG. 5may alternatively be partitioned using more or fewer integrated chips than illustrated inFIG. 5.

Referring now toFIG. 6, a block diagram illustrates a programmable device600according to another embodiment. Certain aspects ofFIG. 6have been omitted fromFIG. 6in order to avoid obscuring other aspects ofFIG. 6.

FIG. 6illustrates that processing elements670,680may include integrated memory and I/O control logic (“CL”)672and682, respectively. In some embodiments, the672,682may include memory control logic (MC) such as that described above in connection withFIG. 5. In addition, CL672,682may also include I/O control logic.FIG. 6illustrates that not only may the memories632,634be coupled to the CL672,682, but also that I/O devices644may also be coupled to the control logic672,682. Legacy I/O devices615may be coupled to the I/O subsystem690by interface696. Each processing element670,680may include multiple processor cores, illustrated inFIG. 6as processor cores674A,674B,684A and684B. As illustrated inFIG. 6, I/O subsystem690includes point-to-point (P-P) interconnects694and698that connect to P-P interconnects676and686of the processing elements670and680with links652and654.

Processing elements670and680may also be interconnected by link650and interconnects678and688, respectively.

The programmable devices depicted inFIGS. 5 and 6are schematic illustrations of embodiments of programmable devices that may be utilized to implement various embodiments discussed herein. Various components of the programmable devices depicted inFIGS. 5 and 6may be combined in a system-on-a-chip (SoC) architecture.

The following examples pertain to further embodiments.

Example 1 is a machine readable medium, on which are stored instructions for determining beacon safety, comprising instructions that when executed cause a machine to: receive a beacon identification information and a beacon content associated with a beacon; determine whether the beacon identification information identifies a known beacon; determine a safety level of the beacon content; generate a beacon safety score based on the safety level and the beacon identification information; and send the beacon safety score to a requester.

In Example 2 the subject matter of Example 1 optionally includes wherein the beacon safety score comprises a value derived from the safety level of the beacon content and the beacon identification information.

In Example 3 the subject matter of Example 1 optionally includes wherein the instructions to determine whether the beacon identification information identifies a known beacon comprise instructions that evaluate a manufacturing origin of the beacon, a geo-physical location of the beacon, and historical activity associated with the beacon.

In Example 4 the subject matter of Example 1 optionally includes wherein the beacon content comprises a uniform resource locator, and the instructions to determine a safety level of the beacon content comprises evaluating the uniform resource locator and content addressed by the uniform resource locator.

In Example 5 the subject matter of any of Examples 1-4 optionally includes wherein the beacon identification information comprises hardware information associated with the beacon and telemetry information received, both received from the beacon, data used to associate malicious data with the beacon, and data used to derive trustworthiness of manufacturing origin of the beacon, data used to determine whether the beacon occupies a well reputed geo-physical location, and data used to associate a known historical activity with the beacon.

In Example 6 the subject matter of any of Examples 1-4 optionally includes further comprising instructions to store the beacon safety score.

Example 7 is a system for determining safety of beacon transmissions, comprising: one or more processors; memory coupled to the one or more processors on which are stored instructions, comprising instructions that when executed cause at least some of the one or more processors to: receive a beacon transmission from a beacon; extract a beacon identification information from the beacon transmission; send the beacon identification information to a beacon registry; receive a beacon content from the beacon registry; send the beacon content and the beacon identification information to a validation service; and receive, from the validation service, a beacon safety score.

In Example 8 the subject matter of Example 7 optionally includes further comprising instructions to suppress the beacon content of the beacon based on the beacon safety score.

In Example 9 the subject matter of Example 7 optionally includes further comprising instructions to identify the beacon registry.

In Example 10 the subject matter of Example 7 optionally includes wherein the beacon safety score indicates whether the beacon is safe and whether the beacon content is safe.

In Example 11 the subject matter of any of Examples 7-10 optionally includes wherein the beacon safety score indicates whether the beacon has a trusted manufacturing origin, a well reputed geo-physical location, and known historical activity.

In Example 12 the subject matter of any of Examples 7-10 optionally includes wherein the instructions to extract beacon identification information from the beacon transmission comprise instructions to: extract a beacon identifier from the beacon transmission; extract a registry information from the beacon transmission; and compute a contextual information, wherein the contextual information comprises a geo-physical location, a time transmission received, and a contextual location associated with the beacon.

In Example 13 the subject matter of Example 12 optionally includes wherein the registry information comprises an address of a private beacon registry.

In Example 14 the subject matter of any of Examples 7-10 optionally includes further comprising instructions to present a visual representation indicative of the beacon content based on the beacon safety score.

Example 15 is a method for suppressing beacon transmissions, comprising: receiving a beacon transmission from a beacon; extracting a beacon identification information from the beacon transmission; sending the beacon identification information to a validation service; receiving, from the validation service, data associated with the beacon; and suppressing, based on the data, propagation of the beacon transmission to other applications.

In Example 16 the subject matter of Example 15 optionally includes wherein the suppressing comprises evaluating the data against a set of user preferences.

In Example 17 the subject matter of Example 16 optionally includes wherein the set of user preferences comprises acceptable times of day to receive beacon transmissions.

In Example 18 the subject matter of Example 16 optionally includes wherein the set of user preferences comprise acceptable types of beacon transmissions.

In Example 19 the subject matter of Example 16 optionally includes wherein the set of user preferences comprise acceptable locations to receive beacon transmissions.

In Example 20 the subject matter of any of Examples 15-19 optionally includes further comprising notifying a user of received suppressed beacon transmissions.

Example 21 is an apparatus comprising: a processor; and a memory coupled with the processor, on which are stored instructions, comprising instructions that when executed cause the processor to: receive a beacon identification information and a beacon content associated with a beacon; determine whether the beacon identification information identifies a known beacon; determine a safety level of the beacon content; generate a beacon safety score based on the safety level and the beacon identification information; and send the beacon safety score to a requester.

In Example 22 the subject matter of Example 21 optionally includes wherein the beacon safety score comprises a value derived from the safety level of the beacon content and the beacon identification information.

In Example 23 the subject matter of Example 21 optionally includes wherein the instructions to determine whether the beacon identification information identifies a known beacon comprise instructions that evaluate a manufacturing origin of the beacon, a geo-physical location of the beacon, and historical activity associated with the beacon.

In Example 24 the subject matter of Example 21 optionally includes wherein the beacon content comprises a uniform resource locator, and the instructions to determine a safety level of the beacon content comprises evaluating the uniform resource locator and content addressed by the uniform resource locator.

In Example 25 the subject matter of any of Examples 21-24 optionally includes wherein the beacon identification information comprises hardware information associated with the beacon and telemetry information received, both received from the beacon, data used to associate malicious data with the beacon, and data used to derive trustworthiness of manufacturing origin of the beacon, data used to determine whether the beacon occupies a well reputed geo-physical location, and data used to associate a known historical activity with the beacon.

In Example 26 the subject matter of any of Examples 21-24 optionally includes further comprising instructions to store the beacon safety score.

Program instructions may be used to cause a general-purpose or special-purpose processing system that is programmed with the instructions to perform the operations described herein. Alternatively, the operations may be performed by specific hardware components that contain hardwired logic for performing the operations, or by any combination of programmed computer components and custom hardware components. The methods described herein may be provided as a computer program product that may include a machine readable medium having stored thereon instructions that may be used to program a processing system or other electronic device to perform the methods. The term “machine readable medium” used herein shall include any medium that is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methods described herein. The term “machine readable medium” shall accordingly include, but not be limited to, tangible, non-transitory memories such as solid-state memories, optical and magnetic disks. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, module, logic, and so on) as taking an action or causing a result. Such expressions are merely a shorthand way of stating that the execution of the software by a processing system causes the processor to perform an action or produce a result.

It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.