Systems and methods for associating data sources with a mobile device using spatial and temporal analysis

Abstract

Various embodiments of the present technology generally relate to data delivery. More specifically, some embodiments of the present technology relate to systems and methods for associating data sources with mobile devices using spatial and temporal analysis. The delivery of data enables various services for and about mobile devices based on data stored in enterprise, commercial, and government databases, which are currently not linked to individual mobile devices. Some embodiments allow advertisers to better determine their target audience for advertising with higher accuracy.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Patent Application No. 16 / 583,212, filed on September 25, 2019, now U.S. Patent No. 10,687,174, which is incorporated herein by reference in its entirety. Technical Field

[0003] Various embodiments of the present technology generally relate to data delivery. More specifically, some embodiments of the present technology relate to systems and methods for using spatial and temporal analysis to associate data sources with mobile devices.

[0004] Summary of the Invention

[0005] Various embodiments of the present technology generally relate to data delivery. More specifically, some embodiments of the present technology relate to systems and methods for using spatial and temporal analysis to associate data sources with mobile devices. The delivery of data supports various services for and about mobile devices based on data stored in enterprise, commercial, and government databases, which are currently not linked to individual mobile devices. Some embodiments allow advertisers to better identify their relevant target audiences with higher accuracy.

[0006] Some embodiments use location data records from websites, mobile advertising networks, mobile applications, and / or the web, whose sensors are located in shopping malls, airports, transportation terminals, hotels, offices, medical offices, elevators, etc. This location data can be used to build location profiles that can be linked to a residential address through a series of analysis processes. Once a mobile device is associated with a residential address, any database containing the residential address as a data element can be associated with the mobile device to build enhanced services that can be delivered to the mobile device or services that can be used to provide location and situation information that requires a mobile device in a certain area to build the profile.

[0007] In various embodiments, the system can also have the ability to group devices into "social networks" based on an analysis of the overlap of location data for a single location input into the system or multiple locations autonomously identified by the system. These social networks can be further analyzed using corresponding data elements in a linked database to refine the social networks based on common characteristics found in the data.

[0008] Various embodiments can perform one or more of the following functions:

[0009] 1. Provide an identification of a mobile device to an individual or household, which can be used to match back any database that uses an address as a key element to identify data.

[0010] 2. Provide an identification of a mobile device, where the system can be used with any type of unique mobile device identifier, such as UDID, Wi-Fi MAC address, Bluetooth ID, browser cache files (cookies), or any other persistent or semi-persistent identifier. A semi-persistent identifier is an identifier that exists for a period of time before being changed, which can be one day, one week, one month, or longer.

[0011] 3. Provide an identification of a mobile device, where the system can be used with any type of mobile device on a satellite, cellular, or Wi-Fi network, using any type of service plan, including subscription, corporate, prepaid, etc.

[0012] 4. Provide an identification of a mobile device, where the system provides a cross-match of multiple mobile device identifiers with a single anonymous identifier.

[0013] 5. Provide an identification of a mobile device, where the system provides anonymization of data so as to protect privacy when the data is used for commercial purposes.

[0014] 6. Provide an identification of a mobile device, where the system can be used with any mobile device data including the following elements: 1) mobile device identifier, and 2) geographical location tags, such as a latitude and longitude pair or other location encoding system. A time / date stamp associated with the mobile device data is desired and it may or may not be necessary to link the device to a database, but it may be required for some applications and analyses to deliver different services.

[0015] 7. Provide an identification of a mobile device, where the system works with any mobile device location data and takes into account the variation in the accuracy of the mobile location data depending on the data source.

[0016] 8. Provide an identification of a mobile device, where the system can obtain real-time data as well as batch data.

[0017] 9. Provide an identification of a mobile device, where the system delivers linked data to commercial services, merchants, governments, and other customers in three ways - 1) in response to a query about an individual device, 2) in response to a query about a location or a radius around a location, or 3) in response to a query about a list of devices or a group of devices.

[0018] 10. Provide an identification of a mobile device, where the system does not require any subscriber data from a mobile carrier to link the device back to any database.

[0019] 11. Provide an identification of a mobile device, where the system does not require any location data from a mobile carrier.

[0020] 12. Provide identification of mobile devices, where the system can identify a "social network" of devices with common interests based on location data, which can be linked back to a commercial database for analysis purposes.

[0021] 13. Provide identification of mobile devices, where the system can identify a "social network" based on a single selected location input into the system or based on multiple locations autonomously generated by system analysis.

[0022] Embodiments of the present technology also include a computer-readable storage medium that contains a set of instructions to cause one or more processors to execute the methods described herein, variations of the methods, and other operations.

[0023] Although multiple embodiments are disclosed, other embodiments of the present technology will become apparent to those skilled in the art from the following detailed description, which shows and describes illustrative embodiments of the present technology. As will be appreciated, the technology is capable of being modified in many ways, all of which do not depart from the scope of the present technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Embodiments of the present technology will be described and explained by using the drawings, where:

[0025] Figure 1 Shows an example of a network-based environment where some embodiments of the present technology can be utilized.

[0026] Figure 2 Shows various components and interactions according to one or more embodiments of the present technology.

[0027] Figure 3 Is a block diagram showing various data and partner components according to various embodiments of the present technology.

[0028] Figure 4 Is a block diagram showing an advertisement network partner using an anonymous request to obtain data from the system according to some embodiments of the present technology.

[0029] Figure 5 Is a flowchart showing a set of exemplary operations for associating a mobile device with a residential address according to one or more embodiments of the present technology.

[0030] Figure 6 Shows a graphical structure corresponding to a social link in a social network.

[0031] Figure 7 Is a flowchart showing an embodiment of a method for generating a location social network.

[0032] Figure 8 is a flowchart showing a method for detecting relocation.

[0033] Figure 9 is a table showing examples of detecting relocation. The table shows two address changes.

[0034] Figure 10 shows an example of a computer system in which some embodiments of the present technology can be utilized.

[0035] The drawings are not necessarily to scale. For example, the sizes of some elements in the figures may be enlarged or reduced to help improve the understanding of the embodiments of the present technology. Similarly, for the purpose of discussing some embodiments of the present technology, some components and / or operations may be separated into different blocks or combined into one block. Further, although the present technology may be subject to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. However, it is not intended to limit the technology to the specific embodiments described. On the contrary, the technology is intended to cover all modifications, equivalents, and alternatives falling within the scope of the technology as defined by the appended claims. Detailed Description

[0036] Various embodiments of the present technology generally relate to data delivery. More specifically, some embodiments of the present technology relate to systems and methods for using spatial and temporal analysis to associate data sources with mobile devices. Some embodiments enable the delivery of data to support various services for and about mobile devices based on data stored in enterprise, commercial, and government databases that are not currently accurately linked to individual mobile devices. One application of the technology is to allow advertisers to better target their advertisements to relevant target audiences with higher accuracy. The technology uses location data records from mobile advertising networks, mobile applications, and hundreds of networks, the sensors of which are located in shopping malls, airports, transportation terminals, hotels, offices, medical offices, elevators, etc. The location data can be used to build location profiles, which can be linked to residential addresses through a series of analysis processes.

[0037] Once a mobile device is associated with a residential address, any database containing the residential address as a data element can be associated with the mobile device to build enhanced services that can be delivered to the mobile device or services that can be used to provide location and situation information needed to build the profile using mobile devices in a certain area. This information can also be used to build a "social network" that identifies individuals with common interests, associations, and social dynamics to provide additional insights into mobile users.

[0038] Large amounts of data about each individual and household are stored in corporate, retail, government, and marketing databases. This data can include any type of data collected today - demographic data, psychographic data, behavioral data, purchase data, interest data, criminal data, occupational data, registration data, survey data, medical data, etc. This data can be used for a variety of purposes, including advertising, marketing, location studies, public safety, healthcare, etc. There are many technologies for capturing location data from mobile devices and building a historical location profile associated with the device.

[0039] The challenge is to link the mobile device to the individual or household such that the data in these existing databases (usually keyed by name and address) can be used to provide enhanced services to the user of the mobile device and to extend the services available to advertisers, merchants, and governments that utilize location data from the mobile device. Even though these commercial and government databases have mobile phone numbers in the database, they are still not easily linkable to the mobile device for the delivery of other services. Mobile applications and services can only access device ID keys, mobile data network ID keys, Wi-Fi network keys, Bluetooth IDs, cache files (cookies), and software-defined persistent and transient device identifiers that do not exist in these databases.

[0040] Identifying the home address associated with a mobile device can be done by the mobile carrier from their billing and provisioning databases, but this information is not available to other service providers and government agencies. To provide enhanced services, these commercial and government agencies need an alternative solution that can accurately identify the home address of the mobile device to link to their data that does not rely on mobile carrier data or databases.

[0041] One of the major trends in marketing is social-based marketing through the use of social networks, aimed at reaching like-minded consumers based on their shared social interests and affiliations. Unfortunately, the ability to reach these audiences is controlled by some large social network companies, which determine the way advertisers reach and interact with these consumers. Mobile devices provide a great reach for advertisers, and their ability to reach social networks and interest groups independently of these large social network companies provides new ways to advertise and interact with these consumers. There would be great power if these social networks and interest groups could be linked to the commercial and marketing data associated with these consumers, allowing for richer analysis of these groups and enabling predictive modeling to find similar types of customers.

[0042] The challenge lies in attempting to identify mobile devices within social or interest groups. Mobile advertising networks, mobile applications, and mobile websites have billions of records associated with mobile transactions that can be mined to create a social network "graph" that links these devices together and, in turn, links individuals together. Multiple embodiments of the present technology provide solutions to this challenge.

[0043] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present technology. However, it will be apparent to one of ordinary skill in the art that embodiments of the present technology may be practiced without some of these specific details.

[0044] In addition, the techniques described herein may be embodied as dedicated hardware (e.g., circuitry), programmable circuitry appropriately programmed with software and / or firmware, or a combination of dedicated and programmable circuitry. Accordingly, embodiments may include a machine-readable medium having instructions stored thereon that may be used to program a computer (or other electronic device) to perform a process. The machine-readable medium may include, but is not limited to, optical disks, compact disk read-only memory (CD-ROM), magneto-optical disks, ROM, random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), application specific integrated circuits (ASIC), magnetic or optical cards, flash memory, or other types of media / machine-readable media suitable for storing electronic instructions.

[0045] The term

[0046] Brief definitions of terms, abbreviations, and phrases used throughout this application are given below.

[0047] The terms "connected" or "coupled" and related terms are used in an operational sense and are not necessarily limited to direct physical connection or coupling. Thus, for example, two devices may be directly coupled, or may be coupled via one or more intermediate media or devices. As another example, devices may be coupled in such a way that information can be passed between them without sharing any physical connection with each other. Based on the disclosure provided herein, one of ordinary skill in the art will understand that there are multiple ways of being connected or coupled according to the foregoing definitions.

[0048] Phrases such as "in some embodiments", "according to some embodiments", "in the illustrated embodiments", "in other embodiments", etc. generally indicate that the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the present technology and may be included in more than one implementation. Moreover, such phrases do not necessarily refer to the same or different embodiments.

[0049] If the specification states that a component or feature “may” (e.g., “may”, “can”, “could”, or “might”) be included or have a characteristic, it is not required that the specific component or feature be included or have the characteristic.

[0050] The terms “module” or “engine” generally refer to generic or specialized hardware, software, or firmware (or any combination thereof) components. Modules and engines are typically functional components that can generate useful data or other output using specified inputs. A module or engine may or may not be self - contained. Depending on the specific implementation or other considerations, a module or engine may be centralized or functionally distributed. An application (also referred to as an “app”) may include one or more modules and / or engines, or a module and / or engine may include one or more applications.

[0051] General Description

[0052] Figure 1 is a block diagram of a network - based environment 100 according to one or more embodiments of the present technology. As Figure 1 shown, user devices 110A - 110N can use network 115 to submit information and obtain information from data delivery platform 120. User devices 110A - 110N can interact with data delivery platform 120 through an application programming interface (API) running on the device's native operating system (e.g., or ANDROID TM ). Through data delivery platform 120, mobile device users can use, for example, spatial and temporal analysis through data delivery platform 120 to associate data sources with the mobile device as a target for the delivery of customized data. Content management platform 125 can enable the delivery of data stored in database 130 to support a variety of services for and about mobile devices, these services being based on data stored in enterprise, commercial, and government databases that are not currently accurately linked to individual mobile devices.

[0053] For example, data delivery platform 120 can use location data records from websites, mobile advertising networks, mobile apps, and hundreds of networks, whose sensors are located in malls, airports, transportation hubs, hotels, offices, medical offices, elevators, etc. This location data can be used to build location profiles, which can be linked to residential addresses through a series of analysis processes. Using this information, a customized profile can be built around the mobile device.

[0054] User devices 110A - 110N can be any computing device capable of receiving user input and transmitting and / or receiving data via network 115. In one embodiment, user devices 110A - 110N can be any device with computer capabilities, such as a personal digital assistant (PDA), mobile phone, smartphone, wearable computing device (e.g., glasses, watch, etc.), tablet computer, or similar device. User devices 110A - 110N can be configured to communicate via network 115, which can include any combination of local area networks and / or wide area networks, using wired and wireless communication systems. In one embodiment, network 115 uses standard communication technologies and / or protocols. Thus, network 115 can include links using technologies such as Ethernet, 802.11, Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, CDMA, Digital Subscriber Line (DSL), etc.

[0055] Similarly, the networking protocols used on network 115 can include Multiprotocol Label Switching (MPLS), Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP). Data exchanged via network 115 can be represented using technologies and / or formats including Hypertext Markup Language (HTML) or Extensible Markup Language (XML). Additionally, traditional encryption technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), and Internet Protocol Security (IPsec) can be used to encrypt all or part of the links.

[0056] A variety of network communication mechanisms can be used to Figure 1 The various components shown in can be coupled to network 115 using a variety of network communication mechanisms. These network communication mechanisms can communicate with other electronic devices by transmitting and receiving wireless signals over network 115 using licensed, semi - licensed, or unlicensed spectrum. In some cases, network 115 can include multiple networks, even multiple heterogeneous networks, such as one or more border networks, voice networks, broadband networks, service provider networks, Internet Service Provider (ISP) networks, and / or Public Switched Telephone Network (PSTN), which are interconnected via operable gateways to facilitate communication between the multiple networks. Network 115 can also include third - party communication networks, such as Global System for Mobile Communications (GSM) mobile communication networks, Code / Time Division Multiple Access (CDMA / TDMA) mobile communication networks, third - generation or fourth - generation (3G / 4G) mobile communication networks (e.g., General Packet Radio Service (GPRS / EGPRS)), Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS), or Long Term Evolution (LTE) networks, or other communication networks.

[0057] Figure 2 Illustrates various components and interactions in accordance with one or more embodiments of the present technology. The system can correlate data in merchant, commercial, and government databases with mobile device data from a variety of providers, including mobile advertising networks, mobile carriers, mobile apps, merchants, Wi-Fi networks, and any other viable sources. Figure 2 The components shown in provide some examples of means for performing the various operations described.

[0058] In some cases, the system collects mobile device data. The mobile device data may include, but is not limited to, the following event data: mobile network call data, mobile data network registration and usage, mobile device location data, mobile device browsing and network data, transaction data, mobile app data, social media data, purchase data, login data, device sensor data, credit card data, etc. Mobile device event data may include one or more of the following fields: 1) device identifier, such as UDID, MAC address, cookies, or any other persistent or semi-persistent identifier; 2) location information, typically latitude and longitude or address; and / or 3) timestamp, including date and time, in minutes and seconds. Note that not all data must include a timestamp to provide a basic match. In some embodiments, timestamps can be used to cross-match data sources with different device identifiers.

[0059] Mobile device event data can be clustered by location, device identifier, and time of day. These clusters are then evaluated based on home address data. The address data is then used to link the mobile device IDs to other databases. As part of this process, the system anonymizes the data to provide enhanced security for the data collected and linked and to ensure that personally identifiable information (PII) is not disclosed to anyone. As part of this process, anonymized IDs can be created such that PII is never revealed when the data is used in customer applications.

[0060] Figure 3 Is a block diagram illustrating the use of an independent data processor to match output data from the system with data provided by an advertising network partner. Since PII is used in the matching process, an independent data process is used to prevent the system or the advertising network partner from accessing the PII. The output of the data processor is linked data that matches the two data sources.

[0061] As Figure 3 shown, the system can collect raw mobile device data as well as commercial, enterprise, and government data about individuals from a variety of partners. This data can be provided by Figure 2The system processes and uses it to create a system data warehouse that includes PII as a keyword. The system can output the data warehouse as a system file, which can be transmitted to other parties, including independent data processors.

[0062] Similarly, partners such as advertising networks also collect customer information from customers of partner services (applications, websites, etc.) and registered users of these partner services, and this information can be similarly accumulated into an advertising network data warehouse. The advertising network data warehouse can also use PII as a keyword. The advertising network data warehouse can also be output as a partner file for transmission to an independent data processor.

[0063] The independent data processor obtains the system file and the partner file and compares the PII keywords. The independent data processor creates an output file that contains combined records from the system file and the partner file, only for records that have matching PII keywords in both files. In some embodiments, if a record with a PII keyword is unique to only one of the files, it is not included in the output. The combined file is then transmitted to the advertising network partner for use. In various embodiments, the system can ensure that PII data of individuals not known to the system or the advertising network partner is not shared with them.

[0064] Figure 4 is a block diagram showing the use of an anonymization request by an advertising network partner to obtain data from a system according to some embodiments of the present technology. One advantage of using an anonymization request is that it eliminates the need to expose PII while providing real-time access to the system output.

[0065] As Figure 4 shown, the system collects raw mobile device data and business, enterprise, and government data about individuals from various partners. This data is processed by the Figure 2 system in and used to create a system data warehouse that includes PII as a keyword. The system then processes the system data warehouse through an anonymization process that removes or modifies PII using data that cannot be directly linked to PII. One way to do this is a one-way hashing algorithm such that no one can convert the data back to the original PII, but other methods include a matching table used within the system to map PII to usable non-PII data, but with much lower security as the matching table itself may be vulnerable to attack. For example, the anonymized data can be stored in a system mobile data mart that is accessible in real time.

[0066] When the publisher's website (or mobile application) sends a request to the partner advertising server, the advertising server in turn sends a request to the system target data engine, which provides an external interface to the system mobile data mart. The system target data engine obtains the anonymized keywords passed in by the advertising server and looks up data in the system mobile data mart. The data returned by the system data mart is transmitted to the advertising server, which in turn uses this data to determine what ads to return to the publisher.

[0067] Figure 5 FIG. is a flowchart showing an exemplary set of operations for associating a mobile device with a residential address in accordance with one or more embodiments of the present technology. Figure 5 The operations shown can be performed by a variety of means, including but not limited to a data analysis platform 120, a content management platform 125, a database 130, one or more servers, one or more processors, networks and networking hardware, a variety of modules or engines (e.g., a receiving module, a profiling module, a linking module, an associating module, etc.), and / or one or more computing systems such as those Figure 6 described below. As Figure 5 shown, location data can be received from one or more sources during a receiving operation 510. Using this information, a building operation 520 can build a location profile that can be linked to a residential address during a linking operation 530. An associating operation 540 can then use this information to associate the mobile device with the residential address.

[0068] Data operation process

[0069] Various embodiments of a system for linking mobile device data with other databases using spatial and temporal analysis can include one or more of the following components and processing algorithms, which can be executed on commercial servers using physical or virtual servers organized into server clusters. According to various embodiments, the system can perform one or more of the following seven functions:

[0070] Function One: Processing of Mobile Device / Location Event Data

[0071] Mobile device / location event data can be transmitted to the system in batch file format or in real time via an application programming interface (API) provided to data providers. Batch files transmitted to the system use standard secure file transfer protocol (FTP) technology. Real-time transmission is done on an event-by-event basis and uses an application programming interface (API) that is built using the WS02 open source platform. The API can be built using JavaScript Object Notation (JSON) and provides a way for partners to transmit data to the platform when requesting data. In some embodiments, the elements transmitted via batch file or API for any mobile device / location record can include at least:

[0072] · Device ID - Possible device IDs include, but are not limited to:

[0073] ο Mobile phone number

[0074] ο Unique device identifier (UDID)

[0075] ο International Mobile Equipment Identity (IMEI)

[0076] ο Mobile Equipment Identifier (MEID)

[0077] ο Electronic Serial Number (ESN)

[0078] ο Media Access Control (MAC) address (MAC-48 / EUI-48 / EUI-64)

[0079] ο Bluetooth address (BD_ADDR)

[0080] · Date: MMDDYY

[0081] · Time: HH:MM:SS

[0082] · Latitude: integer

[0083] · Longitude: integer

[0084] · Partner ID: Assigned by E2M for real-time feeds

[0085] Mobile event data can be considered PII because it contains unique identifiers for each mobile device. While it can be transmitted "in plain text" from data providers to the system, typically the mechanism involves a secure connection, and the mobile device ID data is encoded using an agreed-upon obfuscation algorithm (such as hashing) before sending the data. Once the system receives the data, it ensures that all mobile device IDs are obfuscated before being stored in the system database and used for processing. For example, this obfuscation can be performed by the data provider before transmission, or by the receiving system using the SHA-1 hashing algorithm, which is a one-way hash and cannot be reversed back to the original data. Any other similar one-way hash or encoding algorithm can replace the SHA-1 algorithm.

[0086] The incoming mobile event data is processed through a series of filters that organize the data in the system by mobile device ID. The data can be organized such that it is processed or evaluated with different priorities during subsequent processing. These filters can include, but are not limited to, the following:

[0087] · Time / Date Filter - Data can be segmented by event date / time, and timestamps can be normalized to a single time zone or multiple different time zones, even if the data comes from systems that store time using different default time zones. For example, a filter flags records that occur between 6:00 PM and 6:00 AM, giving higher priority for location analysis.

[0088] · Location Data Cleaning - These filters ensure the accuracy of location data in the following ways:

[0089] ο Correct or eliminate records with invalid latitude / longitude data that has been revoked by the provider, is missing leading minus signs, or is completely missing.

[0090] ο Discard records with default or "blacklisted" locations. The processing performed when identifying addresses associated with mobile devices creates a location blacklist of locations that often come from specific providers (ad networks or publishers) and are not valid locations for that device.

[0091] ο Adjust the accuracy resolution of cross-source data for processing based on the source. Depending on the data source, we can round latitude / longitude data to a specific number of decimal places to standardize the resolution across different data sources, or weight data points based on the accuracy associated with the source. This weighting can be applied based on the source or other information contained in the provided data, or can be defined individually for each source or each data point in the system. Note that this process can also be applied to previously processed or stored location data to continuously improve the quality of results in the system.

[0092] ο Discard location data associated with devices that have been marked as inactive or deleted by the system. The system can use multiple methods, such as analyzing the time since the last data point reported for the device, mobile carrier registration data, or other means of identifying a specific device as no longer in use. Once a device is marked, filters can be used when processing historical location data to eliminate data points from these devices from the processing.

[0093] · Mobile Device ID Filter - These filters evaluate the mobile device IDs passed to the system to check for existing IDs and identify which other mobile device IDs may be associated with the same device.

[0094] Once the movement event data has been processed by the filter and stored in the database, it is ready for location analysis. Location analysis is the process by which the system analyzes all the filtered movement event location data associated with an individual device to identify the locations most frequently associated with the mobile device. This processing uses a density-based scan algorithm to group these data points and find the central location of these groups of data points. Note that any other type of grouping algorithm can be employed.

[0095] Density-based scanning can treat each movement / location record latitude / longitude pair as a single point for clustering analysis. Clustering is performed for each device ID using multiple algorithms. The algorithms can use the following two parameters:

[0096] · Eps (e): The maximum radius of the neighborhood points. The current embodiment uses 30 feet, but is capable of adjusting the setting to balance accuracy with processing time.

[0097] · MinPts: The minimum number of points in the Eps-neighborhood (specified radius). The current embodiment uses 10 as this value, but other settings can be used to balance accuracy with processing time.

[0098] The algorithm can identify clusters of points that meet the density requirements of MinPts within Eps. Then each data point can be classified. Some embodiments use the following categories:

[0099] · Core points are points that have more than the specified number of points (MinPts) within Eps. These are the points located inside the cluster.

[0100] · Border points have fewer than MinPts within Eps, but are in the neighborhood (within Eps) of a core point.

[0101] · Noise points are any points that are not core points or border points. These points are ignored.

[0102] The clustering algorithm of one or more embodiments can work in the following manner:

[0103] · Arbitrarily select a point p.

[0104] · Obtain all density-reachable points from p with respect to Eps and MinPts.

[0105] · If p is a core point, form a cluster.

[0106] · If p is a border point, no points are density-reachable from p, and the next point in the database is accessed by Density-Based Spatial Clustering of Applications with Noise (DBSCAN).

[0107] · Continue the process until all points have been processed

[0108] The result of the clustering process can be a list that includes the location of the core points and the number of data points associated with that location. These locations can then be sorted from highest frequency to lowest frequency based on the number of data points associated with that location. The locations generated are geographical location coordinates using latitude and longitude, although any location reference system can be used.

[0109] Function 2. Identify the street address associated with each mobile device

[0110] Once the mobile event data has been processed and a list of results of locations has been generated for each device, these locations can be associated with the data source in one of two ways: 1) Location identifiers (e.g., latitude / longitude), and the location identifier associated with that pair can be compared with the location identifiers stored in the data source. If the data source uses street addresses and does not include location identifiers, as part of the processing of the input data for these sources, the system will generate location identifiers that can be used for comparison. 2) The second method is to use commercially available reverse geocoding services or databases to convert the locations generated for each device into street addresses (e.g., 123 Main Street, Anytown, CO, 80301). This processing aims to identify two main addresses for each device:

[0111] · "Residential" address: The residential address is crucial for linking mobile devices to commercial, merchant, and government databases that use the residential address as a key field. Residential address matches may match many devices to the same residential address, even if the address is a single-family home, because there are multiple devices and multiple individuals in the family. This is considered a "household" level match when returning data from the database. An anomaly is multi-family housing, such as an apartment building. Since the geographical location data used cannot distinguish between apartment numbers or floor differences, multiple households will have the same address for multi-family housing.

[0112] · "Business" address: It can be a merchant, school, retail, or other business address. Since the residential address matches at the household level of a single-family home, the daytime address is crucial for identifying individuals with single-family homes or households or individuals within multi-family housing units. The daytime address is compared with other databases, which include point-of-interest data, merchant directories, and other data sources that can be used to identify commercial and public entities at a certain location.

[0113] The quality of the addresses returned by commercial reverse geocoding services varies widely, attempting to return the street address closest to the incoming geocoding. These addresses are then compared with the addresses used as keywords in the commercial database containing profile information. In some embodiments, the system analyzes the addresses returned according to the commercial database and classifies them into one of the following categories:

[0114] · Exact match address - An address found in a commercial database.

[0115] · Exact match with city alias - An address found in a commercial database when using a city alias. The postal address names of some cities are different from the geocoded addresses.

[0116] · Incomplete match: But very close to the address - An address where the street number does not exactly match but can match the street number within + / -N house numbers of the address (where N can be defined in the system).

[0117] · Incomplete match: But very close to the address using the city alias - An address where the street number does not exactly match but can match the street number within + / -N house numbers of the address when using the city alias (where N can be defined in the system).

[0118] · Incomplete match: But slightly far from the address - An address where the street number does not exactly match but can match the street number between N and M house numbers of the address (where N and M can be defined in the system).

[0119] · Incomplete match: But slightly far from the address using the city alias - An address where the street number does not exactly match but can match the street number between N and M house numbers of the address when using the city alias (where N and M can be defined in the system).

[0120] · Incomplete match: But very far from the address - An address where the street number does not exactly match but can match the street number outside + / -M house numbers of the address (where M can be defined in the system).

[0121] · Incomplete match: But very far from the address using the city alias - An address where the street number does not exactly match but can match the street number outside + / -M house numbers of the address when using the city alias (where M can be defined in the system).

[0122] · Unmatchable address - Unable to meet any matching conditions.

[0123] · Unmatchable address even when using the alias - Unable to meet any matching conditions even when using the city alias.

[0124] · Unmatchable address

[0125] · Unmatchable address: No latitude / longitude or virtual latitude / longitude - The reverse geocoder cannot even return an address.

[0126] These categories can be used to rate the quality of the returned matches and improve the quality of the data provided. When creating location data points from street addresses for commercial data sources in the system, these categories can also be used to rate the quality of the location data points created from street addresses.

[0127] Function 3. Link mobile device IDs to home and personal-level data sources

[0128] Once the residential address associated with the device has been identified, it can be linked to the data provided in any database that uses it as a key element. These databases can be commercial, merchant, marketing, government, law enforcement, healthcare, or any other database containing home or personal information.

[0129] Using the residential address to match the device to this home and personal data will result in a one-to-one match for a home with only one person, or a many-to-many match for a home with multiple individuals - in a multiple-person home there will be many devices associated with the address that need to be matched to the individuals in the home. For multi-unit dwellings, such as apartment buildings, there will be multiple devices matching the address, which must first be matched to a specific home within the residence and then to the individuals within that specific home. While device matching at the home level is useful, it is more desirable to be able to identify the device associated with an individual within the home, or to identify the home within a multi-unit residential dwelling.

[0130] To match the device to an individual within a home or multi-unit dwelling, an analysis of the non-residential location clusters associated with each device ID can be used. The simplest is the identification of individuals within the home. The system uses external data sources that provide data for each person in the home, which can be used in relation to the characteristics of the location clusters. These data sources can be marketing data providers, online databases such as Linkedln and Hoover’s. Point-of-interest databases or other databases containing location-related information that can be associated with the location clusters and may be useful when compared to known data about the individual (such as interests, hobbies, entertainment activities, purchases, etc.).

[0131] By comparing the data associated with the non-residential locations generated for each device with the known data about the individual, the individual associated with the device can be uniquely identified. Similarly, age information can be compared to location records corresponding to schools to uniquely identify other family members. Throughout the process, the device can be associated with the individual members of the home and, by elimination, potentially with individuals for whom direct data matching is not possible. For services that prohibit the measurement, tracking, analysis, or serving of children, individual identification is particularly important.

[0132] The identification of individuals within a multi - family residential address is performed in a similar manner, with one enhancement. Additional processing is first performed to identify the devices associated with each household within the multi - family residence. This processing uses an overlapping analysis of the data of each mobile device to determine which devices have a significant amount of common location, indicating that the individuals of these devices are often together as family members. Once a device is identified as a household, the same processing used to identify individuals within the household can be performed to identify individual devices.

[0133] Function 4. Linking Mobile Device IDs in the Absence of Residential Location Data

[0134] Some mobile event data sources provide data that is only from commercial or public locations and does not include any residential location data after processing. To match the mobile device IDs associated with this "non - residential" data (NR data) back to a residential - based data source, the data can be linked to other IDs that have been linked to those data sources.

[0135] The process can use an overlapping analysis of the event location and timestamp data from the NR data and the event location and timestamp data from the linked source. In some embodiments, the analysis can build possible matches based on the number of overlaps and also allow for variations in the occurrence times of events from different sources, as finding an exact match is rare.

[0136] Some embodiments of the overlapping analysis can include the following steps:

[0137] 1) Each record in the NR data is compared by location with the location records from a data source that includes residential data.

[0138] 2) For the records with a location match, the timestamps are compared with the timestamp of the NR record (t) to find records within a specific variation N. Records within the window of t - N to t+N are considered possible matches for that device.

[0139] 3) Counts can be created by the device IDs from the residential data source that might match the device IDs from the NR data. Then these counts are sorted from largest to smallest, with the largest representing the most likely match between the two data sets.

[0140] 4) Then the possible matching residential data source device IDs are compared with the possible matches of all other NR data devices to determine whether multiple NR data device IDs are possible matches for the same residential data device ID. If more than one device might match, they are sorted by the highest number of matches.

[0141] Repeat the process with different parameters on existing NR data, or repeat the process when acquiring new NR data and acquiring new residential data, to improve the results and obtain the highest quality match possible. Once a match is obtained, all household and personal data linked to the residential data device ID can now also be linked to the NR data device ID.

[0142] The process can be performed on any device data that does not include the residential location, such as public Wi-Fi data, Bluetooth data, digital outdoor sensor data, in-store sensor data, etc.

[0143] Function 5. Identify "social network" groups

[0144] Unique groupings of devices can be created through additional location and data analysis. These identified "social networks" can be sold as unique audiences for reaching socially relevant groups without relying on traditional social websites (such as Facebook) to provide the data. The added value of the groups created by the system analysis is that these are real-life face-to-face social groups, rather than just potentially virtual online groups.

[0145] Grouping or device linking arranges mobile devices into a social graph, where connections are inferred by the commonality of locations visited roughly simultaneously. The number of times two devices are seen at the same location at the same time represents a stronger or more likely actual social connection. The social graph is used to expand the mobile device audience, which relies on the assumption that the social networks of mobile device users are generally interested in the same products.

[0146] Multiple embodiments can use multiple methods to identify social network groups: 1) for a specific input location or location / date / time, or 2) autonomous multi-location based on groups. Each type of group has different benefits for advertisers. Location-based groups tend to be larger groups that identify macro audiences, such as audiences showing interest in a specific type of sports event, entertainment, or retail category type. Groups can be identified based on the characteristics of the locations or points of interest where users are found together. For example, devices found together on a series of bike paths may be identified as cyclists. The characteristics of a user as a person can be stored in the nodes or edges of the graph - that is, associated with the device, or the person themselves, or the link that connects many devices or people together. Multi-location groups are smaller groups that exhibit more common interest characteristics, thus providing a more focused audience.

[0147] According to some embodiments, the process of identifying social network groups from mobile device location or event data sets can include the following steps:

[0148] 1) Process the data as described in "Function 1" of the above "Data Operation Process" and make the following modifications. Instead of grouping the data by device before executing the clustering algorithm, the data source can be grouped by discrete dates and time periods. For example, from 12:00 pm to 12:15 pm on October 5th, and then run through the clustering algorithm. This generates clusters based on location, with multiple devices in each cluster. This is done for multiple dates / time periods.

[0149] 2) Use an algorithm to compare the devices present in a cluster for one date / time period with the devices present in clusters for other dates / time periods, and identify which devices appear together in many different clusters across different dates / time periods.

[0150] 3) Use an algorithm to score the quality of the possible associations between the devices identified in 2) above.

[0151] 4) Create a database to identify "social groups" of devices, with each group having a unique identifier.

[0152] 5) The system creates a list of devices containing location records and assigns a unique group ID for future reference.

[0153] Due to the amount of data that must be processed, the system's autonomous identification of social network groups involves more. According to one or more embodiments, the steps for autonomously creating social network groups may include:

[0154] 1) The system sorts and segments all location records in the system by date and time blocks within each date. The time blocks can be specified in N - minute increments. For example, 15 - minute (N = 15) time blocks will group all records for a specific date into different groups, with times throughout the 24 - hour period being 00:00 to 00:14, 00:15 to 00:29, 00:30 to 00:44, etc.

[0155] 2) The location coordinates within each time block are grouped using the same type of clustering algorithm described in Function 1 above. The generated groups are divided by location and include all devices, and this will result in creating multiple groups for each time block. These groups are given temporary group identifiers, e.g., T1G1, for time block 1, group 1.

[0156] 3) Then the system can create a table where the rows represent individual device IDs and the columns represent group identifiers. If a device is present in a group, the corresponding cell can be marked with a denoter (1, true, etc.). If a device is not present in a group, the cell may be empty.

[0157] 4) Then the system can analyze by comparing one device with all the subsequent devices one by one line by line. If another device has at least Z overlapping position groups (where both devices have a "1" in the position group), where Z is input by the operator and is variable, then these two devices are put into a new table with the social group ID (SG0, SG1, SG2, etc.) as the keyword, having a list of devices associated with each social group. Each time a device is added to a new social group, the counter in the device list is updated.

[0158] 5) The system repeats the process for the next device, but only compares it with subsequent devices and not with those previously analyzed.

[0159] 6) Once all the devices have been analyzed, there will be a large table of social groups identified by the system. A single device can be in zero, one, or multiple of the identified social groups.

[0160] 7) The counter in the device list can be used to identify and rank based on the reach of social influencers (from most groups to least groups).

[0161] 8) The social group table can also be processed into a relational graph format to identify the relationships between groups.

[0162] Figure 6 A graphical structure 600 corresponding to the social link 610 in the social network is shown. The constructed graph will have nodes 620 corresponding to the device ID (MAID), with edges (connections) representing the relationships 610. Attached to the nodes 620 is the metadata of the mobile advertising ID (MAID) value, and attached to the edges 610 is metadata including, for example, count, fine S2 hash list, timestamp list.

[0163] The figure includes three nodes 620. The node 620A with the metadata "MAID: a12…" is connected to two nodes with the metadata "MAID: b34…" 620B and "MAID: c45…" 602C. The edges themselves have metadata. The edges are symmetric. Queries for the graph can filter the metadata of the nodes 620 and the edges 610.

[0164] The social graph is used to reach a larger audience. A person can use it both backwards and forwards. Here are some example scenarios: Build an audience for the device seen at the car dealership. The social graph can be used in multiple ways to expand the initial audience. We might be able to do this if we: Add the first-level connections seen with the initial device five or more times; Add the first-level connections seen with the initial device only during off-peak hours; First- and second-level (friends of friends) connections. Build an audience of people who visit places related to cars that indicate a higher level of car knowledge, such as race tracks, auto supply stores, Cars and Coffee meetups, etc. Then we can expand that audience. One modification is to expand only to the social connections of those who have recently visited the car dealership, regardless of whether they used the initial device to visit the dealership. In this way, the system can improve the social network by connecting those who want to buy a car with people in their social network who know about cars.

[0165] The system can also enhance the social network by overlaying data from a link database to provide a representation of the social groups and further segmenting them by these criteria to create subgroups. This process can be repeated with different time periods and / or new or modified data to improve the results, identify changes, and increase the confidence level in the quality of the identified social groups.

[0166] Figure 7 is a flowchart showing an embodiment of a method for generating a location-based social network. At step 710, the system collects observation data on a mobile device. The data includes longitude and latitude locations as well as device ID and timestamp. The relevant tuple can be represented as: Mobile Ad ID (MAID), latitude / longitude, timestamp. In some embodiments, the data collected also includes metadata about the point of interest at the identified longitude / latitude, i.e., the location is identified as a residential location (further divided into apartment buildings or townhouses / detached houses), a commercial location with a specific focus (e.g., comic book store), a public place (e.g., park), or a public use (e.g., on a street / sidewalk). In some embodiments, the data collected is subject to geographical and / or time constraints. The relevant output can be split into many output files in columnar format (e.g., CSV).

[0167] The system uses the MapReduce method to process data, where the final output is in a format suitable for ingestion into a graph database. In some embodiments, the method utilizes a single mapper step and two reducer steps, and an optional third reducer step. In step 720 (mapper), the system reads the observation data and based on each record. In some embodiments, the mapper step includes rounding the timestamp down to the nearest hour (up or down). Two devices at the same location are unlikely to report their positions at exactly the same time, so some rounding helps to generate social links between the devices.

[0168] The mapper further calculates the coarse-level and fine-level location hashes (e.g., S2 geometric hashes). Examples of fine and coarse levels include levels 12 and 20 respectively. The level 12 buckets are approximately 2 kilometers per side, while the level 20 buckets are approximately 10 meters per side. The specific levels are a parameter that can be changed. The coarse level is adjusted so that the subsequent calculation steps are easy to handle. Buckets that are too fine will result in an unmanageable number of reduction tasks, while buckets that are too coarse will result in errors such as work imbalance or insufficient memory. The fine buckets are adjusted to be small enough so that devices in the same bucket are likely to be meaningfully close together, but are too fine to eliminate all meetings between devices (e.g., buckets with a side length of one centimeter have few meetings between devices).

[0169] In some embodiments, the Euclidean distance between each pair of devices is used instead of location buckets. Pairs of devices that fall within a given threshold proceed to the subsequent steps. To improve the computational complexity, a combination of location buckets can be used to filter the devices before performing the Euclidean distance processing.

[0170] The mapper emits the observations (MAID, latitude / longitude) on a composite key of (coarse S2 bucket, timestamp). The key is a string with a separator between each part of the key (e.g., "SSSSSSSSSSSS_YYYY-MM-DD-HH"), where S is the S2 hash value, Y is the year, M is the month, D is the day, and H is the hour.

[0171] In step 730 (the first reducer), the method processes the observations of the combined keywords of step 720. The method operates on the observations of all matching keywords from the mappers. Specifically, observations with matching fine-grained geographic buckets and timestamp values are grouped together. To obtain matching observations within the fine-grained buckets, the system first performs a reduction based on the coarse-grained buckets. The fine-grained S2 buckets tesselate the coarser buckets above them. Since the finer buckets tesselate the coarser buckets and the method performs the reduction on the coarse-grained buckets, there is no overlap between the reducers on the fine-grained buckets.

[0172] In some embodiments, groups of fine-grained buckets with more than a certain number of devices are filtered out. Reasons for removing crowded groups of fine-grained buckets include reducing computational complexity and machine inference regarding social connections. The next steps involve 0(N 2 ) computational complexity calculations, which become cumbersome for very large groups. Secondly, locations / times with a large number of devices are less informative for constructing social networks. The significance of two devices being at the same major sports event (e.g., a Bronco game) is less than the significance of them being the only devices at a particular location / time (e.g., a quiet neighborhood park).

[0173] For each remaining fine-grained bucket with a group, the method constructs pairwise relationships between all the devices in the group (this is the 0(N 2 ) step mentioned above). The pairwise relationships use tuples (device_A, device_B) with additional data (fine S2 hash, rounded timestamp) as keywords. In some embodiments, the pairwise relationships are symmetric, so no additional mirror records, such as (device B, device A), are required.

[0174] In step 740 (the second reducer), the method processes the device relationships. For each device value, the second reducer receives a list of (device_A, device_B, fine S2 hash, rounded timestamp) values and collates and maps these values. That is, collating the pairings generates a count of device_A and device_B being together. An example output is a list of fine S2 hashes and a list of YYYY-MM-DD-HH timestamps of when the two devices were observed together.

[0175] Given a list (including counts) of pairings of each Device_A and Device_B, a second reducer applies a count filter to remove device pairs with too few meetings (e.g., remove all device pairs with fewer than 5 events). The count filter can also stratify the pairings. For example, five or more events might be in a first tier, 10 or more events in a second tier, 15 or more events in a third tier, and so on. Higher tiers represent stronger social links. The list and counts above are used to generate metadata attached to the graph relationships.

[0176] In step 750, the method can further classify social links between devices based on metadata included with corresponding location observations and time periods. For example, observations that occur only on weekdays might indicate that the respective owners of the two devices are co-workers. If many meetings are observed over a long period of time and in a wide variety of location types, this might indicate that the respective owners are in a romantic relationship. In cases where meetings are observed only at entertainment venues, the users are likely friends. Each classification is developed as a confidence score. The classification relationships are searchable attributes in an associated database search engine. In some embodiments, the classification relationships are filtered by obtaining a pre-specified confidence score.

[0177] In particular, the advantages of the graph database allow for queries that can efficiently return all devices associated with a given starting device: "Given Device_A, return all devices associated with it." By saving (fine S2 hash, rounded timestamp) values as a list, the associated locations and times can be further filtered. For example, the following questions can be posed: "Given Device_A, return all devices that Device_A appears with more than 5 times" or "Given Device_A, return all connected devices seen at this location between these times of day."

[0178] The graph database allows one to traverse the network to any depth. This is how to find "friends of friends": "Given Device_A, and all devices connected to Device_A, return all devices connected to Device_A and all devices connected to all of its connections." The query can select any degree of interest to the searcher. For example, "Given Device_A, return all devices within 4 degrees of Device_A." The results will include all links to Device_A, all links to those devices, and all links to those subsequent devices two degrees further out. Any of the above searches can be combined and filtered in various forms.

[0179] The graphical social network can also query for users found at each of multiple locations. If nodes in the graph exist both as locations and as users / devices, location nodes cannot be directly connected to each other. However, user nodes can act as a path between two or more location nodes. An administrator can query for the path between any two location nodes. An example query would include "Given location A and location B, return all devices that have been to both places under condition _X". This example query returns a list of devices, from which further queries can identify the social network of those devices. The premise is that if a certain ideal type of person visits two specific locations, then their friends are likely to be the same type of person.

[0180] There are multiple ways to construct the social network graph: In some embodiments, the relationship data is represented in time-divided chunks. For example, August 2019 and September 2019 are separate tables. This can remove old data. However, the main drawback of time-chunked data is that it will be more difficult to calculate and filter the total number of meetings between two devices across all time.

[0181] In some embodiments, the social network graph is constructed incrementally (micro-chunks). Micro-chunks are short time spans (e.g., hourly or daily). The results are incrementally added to the database, which means that if two devices are already linked in the database, this operation appends a new meeting between them, otherwise a new relationship is stored. The advantage is that the system can more easily query / filter the entire history between two devices. The drawback is that the computational cost of iterating over the entire dataset is higher (for creation and deletion).

[0182] Function 6. Deliver data to the application

[0183] Once the mobile device has been linked to households and individuals within multiple databases, these individuals can be delivered to consumer applications for various commercial, public safety, and other uses. In this case, the consumer specifies any mobile, web-based, or other type of application that uses the data to provide services based on that data. The first implementation supports a mobile advertising network in determining the target of an advertisement by delivering interest data to the mobile advertising network, but can be used for any application based on using mobile device or location information.

[0184] The service can provide real-time or historical information from the database to consumer applications. These applications can receive data from the system as a file transfer or as a web-based synchronous or asynchronous service based on JSON or other similar protocols. The two main modes of providing data to consumer applications are: 1) device-specific requests, and 2) location requests.

[0185] Device-specific requests are designed to return home or personal information associated with a particular device. For this service, the consumer application passes a properly encrypted or obfuscated mobile device ID to the system, and the service returns a set of anonymized data associated with that device ID.

[0186] Location requests can take two forms, but in each form, the consumer application passes in a location, typically in latitude / longitude format, for which it is requesting information from the system. The first type of location request generates a combined response for all mobile devices within a specific radius of that location. The second generates a per-person level response for all devices within a certain radius of that location. For both types of requests, the system uses real-time mobile event data to identify mobile device IDs near the requested location.

[0187] The combined response request constructs a summary view of all devices. This is typically used for marketing-type services that are looking for characteristics of the group. In this response, the system combines the data for each data field to be returned and provides a weighted percentage of the values in each data field. For example, if one of the data fields is "male" and 10 devices are identified near that location, 3 of which are linked to data that marks that field as "yes", the system will return a response to the consumer application telling it how many devices there are in total and that "male" is 30%.

[0188] The per-person response request can construct an array of all data for a per-person device and pass it back to the consumer application. This allows the consumer application to view each person's data separately. Note that the system may or may not return the encoded device ID as part of this service.

[0189] Target data for partners

[0190] The system does not provide advertising services. To make data available for use in online advertising and deliver targeted offers to consumers, the system shares aggregated buyer audience data (such as furniture buyers) with selected advertising services, publishers, or advertising network partners, as described below. There are 4 ways to do this.

[0191] Option 1: Supply audience-level data at the advertising network via PII matching

[0192] The system provides the data to an independent data processor, as a third-party partner, to perform a PII-based database match with other Network Advertising Initiative (NAI) members. Typically, some or all of the following fields are used for the match - mobile number, device ID, MAC address, name, address.

[0193] The process for matching data according to some embodiments is summarized in the following steps, and inFigure 4 is shown as follows:

[0194] · The system creates a data file containing name, address, phone number, UDID, or MAC address, or other identifiers for matching the audience and transmits it to the data processor via a secure channel.

[0195] · The system also provides buyer audience attributes (e.g., furniture buyers) in the data file, which will ultimately be used by the partners of E2M to determine the target.

[0196] · The system file is sent to the data processor and compared with the partner file to identify the matching records in the output.

[0197] · The output file called the system match set is constructed to include the record identifier (ANONYMOUS-ID) of the partner and the target attributes of the system.

[0198] · The output file from the data processor to the partner does not contain any PII.

[0199] During the matching process, the independent data processor attaches the system buyer_audience level information to the partner file where there is a PII match. After the matching occurs, all non-matching information can be discarded.

[0200] Matching output: The system match set is transmitted from the data processor to the partner's data storage, where it will be provided for digital advertising.

[0201] Partner determination process:

[0202] · The data processor transmits the output of the matching process - the system match set - to the partner via a secure channel. Then, the partner performs the following steps to prepare the data for determination:

[0203] ο Normalize the system buyer audience data and store the data in their database;

[0204] ο Anonymize the user profile:

[0205] ο Supply the system determination target data for the online advertising delivery system; and

[0206] ο Start the campaign delivery

[0207] Partner anonymization of the user profile:

[0208] Partner advertising delivery is based on the anonymous ID rather than on PII, such as UDID or any ID associated with PII. To be able to use the above match set on the partner network for the purpose of determination, a forward hashing technique emerges to convert the PII-ID into an ANONYMOUS-ID.

[0209] Note:

[0210] Data with ANONYMOUS-ID and PII-ID as keywords is stored in different operating environments and is not co-located according to policy.

[0211] There is no lookup table that correlates ANONYMOUS-ID and PII-ID.

[0212] The conversion from PII-ID to ANONYMOUS-ID is one-way.

[0213] These anonymized profiles are then moved to the user profile store to be made available for ad delivery.

[0214] Partners supply ad delivery services

[0215] As previously mentioned, each user active on the partner network can have at least one partner ANONYMOUS-ID associated with them. The partner ad delivery system can deliver ads based on this identifier ANONYMOUS-ID. Whenever a user is on the partner network, an ad delivery request from a browser request will be associated with the user ANONYMOUS-ID. The browser request can be completed by the partner.

[0216] When the ad delivery system sees a user with a defined set of system attributes 1 specified for that particular campaign, it delivers ads using system data.

[0217] Option 2: Supply audience-level data to the ad server and ad network in real time

[0218] The system can be integrated with partner ad servers and ad networks such that when a request is made to Get_Offer (i.e., display an ad) within their ad serving platform, the ad serving platform will make a request to the system target data engine. During the invocation of the system's recommendation engine, the ad server provides the system with a mobile device identifier, such as a hashed UDID or location. The system can then return audience data related to that device or location. The ad server will then use the audience data provided by the system to select the ad to display. As Figure 4 shown.

[0219] According to some embodiments, the format of the get_audience request can include:

[0220] PID: Partner ID assigned by the system to identify the request source.

[0221] RT: Location (1) or device (0). Defaults to device.

[0222] DID: Identifier, which is the mobile number hashed by SHA-1, device ID (UDID, IMEI, MEID, ESN), MAC address, or cookie ID, and E2M will use it to obtain audience data for device requests. If this is a location request, this field should be used as the partner-generated tracking ID for the request / response.

[0223] LLAT: Latitude of the location collected from the device for a device request (if available) or the latitude of the location of the requested aggregated audience.

[0224] LLON: Longitude of the location collected from the device for a device request (if available) or the longitude of the location of the requested aggregated audience.

[0225] The request tag is a fully qualified URL with a set of query parameters:

[0226] URL syntax:

[0227] http: / / on.spot.extendtomobile.com / onspot.js?PID=<Partner ID>&RT= <value>&DID=<Hashed_ID_VALUE>&LLAT= <latitude>&LLON= <longitude>

[0228] The Audience_Data response tag will have different formats for device and location requests. A response of either type can be one of the following 3 types: script, image, or i-frame. Each partner will provide the system with the format / syntax required for its response tag.

[0229] Device request response. The device request response will return only the determined target information for the hashed device ID sent in the request, along with the audience category to which the device belongs. An example of a response is:

[0230] http: / / www.ThePartner.com?DID=<Hashed_ID_Value>&id=D045&id=CO01&id=C004

[0231] The above response returns three audience segments for the requested device ID, and the ad network can now select ads based on this.

[0232] Location request response. The location request response can return the determined target data used to aggregate the audience at a specific location. For example, if the system finds 100 people near the location coordinates passed in the request, it will identify that there are 10 people in audience D045, 1 person in C001, and 25 people in C004. The response will look like:

[0233] http: / / www.ThePartner.com?DID=<Partner_Tracking_ID>&tot=100&id=C004&cnt=25&id=D045&cnt=10&id=C001&cnt=1

[0234] This provides the partner with the total audience size and the audience size by category, so they can decide on quantity and quality for their ad decisions.

[0235] Specific items of the response tag can be customized in the following ways according to various embodiments:

[0236] Delimiter: The partner can indicate a single character used to separate segments between elements. The most common is "&".

[0237] Suffix: The partner can include additional static information appended to the response tag, which can be additional name / value elements.

[0238] Type: The partner can specify a script, image, or i-frame tag.

[0239] Option 3: Automatically supply audience-level data to the ad server and ad network

[0240] The system can be integrated with our partner ad servers and ad networks such that we send them the determined target data for each known audience member in the system database. This can be transmitted periodically using the same type of response format as in Option 2 or using secure FTP as the file transfer.

[0241] Custom Audiences: Reducing Ad Server Processing

[0242] The previous discussion focused on sending system standard audiences to partners. The system can also build and supply custom audiences for partners, e.g., if an advertiser wants to show their ads to Hispanic furniture buyers with an income between $100,000 and $150,000. These characteristics correspond to the system's standard audiences D047 (Hispanic), D104 (Income 100 - 150), and C001 (Furniture). The system can run an offline process to build a custom audience - P1001, which has analyzed all these characteristics - so that when the system reports to the ad server, in its response the ad server only has to look at P1001 to see if it should display the advertiser's ad, rather than trying to cross-check all the conditions in real time, especially if there are a large number of selection conditions.

[0243] For this, the ad network must notify the system of the ad campaign in advance and provide the advertiser's conditions so that the system can supply the audience. The goal for the supply time is < 1 business day after receiving the partner request.

[0244] Feature 7. Interactive Tools for Querying the Data Mart

[0245] To provide additional value to customers, many interactive reporting tools can be made available via the website, mobile device, computer, or other platforms. These reporting tools include, but are not limited to:

[0246] 1. Audience Counting Tool: The system can provide a real-time interface where users can select conditions from the available data in the database and obtain a real-time count of the number of devices that match the conditions in the database. In addition to other potential uses of such count data, this basic information enables the sales team or advertiser to interactively estimate the audience size of an ad campaign. By augmenting the basic count data with other data (e.g., the number of ad requests a device makes on a specific ad network per day), a more comprehensive model of the number of ad impressions that may occur on a specific ad network can be built and the effectiveness and reach of different ad networks can be compared.

[0247] 2. Location Device Count and Profiles: A user can input a location (e.g., a street address or latitude / longitude) and obtain a report of the number of devices seen at that location, or how many devices are currently at that location in real time. The user can select criteria to obtain reports that break down information by different dates / days / time periods and create statistical profile reports based on the information stored in the system data mart.

[0248] 3. Location-Based Audiences: The system can provide an interface for the user to input a location or set of locations and tag them with a set of data characteristics, which can be used to query the data mart to identify devices with specific criteria. For example, a user might input a set of locations and identify them with the following data characteristics: "jewelry store", "high-end", or "shopping mall". This data can come from a points of interest database, a government database (e.g., a chamber of commerce database, a retailer database, or any other commercial or private database), or can be entered manually.

[0249] Once the new data characteristics are stored in the system, the user can enter a query to "find all devices that visited a high-end jewelry store in the last 14 days". The system will be able to identify all devices that have been at these locations and build a profile report on the personal / family characteristics associated with these devices. Additionally, the system can take the results and build a list of devices that can be targeted to an "in-market" audience.

[0250] Note that these types of audiences can be built in real time by setting trap queries so that every time the system receives and processes mobile device location data, any device that matches one of the locations in the trap query is automatically added to the audience. These audiences can then be provided to the user via the methods in function 6 above.

[0251] 4. Location-Based Profiles: Reports can be generated for retailers or other individuals seeking information about people who visit or are near a physical location. For example, a retailer might want to know who passes by their store each day, whether they come in or not. In addition to time periods (days / dates / times), the system can provide an interface to input a street location or latitude / longitude and provide a profile report based on the devices that meet this criteria. This information can be used to build a list of devices for a mobile advertising campaign or to perform analysis on the origin and movement behavior of the devices.

[0252] Industrial applicability

[0253] Data from multiple mobile event data sources results in the rapid construction of very large sets of mobile device IDs that can be linked back to a vast number of data sources. While primarily applicable to smart phones and tablets, which are the large majority of consumers of today's mobile data services, it will eventually cover the entire population of mobile devices as consumers adopt these devices in the coming years.

[0254] By providing information about individuals associated with mobile devices, the system can build many different solutions, including but not limited to:

[0255] · Smart solutions - These solutions provide access to data, enabling applications and services to customize service delivery or the user experience based on the provided data. This could be a financial application that offers different financial solutions to potential customers based on age, income, and investment information, or a mobile advertising network that delivers different ads based on personal shopping interests or brand preferences.

[0256] · Analytical solutions - These solutions provide a comprehensive view of groups at different times in a given area. Think of a retailer planning a new store location who wants to know the people coming to a specific shopping mall or street, or a city planner who wants to understand commuting patterns in a specific area by looking at different times of the day.

[0257] · Situational awareness solutions - These solutions provide real-time views and information for public safety, homeland security, emergency responders, etc. Examples include being able to identify the likely number of people at an event location, and information such as age, health status, criminal background, etc.

[0258] These are just a small part of the applications, as each business and government agency has a large amount of data they use today and wants to associate with mobile devices and users to expand their public services.

[0259] 1. The system can provide the identification of a mobile device to an individual or family, which can be used to match back to any database that uses an address as a key element to identify data.

[0260] 2. The system can provide the identification of a mobile device, where the system can be used with any type of mobile device identifier, such as UDID, Wi-Fi MAC address, Bluetooth ID, browser cache files (cookies), or any other persistent or semi-persistent identifier. A semi-persistent identifier is an identifier that exists for a period of time before being changed, which can be a day, a week, a month, or longer.

[0261] 3. The system can provide the identification of a mobile device, where the system can be used with any type of service plan, including subscription, corporate, prepaid, etc., with any type of mobile device on a cellular or Wi-Fi network.

[0262] 4. The system can provide the identification of a mobile device by cross-matching multiple mobile device identifiers with a single anonymous identifier.

[0263] 5. The system can provide the identification of mobile devices and anonymized data, so as to protect privacy when the data is used for commercial purposes.

[0264] 6. The system can provide the identification of mobile devices, which can be used together with any mobile device data including the following elements: 1) mobile device identifier, and 2) geographical location tag. The time / date stamp associated with the mobile device data is desired and may or may not be required to link the device to the database, but is needed for some applications and analysis to deliver different services.

[0265] 7. The system can provide the identification of mobile devices, which works with any mobile device location data and takes into account the variations in the accuracy of the mobile location data according to the data source.

[0266] 8. The system can provide the identification of mobile devices, which can obtain real-time data as well as batch data.

[0267] 9. The system can provide the identification of mobile devices, where the system delivers linked data to commercial services, merchants, governments, and other customers in two ways: 1) in response to a query about a single device, or 2) in response to a query about a location.

[0268] 10. The system can provide the identification of mobile devices, which does not require any subscriber data from the mobile operator to link the device back to any database.

[0269] 11. The system can provide the identification of mobile devices, which does not require any location data from the mobile operator.

[0270] 12. The system can provide the identification of mobile devices, which can identify a "social network" of devices with common interests based on location data and can be linked back to a commercial database for analysis purposes.

[0271] 13. The system can provide the identification of mobile devices, which can identify a "social network" based on a single selected location input into the system or based on multiple locations autonomously generated by system analysis.

[0272] Function 8. Detection of home relocation

[0273] Function 8 detects when a user has changed their residence based on the behavior of the user's respective mobile device. People who relocate their residences usually have many commonalities that are useful for data science; therefore, the system includes the function of building an audience based on the relocation date and / or relocation location.

[0274] Relocation detection is built on top of the Home-Household Matching Method (HHMM). In some embodiments, relocation detection matches devices monthly to detect monthly changes. Every day, a list of devices seen on that day is generated during data ingestion. HHMM reads from this list. HHMM determines the address for the month and compares it to the address from the previous month. If the monthly address for a given device is a new address that is different from the home associated with the device within any two months of a three-month span, the user is identified as having relocated.

[0275] Figure 8 FIG. is a flow chart showing a method for detecting relocation. For each device being analyzed, at step 810, relocation detection reads all observations for the device from the database. In some embodiments, the observations span up to 12+ months of past observations, but less than 13 months. Relocation detection is performed periodically on relevant devices. At step 820, a filter and cleaning step are applied to the observations. The filter removes duplicate observations by latitude / longitude and observations that may have been obtained during transit (on the road). At step 830, relocation detection identifies any previous address change records. At step 840, relocation detection identifies the last month analyzed in the address change records and uses that month as the starting month to update the analysis.

[0276] At step 850, HHMM is applied to the observations within each given month. First, the observation data is split by month. People who relocate, especially renters, typically move at the end / beginning of the month. For each month including the starting month and months after the starting month, relocation detection applies HHMM and finds the best match (if any). It is possible that a month does not return a possible home match, in which case the results for that month are discarded. In some embodiments, the current month is considered before the end of the current month. If there is a best match for the month, the detection of the temporary relocation address is recorded.

[0277] A given address is identified via clustering. The filter retains clusters that: 1. Do not have too large a radius. In some embodiments, clusters larger than 100 meters are bad clusters for picking as residences. 2. Have enough observations. In some embodiments, more than 200 observations in the cluster is sufficient. 3. Are close to a time-space cluster. 4. Have a good ratio of weekday observations to weekend observations. If a cluster mainly has weekday observations, then it is less likely that someone lives there and more likely that they work there.

[0278] The clusters are further scored based on: 1. What fraction of all observations are in the cluster? The larger the fraction, the better. 2. Use the weekday / weekend ratio. Lower values (more weekend time than weekday in the cluster) give a higher score.

[0279] For each cluster, HHMM determines a list of nearby residential addresses. The residential matches are scored based on how close the residence is to the cluster and a comparison to the property lines. If the observations in the cluster are closer to the residence and within the property lines, the address is scored higher. A given residence is selected as the monthly address based on the cluster and residential match that gives the best combined score. In some embodiments, a threshold score is required to match to an address for the month.

[0280] In step 860, movement detection identifies new addresses. The previous and newly created address change histories are analyzed to find new addresses and remove duplicates. In some embodiments, an address change occurs when the device matches a new address in two out of three months. At the same time, the date on which a given device needs to be analyzed next is calculated. Devices with fewer observations can be allowed to be analyzed more frequently, while devices with more observations need to be analyzed less frequently. In some embodiments, all devices are analyzed at least once every 30 days for movement detection.

[0281] In some embodiments, the address change records are stored in a database along with a set of data that belongs to categories that can be queried by the database search engine. These records allow queries to be filtered by the movement date and where the device moved from / to. The data categories include: i. device identifier, ii. movement date, iii. previous postal code, iv. new postal code, v. previous address, and vi. new address. The date on which a given device needs to be re-analyzed is also stored in the database.

[0282] Example queries include:

[0283] Find all devices that moved into postal codes (1, 2, 3) in June 2019.

[0284] Find all devices that left postal codes (1, 2, 3) in June 2019.

[0285] Find all devices that moved from postal codes (1, 2, 3) to postal codes (8, 9, 10) between January 2019 and June 2019.

[0286] Find the postal codes with the most in / out movement in June 2019.

[0287] Figure 9 A table showing examples of movement detection. This table shows two address changes. The first change was to address "A" in January 2019 (based on January to March), and the second change was from "A" to "D" in June 2019 (based on June to August). Matches with addresses B and C were discarded because the device was not matched enough times, or the matches were not close enough within two months to meet the two-out-of-three rule. The movement in June 2019 could not be determined until some time in August 2019.

[0288] In some embodiments, there is no fixed time as to when movement detection can identify a movement. When there is "enough" data to make a decision, movement detection assigns the device to a residential address. "Enough" means that the device has enough observed result data so that HHMM can assign the device to a residential location, and this assignment is better than any other alternative it can make. In some embodiments, "enough" is several hundred observations, and the amount of time it takes for the device to produce that many observations depends largely on the device and the applications on that device. Some devices may take an entire month to create that much data, while other devices may complete it in a day or two.

[0289] Theoretically, an address change can be detected in two months and one day. The past two months and one day of the third month. One of the first two months matches the "third month". Once enough observations have been collected at a given residence, the monthly address for the third month can be identified. Although it is unlikely to collect enough observations on the first day of the month, it is theoretically possible. In some embodiments, there is a lower limit on the number of days in a given month for calculating the monthly address.

[0290] Exemplary Computer System Overview

[0291] Embodiments of the present technology include the various steps and operations described above. Many of these steps and operations can be performed by hardware components, or can be embodied in machine-executable instructions that can be used to cause a general or special-purpose processor programmed with the instructions to perform these steps. Alternatively, these steps can be performed by a combination of hardware, software, and / or firmware. Thus, Figure 10 is an example of a computer system 1000 that can utilize embodiments of the present technology. Computer system 1000 is an example of a device for implementing functions and performing several operations described above. According to this example, the computer system includes a bus 1010, at least one processor 1020, at least one communication port 1030, a main memory 1040, a removable storage medium 1050, a read-only memory 1060, and a mass storage 1070.

[0292] Processor 1020 can be any known processor, such as but not limited to Series processors; Series processors; or Series processors. The communication port 1030 can be any one of an RS-232 port for use with a modem-based dial-up connection, a 60 / 100 Ethernet port, or a gigabit port using copper or fiber optic cables. The communication port 1030 can be selected based on a network such as, for example, a local area network (LAN), a wide area network (WAN), or any network to which the computer system 1000 is connected.

[0293] The main memory 1040 can be a random access memory (RAM) or any other dynamic storage device known in the art. The read-only memory 1060 can be any static storage device, such as a programmable read-only memory (PROM) chip for storing static information (such as instructions for the processor 1020).

[0294] The mass storage 1070 can be used to store information and instructions. For example, a hard disk of the SCSI drive series, an optical disk, a disk array (such as the Adaptec series of RAID drives), or any other mass storage device can be used.

[0295] The bus 1010 communicatively couples the processor 1020 with other memory, storage, and communication blocks. Depending on the storage device used, the bus 1010 can be a PCI / PCI-X or SCSI-based system bus.

[0296] The removable storage medium 1050 can be any type of external hard disk drive, floppy disk drive, solid state storage drive, cloud storage system, Zip drive, compact disc read-only memory (CD-ROM), rewritable compact disc (CD-RW), and / or digital video disc read-only memory (DVD-ROM).

[0297] The above components are meant to illustrate some types of possibilities. The above examples should in no way limit the scope of the present technology as they are only exemplary embodiments.

[0298] Embodiments of the present technology may be implemented using a combination of one or more modules or engines. For example, an embodiment provides a graphical user interface generation module that generates one or more graphical user interface screens to convey results / information and obtain instructions, a general or specialized "communication module" for interfacing with a variety of components and databases, a "data collection module" for collecting information from a variety of sources, an "anonymization module" for anonymizing data, a "rating module" for evaluating the quality of residential matches, a "linking module" for linking addresses to mobile devices, a "social graph module" for grouping devices based on one or more spatial and temporal analyses, a "reporting module" for generating device and location reports, and other modules and engines for providing the various functions required by embodiments of the present technology. Still, various embodiments may combine two or more of these modules into a single module and / or associate a portion of the functionality of one or more of these modules with different modules. Each of these modules and engines provides an example of a means for implementing the functions described herein and performing the operations described herein.

[0299] Various modifications and additions may be made to the embodiments discussed without departing from the scope of the present technology. For example, while the above embodiments relate to specific features, the scope of the present technology also includes embodiments having different combinations of features, as well as embodiments that do not include all of the described features. Accordingly, the scope of the present technology is intended to cover all such alternatives, modifications, and variations, and all equivalents thereof.< / longitude> < / latitude> < / value>

Claims

1. A method for determining that a user has moved based on the location of a mobile device, comprising: Initializing a first home address of a user of the mobile device; Periodically identifying a monthly address of the user of the mobile device based on location data generated by the mobile device in respective months; And In response to identifying the monthly address as a second home address in two of a three - month consecutive period, updating the physical address of the user from the first home address to the second home address; And Applying a timestamp to the updated physical address based on the first month of the three consecutive months that the mobile device resides at the new address.

2. The method according to claim 1, wherein The monthly address is identified as the second home address during the first and third months of a three - month consecutive period.

3. The method according to claim 1, wherein The monthly address is identified as the second home address during the second and third months of the three - month consecutive period.

4. The method according to claim 1, wherein, The periodically identifying the monthly address of the user of the mobile device further comprises: Receiving a plurality of location data from the mobile device throughout the month; Organizing the plurality of location data into a plurality of clusters corresponding to geographical regions visited by the mobile device during the month; and Calculating a score of the mobile device for each cluster, the score representing the likelihood that the user of the mobile device resides at a given address within the cluster during the month, wherein the monthly address corresponds to the cluster with the highest score.

5. The method according to claim 4, wherein The calculating the score of the mobile device for each cluster further comprises: Evaluating each cluster based on any combination of the following: A set of timestamps of the mobile device detected in each cluster; Location mapping metadata of the each cluster; and An instance frequency of the mobile device detected in each cluster.

6. The method according to claim 5, wherein, The physical address also corresponds to a cluster having at least a threshold score.

7. The method according to claim 6, wherein, The calculating the score of the mobile device for each cluster occurs each time new location data in the plurality of location data is received and before the end of the monthly cycle when the monthly address corresponds to a given cluster.

8. The method according to claim 6, wherein, The calculating the score of the mobile device for each cluster occurs at a frequency inversely proportional to the frequency of receiving location data of the mobile device.

9. A method for determining that a user has moved based on the location of a mobile device, comprising: Initializing a first home address of a user of the mobile device; Periodically identifying a monthly address of the user of the mobile device based on location data generated by the mobile device in respective months; Monitoring the home addresses of a plurality of mobile devices based on location data collected on respective mobile devices of the plurality of mobile devices; Updating the home address of each mobile device in the plurality of mobile devices in a database based on the detection that a given mobile device has resided at a new address for two of three consecutive months; And Applying a timestamp to the update of each home address of the plurality of mobile devices based on the first month of the three consecutive months that the given mobile device resides at the new address.

10. The method according to claim 9, further comprising: Receiving a search query through a search engine for a mobile device among the plurality of mobile devices whose home address has been updated during a first time period; And Return the device identifiers of all mobile devices among the multiple mobile devices that have updated their home addresses within the first time period based on the time stamp.

11. The method according to claim 9, further comprising: Receiving, via a search engine, a search query for mobile devices among the multiple mobile devices that have updated their home addresses to a first postal code within the first time period; And Returning the device identifiers of all mobile devices among the multiple mobile devices that have updated their home addresses within the first time period based on the time stamp and within the first postal code based on the new address.

12. The method according to claim 9, further comprising: Receiving, via a search engine, a search query for a postal code that has the largest number of home addresses of the multiple mobile devices that have been updated into or out of the postal code within the first time period; And Returning a sorted list of postal codes sorted by home address updates based on the new address and within the first time period based on the time stamp.

13. A system for determining that a user has moved based on the location of a mobile device, comprising: An application software configured to initialize a physical address for a user of a mobile device during a first month, including instructions configured to cause a processor to: Receive multiple location data from the mobile device throughout the first month; Organize the multiple location data into multiple clusters, the clusters corresponding to geographical regions visited by the mobile device during the first month; And Calculate a score for the mobile device in each cluster, the score representing the likelihood that the user of the mobile device lived at the address within the cluster during the first month, wherein the physical address corresponds to the cluster having the highest score; And A memory including instructions configured to cause the processor to, during months after the first month, evaluate the location of the mobile device for the month based on a monthly basis and update the physical address to the second address as a time stamp for a second address different from the physical address for two months during a consecutive three - month period, wherein the time stamp is based on the first month within the consecutive three - month period during which the mobile device lived at the new address.

14. The system according to claim 13, wherein the instructions to calculate the score for the mobile device in each cluster further comprise: Evaluating each cluster based on any combination of the following: A set of time stamps of the mobile devices detected in each cluster; The location mapping metadata in each cluster; And The instance frequency of the mobile devices detected in each cluster.

15. The system according to claim 14, wherein, The physical address also corresponds to a cluster having at least a threshold score.

16. The system according to claim 15, wherein, The instructions to calculate the score for the mobile device in each cluster occur each time new location data in the multiple location data is received and when the location for the month corresponds to a given cluster before the end of the monthly cycle.

17. The system according to claim 15, wherein, The instructions to calculate the score for the mobile device in each cluster occur at a frequency inversely proportional to the frequency of receiving the location data of the mobile device.

18. The system according to claim 13, wherein, The location for the month is identified as the second address during the first and third months of the consecutive three - month period.

19. The system according to claim 13, wherein, The location in that month is identified as the second address during the second and third months of the three consecutive months.

Images