Patent Grant
8990556
The subject matter described herein relates to the selective sharing of beacons across different accounts.
Beacons are increasingly being used for a variety of applications because of their low power requirements and low costs. Beacons transmit identifiers (typically a universally unique identifier) that are detected by applications or operating systems on client devices (e.g., mobile phones, etc.). Such detection can be used, in some scenarios, to initiate an action on the client device which may be based on the specific location of the client device as indicated by detecting the nearby beacon. For example, companies use beacons to extend the effectiveness of their mobile applications by adding real-time context to their offers and services which then can engage customers in the right way, at the right place and the right time. In addition, brands are empowered to increase sales and drive loyalty by delivering highly relevant content and services to consumers who are physically present in their stores & venues or stores and venues where their products and services can be found.
Beacons are typically owned and managed by a single entity. Switching the owner may require a burdensome configuration process and/or changes to client software. One alternative is to set up separate co-extensive beacon arrays at a given location which in turn can be costly, space consuming and time consuming.
In one aspect, data is received that specifies at least one beacon associated with a first account and a first validity window specifying a time period during which the at least one beacon is to be associated with an additional account. Thereafter, a first key is generated which, when registered by a second account, causes the at least one beacon to be associated with the second account until expiration of the first validity window. Outside the first validity window the at least one beacon remain associated solely with the first account.
In some variations, the at least one beacon can be associated with the second account in addition to the first account during the first validity window (as opposed to such beacons being exclusively associated with the second account).
Data can later be received that revokes the first key. In such cases, the at least one beacon can be caused to no longer be associated with the second account during the first validity window after the first key revocation.
Each key can be a unique alphanumeric string that can only be registered once.
Data can be received that specifies restrictions on use of the at least one beacon. In such cases, the association of the at least one beacon with the second account prevents the one or more of the beacons to be used in contravention with the specified restrictions on use of the at least one beacon. The specified restrictions on use of the at least one beacon can include, for example, prevention of at least one of: editing at least one beacon or deleting at least one beacon.
Data can be received that specifies permissible uses of the at least one beacon. In such cases, the association of the at least one beacon with the second account prevents one or more of the beacons to be used for other than the specified permissible uses. The specified permissible uses of the at least one beacon can include, for example, at least one of: detection of each of a plurality of beacons, presenting a notification to an end-user on a client device, launching or changing a user interface on a client device, logging that the end-user was near a beacon at a certain time and dwelled nearby it for an amount of time.
Data can be received that specifies at least one beacon (which may or may not be fully coextensive with the previous beacon array) associated with the first account and a second validity window specifying a time period during which one or more beacons are to be associated with an additional account. Thereafter, a second key can be generated which, when registered by a third account, causes at least one beacon to be associated with the third account until expiration of the second validity window. In some cases, the first validity window can at least partially overlap with the second validity window. Registration of the second key can cause the first key to be revoked such that the at least one beacon is no longer associated with the second account during the first validity window and/or the overlap of the first validity window and the second validity window. Alternatively, the at least one beacon can be associated with both the second account and the third account during the overlap of the first validity window and the second validity window. The at least one beacon can in some cases also remain associated with the first account during the first validity window and the second validity window.
Data can be received that specifies exclusivity terms for the first key such that, after the registration of the first key, the at least one beacon is exclusively associated with the second account during the first validity window according to the exclusivity terms. The exclusivity terms can specify complete exclusivity for the second account with the exception of the first account. The exclusivity terms can specify exclusivity for the second account with the exception of the first account. Data can be received that specifies exclusivity terms for a second key such that, after the registration of the second key, the first key is revoked such that the at least one beacon is no longer associated with the second account during the first validity window.
Non-transitory computer program products (i.e., physically embodied computer program products) are also described that store instructions, which when executed by one or more data processors of one or more computing systems, causes at least one data processor to perform operations herein. Similarly, computer systems (which can additionally include one or more beacons) are also described that may include one or more data processors and memory coupled to the one or more data processors. The memory may temporarily or permanently store instructions that cause at least one processor to perform one or more of the operations described herein. In addition, methods can be implemented by one or more data processors either within a single computing system or distributed among two or more computing systems. Such computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g. the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc.
The subject matter described herein provides many advantages. For example, the current subject matter provides a user-friendly platform that enables beacons and beacon arrays to be rapidly shared amongst multiple entities.
The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
Like reference symbols in the various drawings indicate like elements.
The current subject matter is directed to the sharing of beacons amongst various accounts to selectively allow different account holders to take and selectively use a set of beacons. For example, an account holder having an array of beacons may be willing to share them with business partners selectively during particular times.
The current subject matter can be used in connection with a beacon platform such as that described in U.S. patent application Ser. No. 13/773,379 entitled: “Platform for Wireless Identity Transmitter and System Using Short Range Wireless Broadcast” and published as U.S. Pat. App. Pub. No. 2013/0217332, and U.S. patent application Ser. No. 13/833,110 entitled: “Retail Proximity Marketing” and published as U.S. Pat. App. Pub. No. 2013/0297422, the contents of both of which are hereby fully incorporated by reference.
Various types of actions can be initiated based on the software identifying the beacon. Sample actions include, for example, presenting a notification to the end-user, launching or changing a user interface, logging that the end-user was near a beacon at a certain time and dwelled nearby it for an amount of time, etc.
At some later point, the client device 115 can, at 230, be within a range of the beacon 105 such that the software can detect a transmission from the beacon 105 that identifies such beacon. It is then determined, at 235, whether there the client device 115 includes cached authorization for identifying the beacon as well as application triggering data that is associated with the identity of such beacon. If it is determined that there is cached authorization and application triggering data, the software notifies the application it is associated with or operating system on the client device 115 which, in turn, can trigger one or more actions. In addition, the detection of the beacon 105 and the triggering of actions can be stored in a log that can, at some later point, be transmitted to the beacon server 125. If it is determined that there is no cached authorization, then, at 240, the software can relay the secure beacon transmission to beacon server 125 and request authorization as well as any application trigger data.
The beacon server 125 can then determine whether the software is authorized to be informed of the beacon identity and which actions, if any, to take in connection with the detected beacon 105 and, at 245, transmit the beacon identity, metadata and application triggering data back to the client device 115 for local storage (i.e., caching, etc.). If the server response 245 is that the beacon 105 is to be ignored for period of time, then no further events occur. Otherwise, at 250, the application triggering data causes the software to notify the application it is associated with about the beacon 105 so that an action may be initiated. In either event, the action/ignore events can be stored in the software's log for later transmission to the beacon server 125. With the former arrangement, in some cases, the call into the corresponding application can cause the client device, at 255, to transmit data to an application server 205 (i.e., a server associated with the application that was notified about the beacon 105, etc.) characterizing the call. The application server 205 can make a determination of which action should be initiated by the application (associated with the software) on the client device 115 and transmit further application triggering data, at 260, specifying such action or actions, if any. If the application server response 260 is that the beacon 105 is to be ignored for period of time, then no further events occur. Otherwise, at 265, the application triggering data from the application server causes the software to notify the application it is associated with about the beacon 105 so that the corresponding action or actions may be initiated.
With reference to diagram 300 of
The beacon server 125 can manage and/or interface with a platform that enables different account holders to detect the beacons 105. For example, the platform can associate a particular beacon with a particular account. The account holder for such account can then define what actions are triggered by a corresponding application when a particular associated beacon is detected. Stated differently, the account holder can define what actions will be triggered (and thus form part of the application triggering data sent by the beacon server 125 to the client device 115).
The platform can include a web portal that allows an account holder (sometimes referred to as the owner) to select beacons to be shared with another account holder (sometimes referred to as the second account). In addition, the owner can specify a validity window during which the second account can detect the selected beacons. In other cases, the validity window (e.g., expiration date, etc.) can be pre-defined or at a default value (e.g., 30 minutes, etc.) but modifiable by the owner. Furthermore, the owner can add metadata related to the beacons such as names (e.g., zone 3 beacon, etc.), tags (e.g., entrance, exit, etc.) and the like.
In some cases, the account holder can specify, on a beacon-by-beacon basis or on a group, permissible interactions. Such actions can include presenting a notification to the end-user, launching or changing a user interface, logging that the end-user was near a beacon at a certain time and dwelled nearby it for an amount of time, performing actions only when the application is in the foreground, performing actions only when the application is in the background, etc.
The account holder can then request that the platform generate a sharing key that encapsulates the beacons and metadata to be shared and present it to the second account holder. Such key can in some cases be unique and/or a one-time use key. The owner can give the key to any other entity having an account on the platform (e.g., the second account holder, etc.). The platform can cause the key to be transferred directly from the owner to another account holder or such transfer can be performed external to the platform. With the latter arrangement, a user associated with the second account can receive the key from the owner, log onto the portal of the platform, and enter the key.
Thereafter, when accessing the portal, the user of the second account can be presented with information pertinent to the account. For example, a table of keys that have been entered, the name of the corresponding account holder, when the keys were entered, when the keys were revoked and/or when the validity windows for the keys expired can be presented. Similarly, a table of shared beacons, (e.g. beacons made temporarily available by account holders via sharing keys given), the name of the corresponding owner, when the beacons became available, when the ability to detect the beacons will expire, and the like can be presented.
As can be appreciated, the second account can lose all access to shared beacons when the corresponding validity window or windows expire. In addition, in some cases, the second account can lose access to the shared beacons upon revocation of the key by the owner (which can be performed via the portal). Further, the developer can lose access to a subset of the shared beacons if the owner deactivates (e.g. deletes) the beacons from their account.
Various mechanisms can be provided by the platform to allow account holders to identify beacons associated with one account to be permanently transferred to another account (i.e., sold, etc.) or for which temporary access can be granted (i.e. rented). For example, an exchange can be accessible via a web portal that either lists or otherwise provides a graphical representation of beacons available for transfer/temporary use.
As noted above, the portal can provide an exchange (i.e., an online marketplace facilitating transactions amongst a plurality of account holders). An exchange can facilitate transactions amongst beacon owners and other account holders that do not have a pre-existing relationship. With the exchange, an owner can log onto the portal, select a subset of beacons, set the validity window (e.g., start date, expiration date, valid times etc.), add metadata (name, tags, pricing, etc.), and request to be listed as a beacon network in the exchange table. The owner can also specify permissible interactions using the beacons. Further, the owner can specify certain parameters on the sharing of the beacon such as whether the sharing is exclusive (e.g. only one account holder can detect the beacons at a time), exclusive for a particular field of market (e.g. only one account holder in the fast food restaurant market can detect the beacons at a time), non-exclusive, and the like.
In some implementations, the identity of the beacon owners remains anonymous. The owner can in some variations not specify a price for sharing the beacons and actively solicit bids from other account holders (in some cases with minimum bid levels, etc.). In other variations, the owner can specify a price for sharing the beacons (e.g., $1000/day for an array of beacons, etc.). The owner can also specify time limitations during which bids would be accepted and the like.
Users can log onto the portal, browse the exchange tables/views (e.g., beacon locations overlaid on a map, etc.) to find a beacon network that meets their requirements (e.g. location, metadata description, pricing, etc.). The user can then select such beacon network and then place a bid on it, or in the case of a fixed price listing, accept the listing price. If the beacon sharing is marked as exclusive, the selection of a beacon can invalidate other listings that offer the same beacon for sharing with an overlapping validity window. If the bid is accepted or the fixed price is accepted, the platform can then automatically populate the beacon network into the shared beacon table of the buyer's account or otherwise facilitate the sharing of beacons.
One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) computer hardware, firmware, software, and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
These computer programs, which can also be referred to as programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor, and can be implemented in a high-level procedural language, an object-oriented programming language, a functional programming language, a logical programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor. The machine-readable medium can store such machine instructions non-transitorily, such as for example as would a non-transient solid-state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium can alternatively or additionally store such machine instructions in a transient manner, such as for example as would a processor cache or other random access memory associated with one or more physical processor cores.
To provide for interaction with a user, one or more aspects or features of the subject matter described herein can be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display (LCD) or a light emitting diode (LED) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including, but not limited to, acoustic, speech, or tactile input. Other possible input devices include, but are not limited to, touch screens or other touch-sensitive devices such as single or multi-point resistive or capacitive trackpads, voice recognition hardware and software, optical scanners, optical pointers, digital image capture devices and associated interpretation software, and the like.
In the descriptions above and in the claims, phrases such as “at least one of” or “one or more of” may occur followed by a conjunctive list of elements or features. The term “and/or” may also occur in a list of two or more elements or features. Unless otherwise implicitly or explicitly contradicted by the context in which it is used, such a phrase is intended to mean any of the listed elements or features individually or any of the recited elements or features in combination with any of the other recited elements or features. For example, the phrases “at least one of A and B;” “one or more of A and B;” and “A and/or B” are each intended to mean “A alone, B alone, or A and B together.” A similar interpretation is also intended for lists including three or more items. For example, the phrases “at least one of A, B, and C;” “one or more of A, B, and C;” and “A, B, and/or C” are each intended to mean “A alone, B alone, C alone, A and B together, A and C together, B and C together, or A and B and C together.” In addition, use of the term “based on,” above and in the claims is intended to mean, “based at least in part on,” such that an unrecited feature or element is also permissible.
The subject matter described herein can be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementations consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. As an example, while the above passages relate to a plurality of beacons, sharing can be conducted on a beacon by beacon basis and the subject matter described herein can be tailored accordingly. Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations can be provided in addition to those set forth herein. For example, the implementations described above can be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed above. In addition, the logic flows depicted in the accompanying figures and/or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. For example, with reference to
| Number | Name | Date | Kind |
|---|---|---|---|
| 5784028 | Corman et al. | Jul 1998 | A |
| 5812086 | Bertiger et al. | Sep 1998 | A |
| 6052786 | Tsuchida | Apr 2000 | A |
| 6513015 | Ogasawara | Jan 2003 | B2 |
| 6536658 | Rantze | Mar 2003 | B1 |
| 6970092 | Hum et al. | Nov 2005 | B2 |
| 7260835 | Bajikar | Aug 2007 | B2 |
| 7376583 | Rolf | May 2008 | B1 |
| 7413121 | Goel et al. | Aug 2008 | B2 |
| 7658327 | Tuchman et al. | Feb 2010 | B2 |
| 7737861 | Lea et al. | Jun 2010 | B2 |
| 7752329 | Meenan et al. | Jul 2010 | B1 |
| 7791455 | MacLean, III et al. | Sep 2010 | B1 |
| 7849318 | Zhang et al. | Dec 2010 | B2 |
| 7880616 | Kanagala et al. | Feb 2011 | B2 |
| RE42435 | Katz | Jun 2011 | E |
| 7962361 | Ramchandani et al. | Jun 2011 | B2 |
| 8023895 | Smith | Sep 2011 | B2 |
| 8050984 | Bonner et al. | Nov 2011 | B2 |
| 8090399 | Howarter et al. | Jan 2012 | B2 |
| 8145125 | Masoian et al. | Mar 2012 | B2 |
| 8160577 | Bailin et al. | Apr 2012 | B2 |
| 20020062251 | Anandan et al. | May 2002 | A1 |
| 20040002897 | Vishik | Jan 2004 | A1 |
| 20040082343 | Kim et al. | Apr 2004 | A1 |
| 20040198221 | Bin et al. | Oct 2004 | A1 |
| 20060036485 | Duri et al. | Feb 2006 | A1 |
| 20060178986 | Giordano et al. | Aug 2006 | A1 |
| 20080107274 | Worthy | May 2008 | A1 |
| 20080123683 | Cheng et al. | May 2008 | A1 |
| 20080187137 | Nikander et al. | Aug 2008 | A1 |
| 20090103722 | Anderson et al. | Apr 2009 | A1 |
| 20090185677 | Bugbee | Jul 2009 | A1 |
| 20090210932 | Balakrishnan et al. | Aug 2009 | A1 |
| 20090254416 | Nomula | Oct 2009 | A1 |
| 20090315704 | Rosing et al. | Dec 2009 | A1 |
| 20100027783 | Yup | Feb 2010 | A1 |
| 20100070369 | Fenton et al. | Mar 2010 | A1 |
| 20100203833 | Dorsey | Aug 2010 | A1 |
| 20100267375 | Lemmon et al. | Oct 2010 | A1 |
| 20100287250 | Carlson et al. | Nov 2010 | A1 |
| 20110032916 | Lee | Feb 2011 | A1 |
| 20110138192 | Kocher et al. | Jun 2011 | A1 |
| 20110176465 | Panta et al. | Jul 2011 | A1 |
| 20110179064 | Russo | Jul 2011 | A1 |
| 20120029691 | Mockus et al. | Feb 2012 | A1 |
| 20120047011 | Rippetoe et al. | Feb 2012 | A1 |
| 20120201383 | Matsuo | Aug 2012 | A1 |
| 20120207302 | Alexander et al. | Aug 2012 | A1 |
| 20120209744 | Mullen et al. | Aug 2012 | A1 |
| 20120226537 | Subbarao et al. | Sep 2012 | A1 |
| 20120239504 | Curlander et al. | Sep 2012 | A1 |
| 20120278172 | Mercuri et al. | Nov 2012 | A1 |
| 20130006726 | Tijink et al. | Jan 2013 | A1 |
| 20130214909 | Meijers et al. | Aug 2013 | A1 |
| 20130217332 | Altman et al. | Aug 2013 | A1 |
| 20130282438 | Hunter et al. | Oct 2013 | A1 |
| 20130297422 | Hunter et al. | Nov 2013 | A1 |
| 20140133656 | Wurster et al. | May 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 1626363 | Feb 2006 | EP |
| 2200218 | Jun 2010 | EP |
| 20090095869 | Sep 2009 | KR |
| WO-02073864 | Sep 2002 | WO |
| WO-2005025127 | Mar 2005 | WO |
| WO-2007059558 | May 2007 | WO |
| WO-2009130796 | Oct 2009 | WO |
| WO-2010117364 | Oct 2010 | WO |
| WO-2012035149 | Mar 2012 | WO |
| WO-2013034924 | Mar 2013 | WO |
| Entry |
|---|
| Anonymous. “Stream cipher.” Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. Last modified Jan. 20, 2012. Web. Feb. 6, 2012. [Retrieved on Sep. 18, 2014 Internet Archive WayBackMachine]. |
| Barahim, M.Z. et al. “Low-Cost Bluetooth Mobile Positioning for Location-based Application,” IEEE (2007):1-4. ISBN: 14244-1007-X. [Retrieved on Sep. 17, 2014]. |
| Chaudhry M A, R., and Sheikh, Dr. Muhammad Imran. “Protocols Stack & Connection Establishment in Bluetooth Radio.” IEEE. (2002):48-55. ISBN: 0-7803-7505-X. [Retrieved on Sep. 17, 2014]. |
| Kim, H.W., et al. “Symmetric Encryption in RFID Authentication Protocol for Strong Location Privacy and Forward-Security.” IEEE. Hybrid Information Technology (ICHIT '06). (2006):718-723. ISBN: 0-7695-2674-8/06. [Retrieved on Sep. 17, 2014]. |
| Schneider M A., and Felten, Edward W. “Efficient Commerce Protocols based on One-time Pads.” IEEE (2000):317-326. ISBN:1063-9527/00. [Retrieved on Sep. 17, 2014]. |
| Tsudik, Gene. “A Family of Dunces: Trivial RFID Identification and Authentication Protocols”. Borisov, N. and Golle, P. (Eds.): PET 2007. LNCS 4776.(2007):45-61. [Retrieved on Sep. 17, 2014]. |
| Zuo, Yanjun. “Secure and private search protocols for RFID systems.”, INF SYS FRONT. (2010). 12:507-519. Published online: Aug. 28, 2009. DOI: 10.1007/s10796-009-9208-6. [Retrieved on Sep. 17, 2014]. |
