EP3272062A1 - Système pour réseau de balises anti-arnaque et administration basée sur un nuage de contenu associé - Google Patents

Système pour réseau de balises anti-arnaque et administration basée sur un nuage de contenu associé

Info

Publication number
EP3272062A1
EP3272062A1 EP16769507.1A EP16769507A EP3272062A1 EP 3272062 A1 EP3272062 A1 EP 3272062A1 EP 16769507 A EP16769507 A EP 16769507A EP 3272062 A1 EP3272062 A1 EP 3272062A1
Authority
EP
European Patent Office
Prior art keywords
beacon
content
url
transmitters
servers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16769507.1A
Other languages
German (de)
English (en)
Other versions
EP3272062A4 (fr
Inventor
Richard C. Graves
Chris BLANZ
Beat Zenerino
Kevin Huber
Greg THORNTON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bkon Connect Inc
Original Assignee
Bkon Connect Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bkon Connect Inc filed Critical Bkon Connect Inc
Publication of EP3272062A1 publication Critical patent/EP3272062A1/fr
Publication of EP3272062A4 publication Critical patent/EP3272062A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present invention relates generally to wireless radio signal transmissions. More particularly, this invention relates to systems and methods for the deployment and management of Bluetooth Low Energy (“BLE”) beacons.
  • BLE Bluetooth Low Energy
  • BLE beacons have been emergence 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.
  • BLE beacons operate over several protocols in the market over which BLE beacons operate, including for example Apple's iBeacon protocol, which consists of a fixed length bit package (UUID / Major Identifier / Minor Identifier) that is in turn interpreted by compatible mobile Apps.
  • UUID / Major Identifier / Minor Identifier a fixed length bit package
  • the UriBeacon protocol is an alternative and open source protocol introduced by Google.
  • One premise of the UriBeacon protocol is that beacons broadcast a Uniform Resource Locator ("URL"), which is the address of a web site.
  • URL Uniform Resource Locator
  • the UriBeacon has been promoted as a primary link between the physical world and the Internet, where places and things in can communicate via web sites. Much like QR codes, UriBeacons will be universally accessible, and will not require a custom App, as are required by for example the iBeacon protocol.
  • the conventional mode of operation is straightforward.
  • an administrative App designed to configure beacons and when physically near to the target beacon, one can connect with a "UriBeacon” and program it with the URL of a destination web site.
  • the field that is programmed with the URL is called the Universal Resource Identifier (URI) because it uses some abbreviations for the URL it broadcasts.
  • the target beacon references this URI to broadcast the desired URL.
  • a special browser executable from a client device is configured to read the URI broadcast from that beacon and connect to the destination URL in the normal way.
  • Exemplary systems or methods according to the present disclosure provide a unique model of operation that tightly couples a beacon device such as a UriBeacon with a cloud based server (e.g., URI Management Server or "UMS”), thereby providing several major advantages over the traditional model.
  • a beacon device such as a UriBeacon
  • a cloud based server e.g., URI Management Server or "UMS”
  • a system as disclosed herein includes a plurality of distributed beacon transmitters, each of which are configured to continuously broadcast messages including a URL, and with the URL having a host domain address and an identifier unique to the respective beacon embedded therein.
  • Client devices proximate to one or more of the beacons, and having appropriate browser applications executed thereon, are able to receive the broadcast messages and subsequently transmit content requests to the host server associated with the URL.
  • the host server is further configured to identify the beacon from the unique identifier, and return an appropriate destination URL to the client device for user selection, at which point the browser may for example be redirected to a content server associated with the destination URL for content presentation.
  • the system may further include a hosted and administrator-facing web portal wherein at least destination URLs associated with the respective beacons may be remotely designated.
  • beacons By making use of the cloud based server system to deploy beacons, one may mail them out to the field, even to hundreds of different locations, and later set up and manage all of the above functions from a hosted web portal, all without ever interacting directly with any of the beacons.
  • embodiments of a hosted system or method as disclosed herein enable simplified administration. Rather than using an administrative app in near proximity to the target beacon to reprogram the beacon to point to a different destination URL, customized UriBeacons (or otherwise a closed network of UriBeacons) may be redirected from a cloud server. For someone managing numerous beacons in dispersed locations, this is an important feature, as all beacons may be reprogrammed from a central location, as opposed to being required to visit each beacon.
  • embodiments of a hosted system or method as disclosed herein provide anti-spoofing functionalities. Because beacons generally broadcast an open air wireless message, their signal may be captured, mimicked, and rebroadcast from a different device and from a different location. This is typically called "spoofing”. UriBeacons within the hosted and closed network according to the present disclosure may be prevented from being spoofed because each of them may broadcast a continuously changing unique identifier, which is recognized by the host server. Even if multiple beacons point to the identical destination URL, they all still appear unique to the host UMS server.
  • embodiments of a hosted system or method as disclosed herein detect the presence of users.
  • the host or other authorized client user or administrator is able to provide positive confirmation that the person accessing the web site is in the near proximity to that beacon.
  • web pages may be generally accessed from any Internet connected device, the ability in this system to recognize the current validity of a beacon's unique identifier allows one to know if access to the web site came from someone in the immediate or very recent proximity to that target beacon, or from someone accessing the web site either from a different location or at a later time.
  • 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.
  • embodiments of a hosted system or method as disclosed herein enable users to take secure ownership of a beacon, such that it cannot be reprogrammed by a third party, without ever interacting directly with the beacon. By taking ownership of the public beacon identifier in the cloud based UMS, the user is simultaneously securing the physical beacon with the matching identifier.
  • embodiments of a hosted system or method as disclosed herein provide unique device identifiers for each beacon in a hosted or otherwise closed network.
  • the UriBeacon protocol offers an alternate transmit mode, where rather than a URI, the beacon broadcasts a UID (a unique identifier).
  • UID a unique identifier
  • traditional UriBeacons must be directly programmed to either broadcast a URL or a UID.
  • 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.
  • embodiments of a hosted system or method as disclosed herein provide network trigger points. Because hosted beacons as disclosed herein may typically have a unique broadcast ID, which cannot be copied or spoofed, they may be used as triggers for other applications, or as highly reliable location identifiers.
  • Fig. 1 is a flow diagram representing an embodiment of a hosted beacon web server system according to the present disclosure.
  • Fig. 2 is a flowchart representing an exemplary embodiment of a process for directing beacon-specific content to a device browser as implemented by the system of Fig. 1.
  • Fig. 3 is a flowchart representing an exemplary process of beacon authentication according to as disclosed herein.
  • Fig. 4 is a graphical diagram representing an embodiment of a hosted user interface according to the present disclosure.
  • Fig. 5 is a perspective diagram representing an embodiment of a hosted beacon according to the present disclosure.
  • an exemplary embodiment of a system 100 as disclosed herein may include a hosted beacon 102 that is configured to support some or all of broadcast options including but not necessarily limited to a traditional iBeacon protocol, a standard editable UriBeacon protocol, a hardcoded UriBeacon beacon protocol, and the like. Broadcast messages from any one or more of a plurality of beacons may be transmitted to proximate mobile computing devices 104 such as for example phones, tablets or the like.
  • a hosted web server 106 is further communicatively linked to the device or otherwise accessible via a communications network. The server is configured to direct the browser to content via for example a destination URL 110, with the content corresponding to a particular beacon 102 being designated in various embodiments by an administrator or the like via a hosted user interface 108.
  • 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.
  • 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.
  • 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.
  • identifier/serial number for that beacon would be "AkfGGy”.
  • This identifier may in certain embodiments be physically printed on or otherwise visibly discernable with respect to the beacon and/or its packaging, and the default setting of the beacon may be to broadcast this fixed URI (http : //YYY. ne t/Akf GGv) .
  • beacon's Unique ID which is printed on the beacon, go to the web portal 108 for the UMS, and enter the destination URL there in a field associated with the beacon's identifier.
  • 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.
  • UMS cloud based URI Management System
  • a user is not required to be physically near the beacon itself in order to edit the beacon's URI field, but instead may simply go to the UMS web portal 108 which enables the user to associate the beacon having identifying sub-directory http:/ YYY.net/AkfGGy to destination URL www.Xyz.com.
  • an exemplary method 200 as disclosed herein for providing some or all of the aspects referenced above may be described as follows.
  • various embodiments of a system and method may facilitate a novel interaction between the server and a browser to accomplish a more complete abstraction of beacon hardware from the need for any physical interaction.
  • acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithm).
  • 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.
  • 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.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • 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.
  • 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.
  • 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 the medium can reside as discrete components in a user terminal.
  • the method 200 may be characterized in part wherein each of a plurality of beacon transmitters are configured to implement a first step 201 of transmitting wireless messages comprising a unique identifier.
  • the method 200 may continue with a second step 202 wherein a mobile device proximate to one or more of the beacons receives corresponding messages, and further generates a content request for transmittal to a host web server, for example via a client web browser executed on the device.
  • the method 200 may continue with a third step 203 wherein the host server receives the content request from the mobile device and authenticates the beacon corresponding to the content request according to the unique identifier provided therein. [0038] The method 200 may continue with a fourth step 204 wherein the host server directs the mobile device browser to content designated for the respective beacon in the context of a destination URL.
  • the method 200 may continue with a step 206 wherein the host server is configured to determine a location of the mobile device as proximate to one or more of the networked beacons.
  • This step may be distinguished from a determination of distance from a particular beacon, or a direction from the mobile device to said beacon, but rather relates to a determination that the mobile device and by extension an associated user is physically present in proximity with said beacon.
  • 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.
  • 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.
  • two unique codes may be embedded in the firmware of each beacon at the point of manufacture. Because these codes are issued and are managed by the UMS, they are always guaranteed to be unique and they are also stored in a corresponding file on the hosted cloud UMS server permanently associated with the target beacon.
  • the unique codes are public and private keys in an asymmetric key pair as may be implemented for server-side authentication of broadcasts for a respective beacon.
  • the first code may be the beacon's unique ID, which is its public ID. It is this code that is printed on the beacon, and it is this same code that one uses to access the associated file in the hosted server where the destination URL is entered (or where web content is directly hosted).
  • the second code is the private passkey that is never exposed, and which is used in conjunction with an encryption algorithm to confirm to the host's cloud server the unique identity of each beacon.
  • the private passkey could be the beacon's unique MAC address
  • such an implementation is not recommended for reason that it complicates manufacturing by necessitating the recovery of the MAC address associated with a beacon ID during the manufacturing process for use in the UMS, if one is to avoid having to pair with the target beacon during deployment.
  • 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.
  • the system may for each respective broadcast generate an authentica table message with a new identifier/ security key, the respective identifier having been generated via encryption techniques using the private passkey.
  • 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.
  • the URI that the beacon will broadcast will be www . KLtHbr/6H8k9.
  • the hosted server will use the "6H8k9 sub-directory" to identify the beacon and then will discard this identifying sub-directory (step 303).
  • 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.
  • the server (step 304) authenticates the beacon by implementing the asymmetric key pair and identifying the beacon in the network.
  • a monitoring feature for the beacon power supply (e. g., internal battery) may be added within the framework previously described. Because the beacon is broadcasting a URI that might look like: http : I hp hy. net/HYHKuu#278iM. with the last field being the changing security key based upon the private key embedded into each beacon, we can easily have the beacon also send a reading of its battery's voltage level in the same field, which will allow the host server to interpret and thus monitor battery state. Similarly, beacons may include many different sensors and the sensor data form any of these beacons may be transmitted in the additional transmitted data.
  • the security key may be transmitted in alternate broadcast from the sensor data to allow both to be transmitted.
  • 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.
  • the server as disclosed herein may further provide additional information about the desired operation of the beacon hardware, which will improve the customers' experience. This may be accomplished by providing coded information in addition to the destination URL.
  • An exemplary transmission from the server to the browser may look like or equivalent to the following: http://demo- url.com#8NJHRF, where additional information about the desired user experience is added after a "#" separator (or other character, which separator will serve to introduce the coded information).
  • the UMS may transmit a file to the browser, which includes the additional information.
  • the first information provided by the server to the browser is the desired viewing range.
  • 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.
  • a viewing range By utilizing systems and methods as disclosed herein, and with further reference to Fig. 4, one can set the desired viewing range by simply checking a box indicating at a hosted administrative web portal 400. This is the same portal where the destination URL 405 may be set.
  • the user interface might work for example where a beacon having ID# Ah8unT 402 is pointed toward destination URL http://demo-url.com and has a designated viewing distance 404 of "IMMEDIATE", which would cause one to see this URL on a hosted web browser if one is within about approximately three feet of the piece of art.
  • the user is not adjusting the transmit power of the beacon, but instead is passing back to the viewing browser the range at which it should display the web site (in the coded message #8NJHRF), such that the browser, which can measure range because of its ability to monitor the beacon's signal strength, can then make use of this preference to decide whether to display the web site, or alternately, how to rank it on the browser display.
  • UMS server portal the TAGs that should be associated with a web site.
  • 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:
  • Various embodiments of systems and methods as disclosed herein therefore enable people who deploy beacons to be able to simply enter basic information about those beacons, including viewing range and location description, and to be able to automatically present this information as an addition to the destination URL, so that the browser can use it to display information in a manner most relevant to a consumer.
  • 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.
  • a first destination URL (e.g., http:/myp age. com/breakfast) may be designated for content requests from a client device browser occurring between 7:00am and 11:00am
  • a second destination URL e.g., http:/m ypage.com/lunch
  • a third destination URL e.g., http:/mypage. com/dinner
  • various embodiments of a system and method as disclosed herein may provide additional service enhancements when one makes use of a host web server to enhance, translate and augment the information broadcast by a UriBeacon.
  • a user may manage favicons, titles and descriptions at the host server level. The host server could return these selections to the browser.
  • the server may further or otherwise return more than one URL to the browser, thus acting as more than one Uribeacon.
  • 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”.
  • 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).
  • RF radio frequency
  • an exemplary beacon 102 may be configured with one or more condition sensors 112 such as for example battery power as further described below, and may further store information corresponding to an asymmetric key pair 114 or the like for beacon authentication, also as further described below.
  • 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.
  • 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.
  • 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.
  • 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.
  • ISP's Internet Service Providers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un réseau de balises distribuées et système de gestion à base de nuage (100). Les balises (102) sont chacune configurées pour transmettre des messages sans fil comprenant un identifiant unique généré au moyen des paires de clés asymétriques respectives. Un administrateur est activé par l'intermédiaire d'un portail web hébergé afin de désigner à distance un contenu en association avec des balises, ainsi que des réglages de proximité, des étiquettes de contenu, etc. Un dispositif mobile (104) à proximité d'au moins une balise reçoit leurs messages par l'intermédiaire d'un navigateur ouvert et transmet une demande de contenu associée à un serveur hébergé. Le serveur authentifie les balises par extraction et par mise en œuvre de chacune des paires de clés asymétriques respectives. Lors de l'authentification, le serveur fournit l'accès par l'intermédiaire du dispositif navigateur au contenu désigné pour au moins une des balises, et correspondant à la proximité des réglages et des étiquettes de contenu. Le contenu est fourni par l'intermédiaire des portails web hébergés, ou par redirection du navigateur à des URL tiers désignés par l'intermédiaire de l'interface d'administrateur.
EP16769507.1A 2015-03-20 2016-03-21 Système pour réseau de balises anti-arnaque et administration basée sur un nuage de contenu associé Withdrawn EP3272062A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562136157P 2015-03-20 2015-03-20
US201562152659P 2015-04-24 2015-04-24
PCT/US2016/023446 WO2016154129A1 (fr) 2015-03-20 2016-03-21 Système pour réseau de balises anti-arnaque et administration basée sur un nuage de contenu associé

Publications (2)

Publication Number Publication Date
EP3272062A1 true EP3272062A1 (fr) 2018-01-24
EP3272062A4 EP3272062A4 (fr) 2018-11-21

Family

ID=56979116

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16769507.1A Withdrawn EP3272062A4 (fr) 2015-03-20 2016-03-21 Système pour réseau de balises anti-arnaque et administration basée sur un nuage de contenu associé

Country Status (3)

Country Link
EP (1) EP3272062A4 (fr)
CA (1) CA2980498A1 (fr)
WO (1) WO2016154129A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL2019123B1 (en) * 2017-06-26 2019-01-07 Epesi Creative New Media B V Method and system of presence detection
WO2019076466A1 (fr) * 2017-10-20 2019-04-25 Telefonaktiebolaget Lm Ericsson (Publ) Procédés de fourniture et d'obtention d'accès à des ressources d'iot

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8386259B2 (en) * 2006-12-28 2013-02-26 Intel Corporation Voice interface to NFC applications
US9445305B2 (en) * 2011-09-12 2016-09-13 Microsoft Corporation Low energy beacon encoding
US9088862B2 (en) * 2011-10-08 2015-07-21 Thinglink Oy Use of multiple NFC tags
US9544075B2 (en) * 2012-02-22 2017-01-10 Qualcomm Incorporated Platform for wireless identity transmitter and system using short range wireless broadcast
US9152868B2 (en) * 2012-03-23 2015-10-06 Microsoft Technology Licensing, Llc Personal identification combining proximity sensing with biometrics
US9794321B2 (en) * 2012-12-23 2017-10-17 EVRYTHNG Limited System, method and a tag for mapping tagged objects to context-aware applications
US8781502B1 (en) * 2013-02-01 2014-07-15 Swirl Networks, Inc. Systems and methods for display of supplemental content responsive to location
US9307355B2 (en) * 2013-06-27 2016-04-05 Bluecats Australia Pty Limited Location enabled service for enhancement of smart device and enterprise software applications

Also Published As

Publication number Publication date
CA2980498A1 (fr) 2016-09-29
WO2016154129A1 (fr) 2016-09-29
EP3272062A4 (fr) 2018-11-21

Similar Documents

Publication Publication Date Title
US10104515B1 (en) Beacon-implemented system for mobile content management
US10375060B1 (en) System for mobile content and metadata management
EP3476148B1 (fr) Systèmes et procédés de communication à courte portée entre dispositifs
CN107925654B (zh) 用于交换数据的方法、网关计算设备和存储介质
US9509567B2 (en) Network device configuration by mobile device
US9357017B2 (en) Method and apparatus for automatic service discovery and connectivity
US20140181256A1 (en) System, Method and a Tag for Mapping Tagged Objects to Context-Aware Applications
AU2016362507A1 (en) Systems and methods for scalable-factor authentication
US20120290724A1 (en) System and method for network redirection
CN102595407A (zh) 一种使移动设备自动登录并接入无线网络的系统和方法
JP6515065B2 (ja) 通信の確立
US20170214684A1 (en) A contextual scanning device with pre-authenticated identity
CN104507141A (zh) 客户端接收文件的方法及接收方客户端
Wang et al. What can i do here? IoT service discovery in smart cities
US20220121893A1 (en) Communication platform
JP2018195339A (ja) 電子マニュアルを提供するシステム、サーバおよびプログラム
CN107534689A (zh) 使用户数据与移动设备关联的技术
EP3272062A1 (fr) Système pour réseau de balises anti-arnaque et administration basée sur un nuage de contenu associé
US10278067B2 (en) Methods and systems for associating social media to wireless identifiers
US10462246B2 (en) Unified content posting
EP3360349A1 (fr) Système mis en oeuvre par balise pour gestion de contenu mobile
CN104993999A (zh) 一种信息处理方法和服务器
CN109213907A (zh) 用于推荐信息的方法与设备
CN104767667A (zh) 一种web网页多屏共享的方法及终端设备、网站服务器
JP2005339148A (ja) 無線タグの読取りシステム

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20171020

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20181018

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 4/021 20180101ALI20181012BHEP

Ipc: H04L 9/32 20060101ALN20181012BHEP

Ipc: H04L 29/08 20060101AFI20181012BHEP

Ipc: H04W 4/80 20180101ALI20181012BHEP

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 4/80 20180101ALI20190821BHEP

Ipc: H04L 29/08 20060101AFI20190821BHEP

Ipc: H04W 4/021 20180101ALI20190821BHEP

Ipc: H04L 9/32 20060101ALN20190821BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20190930

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200211