WO2019115842A1 - System and method for unique identification of electronic devices - Google Patents

Abstract

The present document describes a system and method for determining and assigning a unique identifier for electronic devices such as mobile terminals or smartphones. The method described herein allows the unique identifier for electronic devices to be determined and assigned using a system in the architecture of which is implemented a series of devices called nodes, which act such that same listen to certain bands of radio broadcasts generated by nearby mobiles terminals located in a specific area, to be able to generate said unique identifier from said listenings and, once standardised, propagate the identifier in the system.

Description

 SYSTEM AND UNIQUE DEVICE IDENTIFICATION METHOD

 ELECTRONICS

OBJECT OF THE INVENTION

The object of the invention is part of the technical field of information technology and telecommunications.

More specifically, the object of the invention is directed to the management of association and identification of electronic devices such as terminals in communication networks.

BACKGROUND OF THE INVENTION Nowadays, most people carry a personal mobile terminal (hereinafter user terminal, or user terminal by its acronym in English UT), which is present in our life or entity. offline (when we visit different physical sites with the phone in the pocket turned on but not active) and also in our life or online entity (when we visit online sites through web pages or visit mobile applications through that terminal).

Therefore, in the scope of this solution we consider that it is the same user who through a user terminal uses a mobile application, or uses / visits a web page from this terminal, who visits a physical space with said terminal in his pocket , although also the same person could use other terminals or devices (desktop, tablet, or similar devices).

On the other hand, there are currently several methods (among other SMS, instant messaging applications such as n / hatsapp, email, push of other Apps, Push on the web, etc.) to send a message to wake up (vibrate, sound, activation) of screen, etc.) to the personal mobile device of the user (and most of the user has it thus configured). However, we can not currently identify the same user terminal or the same person that is visiting a web page or uses an APP, subsequently visiting a specific physical space, and we can not send a message to the user terminal in the right place with information relevant to your profile (identifying your online and offline activity simultaneously: information on likes, interests, habits, places you visit, frequency with which you visit, etc).

In the state of the art currently known for online identification of UTs and users in addition to the use of cookies and tracking of IP addresses that have many drawbacks, there are published some methods of "Browser fingerprinting" and "App fsngerprinting" that would allow of the unique identification of the browser or the APP in the user's terminal, but there are few attempts to identify by proximity in the physical space those same users that can be identified online, especially without the user having to remove the terminal user's pocket, without having to perform actions for it every time you go to a physical space, for example to open an application or the browser looking for a promotion in store, or listen.

Currently the only systems that combine the detection and identification online and offline of UTs focus on the use of very simple beacon biuetooth hardware with protocols (Ibeacon or Eddystone) that are based on including certain functionality within an APP (through an SDK / Beacon) or in the Browser (if the user configures it with the appropriate permissions) to listen to the unique identifiers that emit the beacon type devices commonly called in the art by its English name beacon and thus identify different areas of the physical space from the APP.

The problem is that in addition to the mobile application or activate a special configuration of the browser, biuetooth activation is required, and that the phone has a compatible biuetooth model, these conditions must be met simultaneously makes the public reach of these systems nowadays it is very restricted. In practice less than 1% of visitors to a store they receive information by proximity thanks to this system. On the other hand, although the information that users receive can be linked to online behavior in the APP in the case of IBeacon, there is no relationship with the behavior of that same user when visiting or interacting in the browser with certain websites such as the online store or social networks or digital advertising.

On the other hand, WiFi tracking techniques based on the detection of the MAC address of the device are designed exclusively to identify the UTs in a physical area, ie for the analysis of offiine behavior, without the possibility of linking it to the user's online behavior, example, the communication of push messages to the mobile application when a user terminal is detected in a physical space is not intended or permitted in all OSs

But nowadays, obtaining a unique identifier from the address of the middle access layer of a mobile terminal is currently a problem that is not solved, due to the fact that the operating systems of the current UTs randomize these addresses and the same devices can generate dozens of addresses in a short period of time. Most market implementations do not overcome this barrier so that when trying to obtain information from devices not associated with a WiFi access point, the quality of real unique visitors that can be identified is very low, since only when the device is connected-associated to WiFi hotspots have a unique identifier and offiine device.

Another known problem is to have a unique identifier of the user terminal and the user in offiine and online, both for Android and for iOS, is another problem that is not resolved, since from some operating systems of wide use (such as iOS 10 ) it is not allowed through an APP (including the Navigator) the access via software to the permanent identifiers of the device such as the MAC address or the access address to the medium of your network cards. In the case of the application, the online advertising identifier of the user terminal could be accessed, but the browser, in turn, does not have access to the advertising identifier, and on the other hand, when the telephone is not in use (ie, it is offiine) the online advertising identifier is not issued or share in any way, so it can not be used to cross it with the detection of the address of access to the medium of your network cards.

It is therefore necessary to have the possibility of carrying out a unique identification of electronic devices, such as user terminals, offiine and Online that also allows distinguishing and analyzing offiine behavior not only people, but also things, for example a location of your assets.

DESCRIPTION OF THE INVENTION

Throughout this document the following terminology is used:

The term system to describe any number of components, elements, subsystems, devices, packet switching elements, packet switches, access switches, routers, networks, devices or computer and / or communication mechanisms, or combinations of components of the same. The term "computer" includes a processor, memory and buses capable of executing an instruction in which the computer refers to one or a group of computers, personal computers, workstations, mainframes or combinations of computers thereof, such as a network . It also has that as users any physical person or any system / machine / robot software or physical that access or are present in any type of:

 a) Online space, that is to say that it maintains an active / open connection / session through any type of communication network or uses / interacts with online information services such as web pages or applications {in this document also referred to as APPs) or networks social).

b) offiine space (stores, cities, shopping centers, airports, etc.), that is, when they are present in the physical space they do not maintain an active communication / session nor are they interacting online, even though they have a terminal (equipment with capabilities) Processing of information and communications) that Íes allows to be online at any time.

NS Server Node: It makes the device of a centralized architecture for storage, processing and distribution of information to the rest of the elements.

Signatures: Succession or array of fingerprints hashed (encoded) that generates the same device, according to ios and / or the SSiDs received, according to the capabilities via APP or via WEB. Each firm has a position, the first ones are called base signatures, and they are obtained when their deviceID has been approved and validated, the rest are additional signatures that will contribute value as a whole.

Visitor: person or any type of device (things machines, physical robots or software) different from others that access a space (physical or digital) generating events in that space.

Visit, short continuous presence considered by the continuous grouping of events of a visitor in a physical or digital space.

Visit, grouped presence of a visitor in a period considering the discontinuous grouping of events of a visitor in a physical or digital space.

Users any type of physical person or thing / machine / robot software or physical that access or are present in any type of online space (website, applications, social networks) or physical (among other travelers of transport systems, citizens, tourists, buyers in stores, and any type of people in any type of physical space) who have a device with information processing and communications capabilities. - User terminal, any device carried by a person, active / robot habitually in his offline life, and which is also used as a person access device! to online media (website, applications, services, queries, internet, etc ... telephone, voice, audio, data, etc. ..) that supports multiple applications, sensors, actuators, screens, buttons, keyboards, etc. The user terminals can be personal or non-personal. Personal devices can do all their functions even if they are not under the control of the human, that is, when they are at rest or not active. But it is considered personal since its physical entity is still linked to the physical person.

The object of the invention is based on the daily use of mobile devices that we use in our day to day (smart phone, tablets, smart watches) that act as an interface between our offline life (when we move to various physical sites with the phone in your pocket) and our online life (when we move around visiting websites or using mobile apps).

Unlike the use of simple beacon emitter systems installed in the physical space, together with mobile applications that install and authorize users to listen to the beacon, the invention described below is based on an intelligent device, which we will call Node, mainly dedicated to the listening and processing of radio information of the UTs.

By locating this intelligent device Node in a physical space, it will receive and demodulate and decode the signals in the public frequency bands of (2.4 -3.6 and 5Gbz) in which other mobile terminals broadcast frequently due to communication protocols. using radio (WíFi, Bluetooth, others), so analyzing the received frames can detect the presence of mobile devices in a physical area (offline space) anonymously without any intervention.

In collaboration with the functionality designed in the form of a kit for developers (Software Development Kit, SDK) that can be used in current operating systems (IOS, Android, ...) and also for HTML5, a an identifier system that we will call Offline Online identifier (OOID) in order to achieve a high probability of uniquely identifying the user terminal in a unique way, both offline and online, which we will call here OOiD Approved.

Various mechanisms are designed to propagate and update the information contained in the OOID to the different elements of the architecture (Node, APPs, Browsers, Server). Said OOID will persist and will be updated in the user terminal also when the user terminal is on but not used (offline).

This device and methods are applied not only to the generation of OOiD identifiers, but also to achieve multicai proximity messages, achieving a high number of UTs that without any gesture from the user receive information associated with their profile in their user terminal by proximity in physical areas (provided they have authorized it legally).

Mechanisms are designed that allow, in a transparent manner to the user, when the user terminal passes close to the Node, a communication is established between both, for the exchange of GGID information or the direct sending of messages to the user terminal.

Methods are designed to maximize the number of UTs that are uniquely identified in the physical space by proximity even if they use random MAC addresses or Virtual MAC addresses, in order to improve the unique identification of their cross-online and offline behavior and be able to send message by proximity to more UTs. In practice with respect to 1% of the total number of visitors of devices detected in a unique way that are achieved using bluetooth beacons or the 20% that can be detected using WiFi beacons, the invention object and associated systems are achieved by means of impiementations. 60 to 80%.

The device and associated components, allow to have a system with many industrial applications nowadays, thanks to having an OOID, especially useful in the field of marketing. In general, in these marketing applications it is not necessary to guarantee 100% unique identification of the UTs at all times and in all environments, but only to try to communicate with as many people as possible at the appropriate time and place, with messages relevant to the consumer that can be chosen by analyzing their behavior in various media or channels.

The online and anonymous behavior information collected by the system is anonymous, it is impossible to identify the person who carries it, but with the user's consent it can be linked to personal or other information provided by the user or available in other systems ( CRM, POS, etc ..), the design includes a new profile creation system that allows the incorporation of personal and non-personal information {psycho-socio-demographic, and transactional) mixed information of anonymous behavior oniine and ofline (in App, Web and physical location) obtained 24/7 and in real time.

DESCRIPTION OF THE DRAWINGS

To complement the description that is being made and in order to help a better understanding of the characteristics of the invention, according to a preferred example of practical realization thereof, a set of drawings is included as an integral part of said description. where, with illustrative and non-limiting character, the following has been represented:

Figure 1 shows a diagram showing a possible architecture model and the enumeration of the elements considered and the direction of the main flows of messages or information between them.

Figure 2.- It shows an example of an event table where the structure and functions necessary in the events between elements of the system are detailed.

Figure 3.- Shows an implementation of the OOID in which the structure and functions necessary in the oniine and offline identifier are detailed. Figure 4.- Shows a diagram showing the processes for the verification of the OOID.

Figure 5.- Shows a diagram showing the processes dedicated to the propagation of the OOiD.

Figure 6.1 Shows a descriptive table of the Node Device.

Figure 6.2 .-- It shows a scheme of the system of direct notifications of node

Figure 7.- Shows a tabia in which the main functions of the APP SDK are appraised.

Figure 8.- Shows a tabia in which the main functions of the WEB SDK are appreciated.

Figure 9 1 It shows a table in which the main functions Server Node or Server are appreciated.

Figure 9.2.- Shows a diagram showing the performance of the behavior analysis, detailing the management module of on-line and offline behavior.

Figure 9.3.- It shows a scheme where the parameters of the calculation of visitors, visits and visit are described, describing the techniques of analysis of online and offline behavior.

Figure 9.4.- Shows a diagram showing the interaction between systems, detailing the operations between modules and subsystems. PREFERRED EMBODIMENT OF THE INVENTION

In a possible preferred embodiment of the object of the invention it is required to have unique identifiers that allow the information of offiine and oniine behavior to be crossed, using the following elements that are described in the architecture of figure 1.

In different alternative embodiments configurations of the architecture described below could be varied, and that has been considered as the best alternative in the current state of technology, thinking of using a central element or server and a large number of low-cost devices ( nodes) forming an extensive network, although you could also use a model where the server functions are distributed in the nodes having a distributed network scenario.

In this preferred embodiment the elements that are combined in the architecture are:

 An intelligent hardware device or Node (101), comprising among others a radio frequency listening module.

 A series of electronic devices (102) such as user terminal equipment (102), referred to in parts of this document as UTs (102), capable of running mobile applications where an SDK APP (104) is integrated for mobile applications or APPs, and where a web browser runs which in turn have a web SDK (105) integrated, preferably under HTML5 for web pages.

NS or Server Node (103) with subsystems or modules - preferably implemented in software hardware - analysis and propagation of oniine and offiine identifiers (108), behavior management module (107) offiine and oniine and a campaign management module that includes a module of analysis of profiles and results (108), all with different connections between them. The Server Node (103) acts as a centralizer. NS or Server Node (103) preferably implemented in hardware, which includes among other subsystems or modules-: a) software- analysis and propagation of oniine and offline identifiers (106) b) module management of! behavior (107) offíine and oniine c) a campaign manager module that includes a profile and results analysis module (108), all with different connections between them.

The Server Node (103) acts as a centraliser.

Through the analysis module of! Behavior (107) can obtain information of offine detections (node events), which are analyzed to calculate visitors, visits and visits, and update data from an Online Offline Identifier, called OOID for its acronym in English, to the rest of elements.

Through the behavior analysis module (107) information (SDK events) of the online use of mobile applications of the SDK APP (104) and browsers by visiting web pages through the WEB SDK (105) is obtained in order to analyze the behavior crossed oniine in the profiles and results analysis module (108).

Through the profiles and results analysis module (108) offiine and oniine cross behavior profiles are generated, and the results of communication campaigns are analyzed, updating profiles and the OOID idenfifiers of the UTs (102).

Through the campaign module information is exchanged between the various elements of the architecture in order to send a push-type message through the various possible channels enabled to the user terminal (102) of! user. On the other hand, a communication subsystem is designed based on events (discrete pieces or pieces of information) from the UTs (102) and Node / s (101) to a server (SETS, Send Events to Server) and a communication protocol from the server to the Node and UTs (REFS: Receive Element from Server).

In various impiementations for any communication between the elements of the architecture one could use Node events (those traveling between the Node (101) and the server node (103) or SDK events (those traveling between the SDK and the serving node (103), with the following elements among others:

Timestamp, universal time stamp of the APPJD event, identification of a digital application or physical space

 NodeJD, identify a node or a physical zone.

 Geoloc, coordinates and geo-location precision.

 Type event or information that is sent and its specific parameters.

 Morelnfo, you can use it to send more maintenance information, sending lists, objects, etc.

The OOID identifier can include, among others, the elements shown in figure 3. In this way, there is a device identifier (dID), which can be generated from a SHA1 Hash at the execution time of the address of the layer of access to the medium (whether or not random) that can be obtained in the frames listened to from the Node (101), or via software in certain versions of the OS of the UTs (102).

Although the rest of the elements present in figure 3 and which are described below were not included, the dID would always be present in the OOID even if it is a random, non-approved value, in turn the dID could be updated by the process of propagation of OOID by the SDKs (104, 105), the server node (103) or the Node (101) at the time the approved OOID is known.

As can be seen from FIG. 3, the OOID can comprise an OUI, which corresponds to the first three bytes of the address of the access layer. middle of! ends! of user (102) and will be used in the process of approval of! QOID

The object of the invention contemplates the implantation of a succession of signatures that we denominate by its term in English array or in Spanish succession of Signatures, which allow to add signatures to it, understood said signatures as characteristics of the user terminal (102) or of its behavior, which can be obtained and propagated by Nodes (101), Server Node (103), SDK APP (104) and WEB SDK (105) in combination. That is, they are obtained by combining online and offline information sources.

The object of the invention makes use of processes of homologation, unification, acceptance and propagation of OOIDs. In some implementations the following processes could be performed in any of the architecture components that receive events with OOIDs from UTs (102), especially in the Server Node (103); for this, in the homologation, those OOIDs can be marked with the status of Approved, which by any method has proven that their dID comes from a real and non-random address of the access layer to the middle of the user terminal (102). They are used to determine the number of unique visitors and to have unique identification in the message delivery system.

In some implementations, the Approved OOIDs can be obtained directly:

 - By offiine detection of the Node from the direction of the access layer to the middle area! of the frames listened to both when the device is discovering frames and when it is associated with an access point, hereinafter AP.

 - By detection of the Node (101) when the browser connects a UT (102) to a port! captive of! Node (101).

 - In the Android APP SDK (104) by software from the address of the medium access layer.

 - In the SDK APP (104) IOS up to iGS9 by software from the address of the access layer to! medium.

- In the SDK APP (104) OS software when the Smartphone has WiFi connectivity up to 10.3 from the address of the medium access layer. - From OS 10.3, different techniques are combined, such as the direct connection to the access point - the hidden AP of the Proximity Node or the propagation of the OOID between the different elements of the architecture.

In a possible alternative embodiment, the OOID could be homologated to generate the dID in the SDKs (104, 105) and Nodes, or later in the Server Node only with the OUI without the need to store or send the complete real address to the server node (103). (for privacy), for this could be contrasted against the list of OUI of official manufacturers, against a history of real OUIs (used by Chinese manufacturers that do not use the official list) available before the processes of aieatorlzación, and against a list of virtual or false OUIs, which have been detected as such, since they appear with unnatural behavior, even at night, and checked with the different models of UTs (102) in different locations.

In unification, the Unified status of a non-approved OOID can be marked when there is a high degree of coincidence or small distance between the set of signatures with another Approved OOID (which has been received through the propagation process. can create a record of unified OOIDs among them that would be used among other tasks to determine the number of unique visitors and visits in the offline behavior analysis process.When a device is unified, among other processes, the matching signatures between the OOID approved and the OOID not approved, and thus propagate a unified OOID in signatures In this process of unification could be removed repeated signatures or contained in others to optimize the process, and could be ordered so that the coincidence measurement could be implemented nimbly in the case of many firms, assigning a greater weight to the first firms that allow better identification of e unique form to a user terminal (102).

The distance between two signatures of two OOIDs (A and B) could be measured, and the

coincidence among OOIDs signatures according to the following formulas:

Distance D = (signature A- signature B x weight signature) where the signature weight is a configurable value that can be modified to fine-tune the system. And the coincidence between the set of the signatures of each OOID, as the sum of the distances of the firms compared one by one for those existing between both OOIDs,

Match C = Sum i = 1; i = n {D (i)}

Where n is the number of matching signatures available between both OOIDs.

 For acceptance, the Accepted status of a non-approved and non-unified OOID can be marked when there is a degree of overlap between the set of signatures with another Approved OOID. Likewise, a record of unified OOIDs could be created among them that could be used in the behavior system to determine the presence time the number of visits. In this case, the concatenation of signatures or propagation would not have to occur. A unified OOID record could also be created between them.

For the validation, it is possible to mark the validated bit (and therefore they could be used for the analysis and other processes) of those OOIDs that are not excluded from the for different reasons, among others:

 Because they are on blacklists (Robinson).

 Because they have been excluded by other valid data verification methods, such as:

 o They appear simultaneously in two very distant locations o They do not have enough detections with variations of power that imply a certain movement inside a space with several nodes (101), that is to say their behavior is similar to fixed devices.

A part of the method object of the invention is based on the online and offline identification from the propagation of the OOIDs obtained for the UTs (102), by several ways (such as events or silent push notifications) and is applied, not only to the server node (103) but to all the elements of the architecture, impiementing at least the functions that are appreciated in figure 5.

In this way it is necessary that when receiving an OOID, it is compared with the available QOiD, being updated if applicable according to the homologation methods, Unification, acceptance and vaiidation. Normally the SDK (104, 105) running the UTs (102), have information only of their OOID, but the server node (103) will receive at some point all the OOID generated in the system, the nodes (101) could receive information from all OOIDs or only from them (those in the same NodeID zone or APPID application).

The server node (103) can broadcast the approved OOIDs to other applications and browsers, mini-browser (which is launched automatically in some operating systems of UTs (102) when accessing a captive portal) and embedded browsers (webviews) through various techniques among others:

 - By silent push (actively).

 Through functions of the SDK every time a program is started or run

 APP process.

 - Using SDK functions every time you connect to a page with the HTML5 SDK

In this way, the propagation process guarantees the propagation of Approved OOIDs:

 Received from a WebViewBrowser that in turn has obtained it:

 o When opened by an APP

 o From a shared cookie.

 Received from the Browser that in turn has obtained it:

 o Updated by the server node (103).

 o Updated by the Captive Portal of the Node (101).

 Received from the server, which in turn has obtained it from:

 o Another App that has previously obtained it from:

 * The MiniBrowser, Browser with Connection to a Captive Portal of the Node (101)

^® The WebViewBrowser.

When propagating an OOID the number of the propagation status can be encoded, to know if it has been broadcast several times to all the elements of the architecture. Only the approved / unified and validated OOIDs are propagated, updated in real time. The server node (103) can update the status of the OOIDs that do not are Homologated to Approved and also update their value in the historical data associated with UTs (102), or only store the historical relationship between OOIDs from the date of approval without altering the OOID of past data.

In this way there is a system whose architecture and configuration allows carrying out the previous actions in order to implement, in a possible embodiment thereof, the method object of the invention. Said architecture corresponding to a preferential embodiment of the object of the invention comprises the device Node (101), which responds to a structure as shown in Figure 6.1 and which according to implementations may include among others the following functionalities labeled in said figure 6.1 , having in this way the following functionalities:

SETS: Listen and process frames that emit UTs (102) both when they are and when they are not associated with wireless networks that use Wi-Fi, ie WLAN type. From the information of said frames they could generate at the time of execution an OOID, process it among others with the approval, unification, acceptance and validation systems described above, and generate one or more Node events (101). They could listen and process frames that emit UTs (102) when they have b! Uetooth (BT) communications. From the information of said frames they can generate an OOID in execution time, process it among others with the approval, unification, acceptance and validation systems described above, and generate one or several Node events (101). Among other mechanisms, it is considered to establish a virtual private network (referred to in this document as VPN for its acronym in English) with the server that guarantees privacy of the information between both. The generated Node events can be stored until the connection to the server is available.] To save computation in the behavior systems, it is expected to be able to group the data of detected frames or detected detections and send them during a small time window. in a single node event, which also contains the OOID only the information of the number of detections and the average detection power. Therefore, Events may contain information from a single detection or several in a short space of time. Additionally, in each node event it could include, among other data, more information useful for remote maintenance (such as its IP address, GPS coordinates, list of nearby SSiDs).

 REFS Node: Among other information, it could receive, in real time from the server, information from approved OOiDs, for the execution of the unification process. Among other information to support all the functionality of the system could receive in real time from the server, information of events of other Nodes (101), OOIDs of UTs (102) that enter the Node Virtual geofence with their SSIDs, campaigns, profiles, communication tokens with the user terminals (102), the manufacturers GUI list, a history of OUIs available before the randomization processes existed, a list of virtual or false GUIs and the list of validated OUi.

- Hidden access point NODE: A hidden access point (AP) can be generated only known by the UTs (102) where the APP SDK (104) has been integrated, allowing WLAN connections with said UTs (102). It can also generate a BT point visible mode to pair with other user terminals (102) that know a link number (PIN) only available in the UTs (102) where the SDK APP (104) has been integrated, allowing BT connections with said UTs (102). In some implementations it could be by means of socket and that could, among other information, send its Approved OOID to the connected UTs (102), since it would have in the level 2 connection enough information to Homologate the OOID. Being able to disconnect them once confirmation is received that all the information in the UT (102) has been correctly received to be effective in the number of user terminal (102) connected simultaneously. A Captive Portal Node is responsible for generating an access point, an AP, visible in open mode with a captive portal, to allow connections with any user who wants it (for example, because he is trying to register in a fideiización program, validate a coupon received by email, or because you are looking for free internet access). Through dynamic modification techniques of! DNS of! node (101) or others of! holder! captive could redirect! or always! browser! user terminal UT (102) to the same domain (the one associated to the NS web server for example) thus loading the main web page of the captive portal of! Node that would include the WEB SDK (105). In this way Node (101) would identify and access the frames sent for the connection to the captive portal, could among other methods homologate the OOID and through the WEB SDK (105) store it in a local storage device! which we call by its English name! oca! storage or in the form of cookies associated to said predetermined domain ..

An unauthorized Bogue-type node that demotes Rogue Node can be responsible for generating WLAN beacon frames to announce an available SSID and force nearby user terminals (102) to send association frames if they have said SSID in their list of connected networks . Among other sources, the list of SSIDs to be announced could come from the one received from the server and previously obtained by the SDKs installed in the PTSs of the UTs, of the most popular SSIDs but not detected in the vicinity by the Rogue Node (since these are already announce) or of the SSID history announced in the WLAN discovery frames of the UTs that are included in the signatures of the OOID exchanged with the Server Node (103) (coming from other nodes). The mechanism to prioritize, optimize and trigger the announcement of SSIDs could be among others announce first and periodically, until receiving the response of the user terminal (102) in a configurable time frame, those SSIDs coming from the SDK APP (104) of UTs (102) that known by geo-location (which we can call Virtual Node) have entered some coordinates within a configurable radius around the Node (for example 0.5km).

A Beacon Node can be responsible for issuing frames by bluetooth according to the protocols Beacon ™ and EddyStone ™ that through an APP or the Navigator could be detected and through! SDK APP (104) and could generate a Node event (even if it was not generated by the node but by the UT (102) with the information of the Approved OOID if it was known by the UT (102).

Optionally you can use a direct Push node that allows to include a campaign manager within the node itself (101), avoiding delays in sending messages from the server, and making it the own node (101) e! that manages the sending of messages to the user terminal (102), or even when it has direct communication with the user terminal (102) by proximity through the system designed for that purpose, can call direct functions of the SDK (104, 105) to show the user the message directly (through among other techniques such as local push notifications, PopUps, etc.) without using the available channels of the user terminal (SMS, Push, Email, ..). The Node would receive to the Server Node (103) the tokens of the approved OOIDs as well as any other information related to the campaigns.

It could use among other techniques the offer through the HotSpot2.0 protocol to provide a communication channel and that the UTs (102) use this channel to ask an AP for the information of access to the network using the ANQP (Access Neiwork Query Protoco L with its address of the access layer to the real environment, thus increasing the probability of obtaining the approved OOID in less time for those devices that randomize it.I could use among other techniques to increase the probability of obtaining the homologated OOID in less time for those devices that randomize the address of the access layer to the medium, HoiSpot 2.0 HS2.0 to provide a communication channel and that the UTs (102) use this channel to ask an AP for the information of access to the network using ei ANQP (Access Network Query Protoco!) Offering its address of the access layer to the real media, in this way it could be used, among other techniques, the announce r frames of the protocol used to facilitate the pairing between devices called Wi-Fi Protected Setup (WPS), to force the UTs (102) to generate a UUID identifier, which will be collected as one more signature that will help unify the UTs (102 ) that randomize the address of the access layer to the real half.

To increase privacy in the location and identification with third parties of the UTs (102) that are in the physical space of scope of the Node (101) among other mechanisms, the node (101) can generate in real time or execution frames of discovery of the WLAN or BT networks, which are normally emitted by the UTs (102), using for this the same addresses of the medium access layer of the recently heard UTs (102), or of those heard by other nodes and that have been received by the propagation process, and also generated randomly with different common patterns similar to those usually received.

It is also contemplated to be able to perform the analysis of SSIDs received in the discovery frames among others, generating a signature for each SSID-S detected, which can be concatenated to obtain greater efficiency in the process of unification of OOIDs Pudiento to perform the analysis of the Elements Information (lEs) contained in WLAN frames such as Supported Bates, Higb Throughput capabilities, Interworking Capabilities, and WPS or Wi-Fi Protected Setup, we can have a high number of unified devices for certain models, and provide the signature base for the other models. Specifically through the signature lEs we can distinguish if it is a device OS8 or higher, which helps optimize processes of Unification, Acceptance and Validation. The possibility of carrying out the analysis of the shuffled and predictive seeds of the radios used by the UTs (102) to detect coincidences is also contemplated.

In those embodiments where the use of the APP SDK (104) makes use of the features of the APP SDK (104) shown in Figure 7 and respond to:

SETS:

 They could generate an OOID from the information available via software, and between other times each time it starts or before closing the application or APP or at the moment that there is any user interaction, SDK APP events could be generated (104) to the Server Node (103). In order to obtain the approved OOID, the APP SDK (104) could access the address of the middle access layer of the user terminal (102) and, if it is not accessible, a random dID and an uncertified OOIDs would be generated. When receiving information from the Server Node

(103) The OOID is updated with the OOID approved in iocalsiorage, cookies or other means to ensure the persistence of the information accessible to the SDK APP

(104). Object tracking and use:

 To learn more about tastes, interests, etc. functions that the programmer could use in his APP to monitor the behavior of objects and the user's own use of the APP by means of signatures obtained from:

 - SESSION-S Session Events, each time the user opens the APP, the number of sessions made by the APP in that user terminal could be increased by one (102)

 - CLICK-S clicks events, each time the user clicks, could accumulate the number of click on each object to analyze in a period

- Text events TEXT-S, every time the user types in a field or the programmer passes an alphanumeric character parameter (for example the points accumulated in the game or loyalty program or the opening or closing of the application).

 - Events of electronic transactions EGOMM-S, similar to text events but with specific parameters that identify order forms in electronic stores.

 - Events of visual impression of IMPR-S objects, where the total time and number of times an object has been visible on the screen of the user terminal (102) is collected, taking into account the space on the screen.

 - NAVI-S Navigation Events, which reflect the depth of navigation indicating whether it has passed through several sections of the APP before.

- Multimedia events MDIA-S, that pick up the activity configuration with players, for example if you have finished watching the video.

Tokens and personal data:

Among other data, data can be sent to the Server Node - personal or non-personal - that has been provided by the user and collected through the functionality of monitoring the behavior and interaction available, which can serve as communication idols ( ie identifiers in a communication system) among other data such as phone number or email, or social ogin that could serve as tokens for the sending of messages. Rogue:

 Among other data you could send to the Server Node (103) the SSIDs with which the end is connected! of user (102) that will reach the Node (101). REFS:

 Among other data, it is possible to receive, in real time, the Server Node (103), definition information of geo-limited areas or geofence by its name in English, information on campaigns such as its elements and objects, the OUI list of manufacturers, a history of OUIs available before there were randomization processes, and a list of virtual or false OUIs, the list of validated OUIs. Ai receiving external push notifications could manage the collection of notification parameters, so that automatically according to the programming of the campaign could open browsers embedded in the APP or external browsers. Geofence:

 A node-type event can be generated (as if a node had detected it by proximity), to have a virtual node at any physical point, and for the activation of the rogue node functionality in the node (101). interrogation:

 It can be connected to! AP access point hidden from the nodes or the BT connection offered by these, and through socket or other communication procedures exchange their approved OOID among other data. It will be in the process of installing the APP that the user would be asked for the appropriate permissions for direct connection to the hidden AP of the nodes or even the installation of a profile for that purpose if necessary in some models of operating systems of ETs.

Propagation:

 Among other moments every time you know your approved OOID you can spread to! Server node (103) as well as UT browsers (102), for this could use among other methods the following:

Open a browser embedded in the APP (peWebView) and pass it as parameters in the URL to the approved OOID. - Open an external browser configured by default in the user terminal and pass it as parameters in the URL the approved OOID.

PUSH Direct:

 Through an internal campaign manager such as the one described above, you can frequently analyze the list of campaigns and objects received to launch a Local Push Notification, avoiding the need to have any Internet connection to receive push messages at the time programmed in the bell.

INTERNAL_AP:

 In those UTs (102) that your OS / operating system would allow (with the appropriate user permissions) it could generate a hidden AP, while the UT (102) does not use the WLAN connection, to which any other UT can connect (102). ) -even the same one- obtaining the UT Approved SUID (102) in a manner totally analogous to how it is done in the node (101) by this means.

In the process of installing the SDK APP (104) the user will accept the conditions of use and will give all the appropriate permissions or even install the necessary usage profiles, for each of the functions described above, ensuring compliance with the legislation in this matter.

Privacy and permissions:

 In the process of installing the APP application with the integrated SDK APP (104) it is the user who authorizes all the permissions and accepts the conditions of use derived from all the functions mentioned above.

Firms:

It establishes the possibility of using capabilities or other identifiers obtained from the APP via OS APIs, such as IDFA / GAID, Carrier, screen resolution and color depth, Model, Memory, Installed Apps to generate other signatures. In particular, the IDFA / GAID signature could be generated, since this is a unique identifier per device accessible only via software from a mobile application. All mobile applications of the same device have the same GAID / IDFA provided by the manufacturer, for advertising use. Likewise, they could be used among other Gender, Date of Birth or Zip Code provided by the user directly in the interaction with the APP, to generate a signature based on personal data PiIS {Signature of Personal Information Identifl cable). This information will be provided and processed by the system in accordance with current legislation. That is, for example, these signatures will not be generated without the prior informed consent of the user, and may be eliminated.

It is also planned to use other non-personal data provided by the user directly in the interaction with the APP, to generate a signature based on non-personal data NPIS {Non-Personal Information Signature). This information will be provided and processed by the system in accordance with current legislation.

In those embodiments in which the SDK WEB (105) is used, it has to influence the functionalities that are shown in Figure 8 and that correspond

SETS:

 Among other times, each time you upload the website with the HTML5 SDK or before closing the page, you could generate SDK events that will be sent to the Node through calls to NS functions (for example, Php functions or other application platforms). Server). Ai receive information or when launched from an APP update your OOID, stored in / ocalstorage, cookies or other means to ensure the persistence of information accessible to the SDK. By connecting to the captive Portal of the node (101), the OOID stored in ¡ocalstorage or in cookies or other means is updated to ensure the persistence of the information accessible to the WEB SDK (105).

Object tracking functions:

To learn more about tastes, interests, etc. You can incorporate functions that the programmer could use in your HTML code to track the behavior of objects and the user's own use of the website or application by means of signatures obtained from: - SESSION-S Session Events, each time the user opens the WEB application, the number of sessions made by the WEB application in that user terminal (102) could be increased by one.

 - CLICK-S clicks events, each time the user clicks, could - accumulate the click number on each object to analyze in a period.

- TEXT-S text events, each time the user types in a field or the programmer passes a parameter of allanumeric characters (for example, the points accumulated in the game or loyalty program or the opening or closing of the application).

 - Events of electronic transactions ECOMM-S, similar to text events but with specific parameters that identify order forms in electronic stores.

 - Events of visual impression of IMPR-S objects, where the total time and number of times an object has been visible on the screen of the user terminal (102) is collected, taking into account the space on the screen.

 - NAVI-S Navigation Events, which collect the depth of navigation indicating whether it has passed through several sections of the site or WEB application before.

 - MDIA-S multimedia events, which include the configuration of activity with players, for example if you have finished watching a video, etc.

Tokens and personal data:

 Among other data you could send to the server node (103) those personal or non-personal data that have been provided by the user and collected through the functionality of monitoring the behavior and interaction available, among other information such as phone number or email , or access data to social networks that can serve as tokens for sending messages to the UTs (102). PUSH Web:

 To implement the so-called web push notifications, upon receiving the

Web SDK (105) an NS event in real time via AJAX or any other web protocol for sending asynchronous events, could open other windows (pop-up) or dynamically change the content of a banner on the website where it is integrated or any other action that the programmer wishes to integrate on the website.

Browser notifications:

 It is planned to use the browser's own notification system (depending on the type of browser opened) if it has the appropriate permissions.

Firms:

 A WEB-S signature can be obtained in the form of an array of signatures in turn from collecting information from the user terminal (102) according to the capabilities obtained from the WEB, such as, among others, UserAgent, http accept header, or the resolution of screen and depth of color among others. Could be used among others Genre, Date of Birth or Zip Code provided by the user directly in the interaction with the WEB site that are collected through the object tracking functions of the web SDK (105), to generate a signature based on data Personal PII-S (Signature of Personal Information Identify). Said information will be supplied and processed by the system according to current legislation. That is, for example, these signatures are not generated without the prior informed consent of the user. Other non-personal data provided by the user can be used directly in the interaction with the website, to generate a signature based on non-personal data NPI-S (Signature of Non-Personal Information). This information will be provided and processed by the system in accordance with current legislation.

Propagation:

Among other moments when the user launches the browser of the user terminal (102), each time he accesses a web site or application, the WEB SDK (105) could be loaded and techniques for passing parameters in the URL or other techniques , the Approved OOID would be exchanged with the NS. Ei OOi is stored in the / ocalstorage of the browser or in cookies if possible, among other methods. Also, when the embedded browser (type WebView) is launched from an APP with the APP SDK (104), the OOID homologated with the APP is exchanged. The OOI is stored in the browser's ocalstorage or in cookies if possible, among other methods. Analogously, when launching the external browser configured by default in the user terminal (102) and pass it as parameters in the URL the approved OOID. The OOI is stored in the! Oca! Storage of the browser or in cookies if possible, among other methods.

The server node (103), whose main functions are shown in Figure 9.1, has the following functionalities:

SETS:

 The events of the SDK (104, 105) and nodes (101) can be received, stored and processed, using web servers, databases and / or applications.

REFS:

 It allows sending and responding to requests for information from the SDKs (104,105) and the Nodes with data among others of SSIDs, tokens, profiles, campaigns and results, to the OUI list of manufacturers, a history of OUIs available before there would be the processes of randomization, and a list of virtual or false GUIs, the list of GUIs validated.

ROGUE:

 You can receive the list of SSIDs to which a UT (102) is connected through the SDK APPs (104). You can also broadcast the list of SSIDs received from the SDK (104,105) to the Nodes (101).

Firms:

From the combination of the event identifiers, campaigns and responses or results, you could create a different OOBS signature for each combination of information sent to the user terminal (102) by messages anywhere or in a certain place and subsequent detections made by the Node (101); for example, if a user terminal (102) was detected in a zone B that was in an area A which, within the programmed timeframe of the campaign, has been invited by means of a message to move to zone B. The object of the invention may be of interest in applications of behavioral studies or analysis of user interaction. For this, the object of the invention can provide a behavior analysis system as detailed in Figure 9.2. Said behavior analysis system has a series of functionalities that allow, from the events of Node (101) and SDK (104,105) in the server node (103) to calculate or compute visitors, visits and visit is [ 9301], as well as any other indicator or ratio considered of interest from these to obtain the cross-online and offline behavior of the UTs.

Likewise, it is foreseen to submit said events to the processes of Homologation, Unification, Acceptance and Validation and Propagation described above.

Normally the nodes (101) generate events of type Node and the SDK (104,105) of type SDK; but the SDK (104,105) could generate node-type events, when the detection is done by beacon. The nodes (101) could generate SDK type events when the detection is made to connect to a captive portal (an SDK type event is generated). This information will be treated by the behavioral system as if it came from the type of event received.

To carry out a count of visitors, visits and visit is in a physical site (physical area of scope of the Node (101)) or an online site (App or Web where the SDK APP (104) is integrated or in the SDK ( 105)) totally analogous methods are used. In different impiementations, models similar to the one shown in figure 9.3 can be implemented to obtain visitors, or visits.

Each time an event is received in the Server Node (103), it is recorded and can be analyzed taking into account the information of previous available events, over a period of time. Subsequently, different indicators can be obtained for different periods of time such as hours, daily, weekly, monthly, annual, etc. For the analysis of events, it is possible to configure the time of the visits analysis windows, and the time of the gap between the so-called visits is (concept analogous to sessions on a website, but applicable to offline and online). The purpose of the analysis window is to decide if an event of type Accepted for the same OOID extends the time of visit or visit of the same visitor. The goal of the gap between visits is to distinguish different visits of the same visitor considering that long periods of inactivity are due to different reasons or interests in the visit to a physical or digital space. In an online analysis the gap between visits is, in general, greater than the gap between sessions, that is, the time of inactivity to consider that a new session of the same visitor begins. Therefore, the analysis of events includes configuring: a time of the windows of analysis of visits, where a window of analysis includes a decision on whether an event of type Accepted for the same OOID extends the time of visit or visit of the same visitor , and a time between visits, where said time is defined as elapsed between visits by the same visitor.

Normally the analysis window is smaller than the gap and this smaller than a full day. After the time of the gap between visits is, the events are part of a new visit. After the visit or session gap, only the approved or unified events start the period of the analysis window. The validated, unified or accepted valid events received within the period of the analysis window would be grouped in the same visit, and therefore are associated with the same visitor, and therefore of the same visit. The accepted events allow to extend the time of presence of a visit of the same visitor, and therefore also extend the presence of a visit.

With this method visits will be extended dynamically as more events arrive within a period of time, thus obtaining the times of presence of a visit in a given area, and analysis of Online or offline behavior could be performed in real time. considering with the data of previously received events, and not in real time analysis with the data of a whole day or a month.

From the visits generated by the same visitor in the behavior analysis module in some implementations, many other functions and computations could be performed, among others:

They could establish criteria to validate detections. Among others if the same visitor is offíine in two geographically very remote areas. - Analysis of average times of presence.

 Evolution of visitors.

 Flows between several zones or online sites.

 Visits to a physical site that simultaneously or previously use the App or Web.

A field of application of specific interest for the implementation of the object of the invention is that in which the method described here is complemented by a manager of profiles, campaigns and results such as that shown in Figure 9.4 where the interaction between components is shown. minus the following functions that provide the following functionalities:

A profile manager, which has among other tasks, calculate profiles or user groups that should receive messages from the server or by proximity when detected by the node (101), based on certain criteria of segmentation or behavior grouping, or You can also import / upload ios 00! D of the UTs (102) from an external behavior analysis platform. Based on the events of Node (101) and SDK (104,105), the results of visitors and visits to the behavior system, and the rules introduced in the campaign manager, the profile management system could calculate or compute which UTs (102) have the same cross-online and offline behavior profile, as well as any other marketing indicator such as a key performance indieator (KPI) that is considered of interest from these data, an example of KPI can be the number of times that on average, visitors with a family profile repeat visits in a month. For example, a profile that could be called family type, would be those devices that yesterday generated a visit to the website of a children's store in the shopping center, today they have opened the APP of the shopping center to visit the cinema billboard looking for a children's movie and they have also been detected by a node with a visit presence of more than 5 minutes in the shopping area of the shopping center. Another example of crossed profile definition online and offline would be those who usually arrive at the office more than 10 minutes before the time of entry and have ever used the corporate APP of the company to reserve meeting rooms. In the definition of the profile, responses to the messages received may be included, for example, a profile of employees in active training would be those employees who receive messages when they receive messages. Inviting them to attend face-to-face courses, they finally go to the classroom where this in-person course is held.

A system for triggering messages by physical or digital proximity, based on when a device is detected through a Node event (101) in addition to generating a valid and homologated visit in real time by the behavior system, at this time it is checked if the OOID is included in an active profile and an active campaign, and a message is sent immediately through the campaign manager so that it can be read in real time to the user terminal (102) by any of the channels available This system could, among other functions, send the messages to the UTs (102) programmed at the opportune moment according to the information programmed in the campaign manager when receiving Node (101), Virtual Node (103) or SDK (104,105) events. ) among other trigger events. That is, by proximity or visit a physical site or a digital site.

There are available as Online channels all those that allow direct sending to the user terminal (102) without the need for the user terminal (102) to pre-order the message (ie, push type). For this, identifiers are available for the communication (íokens) of each user terminal (102). Among others, the channels are chosen from: Push Notifications, Email, SMS, Push Web Notifications] or Browser Push Notifications. For the sending of messages to the UTs (102), the Approved or Non-Approved OOIDs can be linked to each User entity (that is, the entity that stores said communication idols and other personal data) in the server Node (103). Although a user terminal (102) does not have an approved OOID, it can receive messages from the server node (103), but it would need the validated and validated OOID to push messages by proximity to the node (101).

The campaign manager, among other tasks, could generate or pre-load the contents and formats of the messages for the different channels chosen, as well as dates, zones, online sites, and any other variable useful for the definition of the campaign. It is planned to launch the campaigns and messages in the moment programmed in e! campaign manager the messages to the programmed UTs (102). That is, by time and profile; It is also planned to import campaigns and messages from third parties through webservices or other procedures, to complete the functionality of the campaign manager.

The results manager, among other tasks, collects the confirmation information in sending messages from the proxies of each channel, the answers associated with the digital spaces that have been used in the communication (filling in the form, personal data, surveys, subscriptions, etc ..), as well as its behavior in the physical and digital space after the sending of coupons, offers, information, surveys, other ways to suggest visiting physical or digital sites, etc ... Therefore, it would be able to calculate for example how many users who have received an offer by email on Friday afternoon, have been detected in the supermarket during Saturday morning.

Depending on the information received from the result of the message, the information of the campaign manager can be updated. The results manager, in addition to reporting efficiency data, can act as a feedback loop to modify profiles and campaigns in real time, achieving a dynamic optimization based on the user's response

Thanks to the above features the system makes it possible to do what is known as remarketing but offline, which consists of sending a message to the user terminal (102) by proximity or offline presence, knowing previously their tastes or interests through digital behavior analyzed, for example in the APPs or WEB sites that have the SDK integrated, or through the physical behavior analyzed in the areas where there are nodes, and even based on responses to previously sent communications.

Claims

one . Unique identification system of electronic devices (102) capable of executing mobile applications, system characterized in that the electronic devices (102) comprise:  to. an SDK APP (104) for mobile applications, and  b. a web browser that in turn integrates a web SDK (105); and in that the system comprises interconnected a series of nodes (101) that are process capable devices equipped with wireless communication means, where at least one of said nodes (101) is configured to listen and process information of radio signals in different frequency bands to determine the presence and identify the electronic device (102). 2. Unique identification system for electronic devices (102) capable of executing mobile applications, system characterized in that it additionally comprises a server node (103) configured to analyze and propagate electronic device identifiers (102). 3. Unique identification method of electronic devices characterized in that it comprises, by means of a node (101) with process capability and equipped with wireless communication means adapted for listening and analyzing radio signals, listening and analyzing radio signals to determine the presence of at least one electronic device (102) in a physical area in which the node (101) is located. Method according to claim 2 characterized in that the analysis carried out by the node (101) comprises demodulating and decoding the signal. Method according to claim 2, characterized in that the detection of the presence of a user equipment (102) in a physical area is carried out by analyzing received frames. Method according to claim 2, characterized in that the radio signals are comprised in frequency bands between 2.4-3.6 and 5Gbz. Method according to claim 2 characterized in that the identification comprises a generation of at least one identifier (OOID) of type increases! and distributed, based on a combination of signatures that come from the analysis in real time and historical events generated by the electronic device (102). 8. Method according to claim 8, characterized in that generating the identifier (OOID) comprises generating device identifier (dlD) from a Hash SHA1 at the time of execution of the address of the medium access layer obtained from the listened frames. Method according to any one of claims 1 to 8, characterized in that it additionally comprises and complements a system for triggering messages by physical or digital proximity, which comprises detecting:  to. a device is detected through a Node event (101), b. generate a valid and homologated visit in real time,  c. Check if the OOID is included in at least one of: an active profile and an active campaign, and  d. to send a message so that it arrives in real time to the user terminal (102) by any of the available channels. Method according to any one of claims 1 to 8, characterized in that it additionally comprises implementing privacy in the location and identification with third parties of the UTs (102) that are in the physical space of scope of the Node (101), where the node ( 101) generates in real time or execution frames of discovery of the WLAN or BT networks, by the UTs (102), using for it: to. the same addresses of the medium access layer of the recently heard UTs (102), or b. the same addresses of the access layer to the medium of the UTs (102) heard by other nodes (101)  that have been received by the propagation process, and also generate them randomly with different common patterns similar to those received. 1. Method according to any one of claims 1 to 8, characterized in that it additionally comprises calculating a count of visitors and visits where said calculation comprises in turn:  to. receive and register an event of the server node (103) each time it is received,  b. analyze said event taking into account the information of previous available events, during a period of time,  c. get different indicators for different periods of time 12. Method according to claim 1 where the analysis of events comprises configuring:  to. time of the windows of analysis of visits, where a window of analysis includes a decision on whether an event of type Accepted for the same OOID extends the time of visit or visit of the same visitor, and  b. time between visits, where said time is defined as elapsed between visits by the same visitor.