On-device ID resolution software development kit

Abstract

A software development kit for providing targeted messages to a client device from a remote device via an app installed on the client device operates without personal information leaving the client device. One or more bloom filters are created and mapped to a particular app bundle identifier. Matched identifiers are resolved to a set of bloom filters to target messages based on a user identifier. Processing is performed locally on the client device so no personal information leaves the client device. Real-time measurements are performed by triggering translation events to a unified mobile network providing analysis of the effectiveness of the targeted messaging without providing personal information to the remote device.

Description

[Technical field]

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 306,326, filed February 3, 2022, which is incorporated herein by reference in its entirety.

[0002] The field of the invention is software development kits (SDKs) for applications that use mapping on a client device to enable targeted messaging without transmitting personal information about a user of the device from that device. [Background technology]

[0003] Traditional targeted messaging requires that personal information (PI) from a user be sent from the user's electronic device (computer, smartphone, tablet, etc.) to a server in remote communication with this client device. This remote device may be operated by the party to whom it is desired to send targeted messages, or it may be a supply-side platform (SSP), demand-side platform (DSP) or other network that provides a service to the party to whom it is desired to send targeted messages. Often, the means by which the information is sent from the user's electronic device is an SDK, which may consist of a library bundled with a software application or "app" installed on the device. The SDK may be specific to a particular hardware and operating system combination.

[0004] Ultimately, the parties who issue and maintain the operating system of an electronic device control the ability of any app to send PI from the user's electronic device to any remote device. For example, Apple Computer issues the iOS operating system used on the company's iPhone® smartphones and iPad® tablet devices, and Microsoft® Corporation issues the Windows® operating system used on many personal computers. If these companies or other operating system providers modify their operating systems or operating system policies in a manner that restricts the ability of apps to send PI from the client device on which the operating system is installed to remote devices, apps that rely on this ability will not function properly and will not be able to deliver targeted messages to the electronic device where the user can see them. In one example, Apple's App Tracking Transparency (ATT) framework provides a notification to the user when the app is downloaded or opened, asking the user if they wish to be tracked across third-party apps and websites. SDK developers within the Apple framework must comply with the user's request recorded by the ATT framework.

[0005] A great many of the services available through the World Wide Web and the apps that interact through the Internet are given free of charge to users. Funding for providing these services and apps comes from parties who want to send these targeted messages, and therefore the business models of these services and apps depend on the ability to deliver targeted messages to users of electronic devices. Without the ability to send targeted messages, many of these services and apps that users rely on would become economically unviable due to loss of revenue and would therefore disappear. Thus, users of these electronic devices would suffer the loss of the services and apps that they currently enjoy. Similarly, messages would still appear, but they would be less targeted and therefore less interesting to users than targeted messages directed to the client device. For this same reason, these messages would be less valuable to the parties that purchased the rights to deliver the messages, and therefore the quality and quantity of such apps would decrease.

[0006] The inventors have recognized that where an operating system restricts the sending of PI from a user electronic device to a remote device, then it would be desirable to develop a system and method for providing targeted messages that do not require PI to be sent from the user electronic device to the remote device. However, to avoid the problems discussed above without sending PI from the client device, there must be some means by which message targeting can be accomplished, and it is desirable to develop an SDK to facilitate this functionality.

[0007] References mentioned in this Background section are not admitted to be prior art with respect to the present invention. Summary of the Invention [Means for solving the problem]

[0008] The present invention is directed to a system and method SDK that provides targeted messages to a user electronic device (i.e., client device) from a remote electronic device via an app installed on the client device, but operates without transmitting PI from the client device to the remote device. In certain implementations of the invention, a set of bloom filters are created from data regarding who one wishes to send targeted messages to. In certain embodiments, these may be mapped to specific app bundle identifiers for efficient, targeted download to groups of user devices. Bloom filters are very space-efficient data structures such that reasonable bandwidth and storage limitations for sending data to apps on client devices may be met. A user login / matched identifier may be resolved to a set of bloom filters for targeted messages based on the user identifier. In this way, the processing for delivering targeted messages based on matching PIs is performed on the client device, rather than on the remote device. Because the processing is performed locally on the client device, the PIs do not need to leave the client device as all matching with PIs is performed locally. In certain implementations, real-time view-through and click-through measurement can be performed by triggering conversion events into the integrated mobile network, thereby enabling analysis of the effectiveness of targeted messaging without providing PI to remote devices.

[0009] In certain implementations, an SDK user may be provided with functionality to remotely adjust configuration parameters of the SDK after the SDK is installed on a client device. This may be provided via a remote management platform (which may be referred to herein as a "console"). The remote console platform may also be used to control the selection of Bloom filters on the client device on which the SDK is installed.

[0010] Certain implementations of the invention described herein provide several advantages. First, because PI never leaves the client device, the privacy of the client device user is never compromised. Thus, because there is no PI transmitted over the communications network or stored on the remote device, the user does not need to rely on security measures maintained during communication to the remote device or worry about data leakage at the remote device. Second, the use of a highly efficient Bloom filter, rather than providing a separate set of identifiers for every possible app, as well as the use of a specific app bundle identifier, greatly limits the bandwidth and storage requirements of the present approach, making the app practical for smartphones and similar devices that operate with limited storage and bandwidth. Third, even if the transmission of PI to remote devices is no longer facilitated by the applicable operating system, these implementations of the invention provide the ability for those who wish to continue to send targeted messages and do so, thus maintaining a free service to users and the economic viability of the app.

[0011] These and other features, objects and advantages of the present invention will be better understood from a consideration of the following detailed description of the preferred embodiments taken in conjunction with the drawings described below. [Brief description of the drawings]

[0012] [Figure 1]1 is a sample screen shot of software of an embodiment of the present invention running on a device used by a party wishing to send a targeted message according to an embodiment of the present invention. [Diagram 2] FIG. 1 illustrates the operation of a Bloom filter used for matching in a device. [Diagram 3] 4 is a data flow diagram according to one implementation of the present invention. [Figure 4] FIG. 1 is a system architecture diagram according to one implementation of the present invention. [Diagram 5] FIG. 10 illustrates operations for selecting a targeted message for delivery at a client device according to one implementation of the present invention. [Figure 6] FIG. 13 illustrates an operation for performing analysis of delivery of targeted messages to client devices according to one implementation of the present invention. [Figure 7] 4 is a data flow diagram illustrating SDK initialization and configuration according to one implementation of the present invention. [Figure 8] 1 is a data flow diagram illustrating synchronization of Bloom filters according to one implementation of the present invention. [Figure 9] 4 is a data flow diagram illustrating refreshing according to one implementation of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Before describing the present invention in further detail, it is to be understood that the invention is not limited to the specific embodiments described in any section of this specification, since the scope of the present invention is limited only by the claims, and the terminology used in the description of the specific embodiments is for the purpose of merely describing those particular embodiments, and is not intended to be limiting.

[0014] Generally speaking, there are limitations on how much data can be pushed from a remote device to a single client device or to a particular app on a client device. These limitations may be enforced by the operating system or by individual apps. Thus, to minimize the data delivered to a particular app or client device, certain implementations of the present invention use a preliminary step that allows for "matchmaking" between app publishers and those wishing to provide targeted messages to users of their apps. In one instance, those wishing to deliver targeted messages may be given the option of selecting app bundles (i.e., specific app groups) that they believe will have a high degree of overlap with their desired messaging audience. This overlap may be facilitated by past exposure / attribution information. In some instances, one operating system may be used as a proxy for another, for example, data from the Android operating system used on many non-Apple smartphones may be used as a proxy for the overlap of iOS on Apple branded smartphones based on data available through that operating system. In certain implementations, a single group can be created for multiple apps from the same purchaser that reside on the same device, which opens up the possibility of shared storage of multiple apps, further reducing storage and bandwidth requirements when a particular client device has multiple apps installed. This is common since app developers often publish multiple apps that are meant to complement each other.

[0015] To facilitate this matchmaking, those wishing to deliver targeted messages may be presented with a web-based display 10 as shown in FIG. 1. This display 10 is generated from a server maintained by the DSP or other network, which may be configured via a remote management ("console") platform that controls SDK functionality parameters. It will be appreciated that the display categorizes various groups of apps based on categories 12, e.g., "Fashion & Lifestyle," "Entertainment & Art," and "News & Current Affairs." Options are presented to the viewer based on the category, along with segment and pricing information 14. The viewer (e.g., a marketer or brand owner) then makes a viewer selection via a graphical user interface on the display 10.

[0016] The essence of audience-based message targeting is to determine whether an impression is of interest to a party to whom a targeted message is to be sent, based on the available impressions. In other words, whether the user who is to receive the targeted message is a member of a set. Thus, a Bloom filter created with identifiers from interested users can be used to test identifiers from a particular user to determine the membership of the set. A Bloom filter is a data structure that allows a search to determine whether a given element is in a certain state. The downside of a Bloom filter is that it is a probabilistic data structure, therefore, while a Bloom filter can determine whether an element is indeed not in a set or may be in a set, a Bloom filter cannot determine with 100% certainty that an element is actually in a set. An example of a Bloom filter and a search for a particular name in a Bloom filter is shown in Figure 2.

[0017] As shown in FIG. 2, the basic structure of a Bloom filter is a bit vector or table 20. Each empty cell in the table 20 represents a bit and is associated with an index. To add an element to the Bloom filter, such as the filter input 22, it is hashed and bits are set to 1 in the bit vector 20 at the index of their hash. When a string is added, the bit at the index given by the hash is set to 1. To then test for membership of the filter query 24 in the bit vector, the string is hashed with the same hash function and then it is determined whether their value is set in the bit vector 20. If their bits are not set, then we can know for sure that the element 24 is not in the set. However, if their bits are set, then we can only know that the element 24 might be in the set because another element may have set the same bits. The likelihood of such a collision depends on the size of the table 20. It will be appreciated that this structure does so by sacrificing certainty as to the likelihood that the desired data is indeed within the set, but that this structure requires much less storage space than traditional data structures that completely store all of the relevant data.

[0018] The false positive rate of a Bloom filter can be modified by increasing the size of the data structure, and thus the use of Bloom filters allows the implementations described herein to be tuned in a manner that maximizes accuracy within the given limits of storage space allowed for an app or client device. The false positive rate of a Bloom filter is approximately (1-e -kn / m ) k where k is the number of hashing functions used, m is the number of bits in the Bloom filter, and n is the number of elements expected to be inserted into the filter. Thus, the formula for optimizing the number of hash functions (i.e., the value of k) given specific values ​​of m and n is k=(m / n)ln(2).

[0019] Since remote resolution services for identifiers will not be available in this application, traditional identifier or server-side secret salts cannot be used. Nevertheless, it will be assumed that there is data available to the app publisher, e.g., email address or phone number. Thus, the Bloom filter may use data such as email address, phone number, or both. Other identifiers may be used in alternative implementations. However, since data elements such as these are PI, controls are in place to prevent disclosure of these inputs. PI items are encrypted by being hashed (e.g., using the SHA256 algorithm) and salted. The salt is kept separate from other salts to protect other workflows from inadvertent disclosure. In mobile environments (i.e., where the client device is a smartphone and similar devices), the salt is stored as a server-side secret. The secret can be retrieved from the device by connecting over a secure (e.g., SSL / TLS) connection that leverages a pinned certificate on the device. It will be impossible to intercept any of the traffic unless the device is jailbroken and rooted. Server-side secret salts can be periodically rotated and / or bound to specific viewers to protect the underlying data. In some implementations, PI items may be subject to multiple hashes using different algorithms, e.g., SHA1 / SHA256 / MD5 hash triplets. This can increase the confidence of the match (reducing the false positive rate), but also increase the size of the Bloom filter data structure.

[0020] To support attribution, the token resulting from the hash encryption process can be prefixed (or otherwise identified or associated) with a group identifier, representing a small but unidentifiable set of users (e.g., around 100) that can then be incorporated into the converted signal.

[0021] When a party wishing to send a targeting message provides a list of identifiers to the users it wishes to target in its message, then traditional ID resolution can be used to find the DSP's own internal linkages for those users. The DSP typically maintains linkages or identifiers for consumers, households, or businesses so that the DSP can unambiguously resolve the identities of individuals within these groups. For example, this allows the DSP to unambiguously resolve different people with the same first name, or to properly identify a person who has changed his or her first name (e.g., as a result of marriage) as being a single person despite being known by two different first names. One such ID resolution system is the AbiliTec service offered by LiveRamp, Inc. of San Francisco, California. After this resolution is complete, an append / enrichment step can be performed to associate all available plaintext identifiers with the linkages. Finally, the plaintext identifiers can be tokenized / encrypted and used to create the corresponding Bloom filters. A diagram illustrating this process is shown in Figure 3, which in this case uses LiveRamp technology.

[0022] Starting with customer relationship management (CRM) audience data 30, this input is provided to a resolution provider 32. In a resolution step 34, the CRM audience data 30 is used to resolve audience members to specific links. These are then mapped to hashed emails, hashed phone numbers, or both, in an append step 36 and appended to a data structure. The data structure is then pseudonymized in a tokenization step 38. The resulting data is then used to create the actual Bloom filters in a model step 40. In an activation step 42, the Bloom filters are distributed to partners for use in various apps by the SDK. These will then be ultimately distributed to user electronic devices 44 when the apps are downloaded by users.

[0023] To accommodate the Bloom filters created in this way, each app owner first configures the amount of storage allocated for targeted message processing via a remote management platform ("console"). In the timeline example of FIG. 4, at time 50, the app communicates with the server requesting the configuration of "ABC123". The server replies with the configuration and a list of filters BF1, BF2. At time 52, the app requests filters BF1 and BF2, and the server responds with the requested filters along with their respective transaction IDs and expiration dates. The app may attempt to download the bundle at a convenient time, e.g., when connected to Wi-Fi and the client device is plugged into an external power source. This may be timed, e.g., in the middle of the night, to minimize the degradation of the user experience associated with loss of performance on the client device during this time. The filters themselves are downloaded to a separate storage available within the app or application bundle. In iOS, for example, apps and their SDKs may have reservations regarding the loading of large amounts of data, e.g., data stored in a traditional manner on a network server. Thus, in certain implementations, campaigns will "bid" on a particular guaranteed dollar amount (PG) from the publisher to prioritize only the most valuable viewers at a given time. Later, at time 54, the app again requests the "ABC123" configuration. At this later date, the server responds with the configuration and a list of filters that includes only BF2. The SDK removes BF1, since BFI is not in this new version of the configuration. Still later, at time 56, the SDK also removes BF2, since the expiration date of Bloom filter BF2 has been reached at that point. Thus, in this example, at time 58, there are no more Bloom filters in the app.

[0024] In one particular implementation, shown in Figure 4, the gzip file format may be used for compression. A gzip Bloom filter containing the desired audience segment may be constructed as shown in Table 1 below, with the compression ratio between the raw data and the resulting Bloom filter shown in the right-most column: [Table 1] It can then be seen that if an app allocates 10MB (uncompressed) storage for targeted messaging on the device, it can support, for example, 847 viewers with 10,000 MD5 inputs, 87 viewers with 100,000 MD5 inputs, 9 viewers with 1,000,000 MD5 inputs, 1 viewer with 10,000,000 MD5 inputs, or a combination of 8 viewers with 100,000 MD5 inputs plus 3 viewers with 1,000,000 MD5 inputs. In various implementations, gzip filters can be downloaded nightly or weekly over Wi-Fi and campaign expiration times can be set.

[0025] Now referring to FIG. 5, the process that occurs in an app for the use of a Bloom filter can be described. A publisher who holds a PI, such as an email address or phone number 59, will pass it to a function in a tokenization routine 60 to create a token. This token can be queried against a set of Bloom filters 62. As already noted, the Bloom filter will return this via an ad request 64 to an ad exchange 66, giving a probabilistic result of whether the user is in the set or not within some confidence interval. The ad exchange 66 communicates with a DSP 68. For example, in some implementations, the Bloom filter may determine with 99.9% confidence that the user is in the set. As also previously mentioned, this interval can be adjusted depending on storage and accuracy needs. If the user is a match, the SDK will flag a predefined transaction identifier that corresponds to that particular message audience from the ad request 64. If not, the auction will proceed without it. Those DSPs 68 wishing to send targeted messages will know, with a high degree of confidence, that their transaction identifier is included in the bid request and that the desired user is associated with the client device, but no PI is sent off the device to make this determination. To prevent attempts to enumerate all members of the set, and thereby circumvent the privacy built into this system, in certain implementations calls to the Bloom filter may be placed after a rate limiting meter to make it infeasible to "break" the filter via this type of brute force attack.

[0026] Post-delivery attributes may be described with respect to FIG. 6. With matching at the device, user attributes after delivery of targeted messaging are inherently limited. Nevertheless, record-level events may be further supported in real time in certain implementations of the present invention. The system may not send user identifiers or proxies to remote devices. However, when a user is provided with a targeted message 80 and responds, for example, by clicking on an appropriate area in a display provided by the app publisher or simply viewing the displayed message 80, then a translation event 82 is fired to the SDK server of the message 80. That translation event 82 may not include user identification information, but may include other information useful in this context. In certain instances, this information may include group identifiers, bundle identifiers, transaction identifiers, timestamps, and / or creative units associated with the targeted messaging, as described above with respect to tokenization. Other types of information may be used in alternative implementations, provided that PI is not sent to the remote device and the user's identity cannot be reasonably ascertained through the inclusion of these additional attributes. By enabling real-time reporting, parties requesting the sending of targeted messages can be better able to map both "active" and "passive" events related to conversions at a population level, if not an individual level. Such information can be stored for subsequent analysis in database 84.

[0027] The process of initializing the SDK before use may now be described. In a preferred embodiment, the SDK will include a fallback configuration. The fallback configuration is the default configuration for the SDK when the device does not have a cached fallback configuration or a cached online configuration and the network connection is not functional. This ensures that the SDK will be usable regardless of the state of the network or console platform. If a fallback configuration is not provided, then in such an embodiment, the SDK may be configured to enter an error state and an error event may be triggered.

[0028] To provide a custom online configuration, the online configuration is fetched from the console platform using a provided application programming interface (API) key. If the API key is valid, and if there is a working network connection, and if there are no network errors, then a new configuration may be obtained from the console platform and stored with the SDK. This may then be referred to as a cached online configuration. As mentioned above, the fallback configuration is the previously cached online configuration, and if the previously cached online configuration is unavailable then the default fallback configuration provided as part of the SDK is used.

[0029] Referring now to FIG. 7 to further discuss SDK initialization and configuration as part of the overall system setup, the process may begin with a connectivity service 90, for example, the LiveRamp connectivity service provided by LiveRamp, Inc. The connectivity service 90 is a cloud-based software application for uploading, managing, and distributing data. The connectivity service 90 may also be used to "onboard" data to take data acquired via offline transactions and move the data to an online environment so that it may be used, for example, in online digital messaging. The connectivity service 90 communicates with a cloud platform, in this case, Google Cloud Storage (GCS) storage 92, which is part of the Cask Data Application Platform (CDAP). CDAP is a general application platform for building and managing data applications in a multi-cloud environment. The list of identifiers 94 is then used to create a Bloom filter JSON (Java Script Object Notation) object 96 using the methods described above. Metadata 98 ​​may be used in this process, including components such as those described above, which in this case are integrated into Amazon Web Services (AWS) storage 100.

[0030] AWS storage 100 uses the Bloom filter metadata 102 to communicate with a process to convert the Bloom filter JSON object 96 into a binary format. This is stored in a second AWS storage area 106. From this point, the console platform 108, whose functionality was previously described, takes over the process. From the console, the user can select the Bloom filter to be deployed in a filter selection process 110, and configuration is performed in a configuration process 112.

[0031] The console platform 108 communicates with the SDK 118 over a network (e.g., the Internet). In this manner, Bloom filter initialization, configuration, and selection can be performed. The SDK 118 communicates with each of these processes and pulls data from the second AWS storage area 106. The SDK 118 can also communicate with the authorized traffic solution (ATS) API 114, a service provided by LiveRamp, Inc. The ATS service 114 allows content publishers to recognize their known users on their sites in a real-time manner, thereby allowing publishers to immediately engage with their customers based on this recognition. The API structure allows for rapid engagement and interaction. The publisher app 124, including the SDK 118 as described above, can use all of this data to perform operations including targeted messaging regarding users of devices on which the publisher app 124 is installed.

[0032] During operation, the publisher app 124 may receive an individual user identifier 116. This may occur, for example, when a user interacts with a publisher property. As part of the operation of the SDK 118, a query is made to determine whether the user of the device has elected to block third party tracking or similar functionality for that particular app. In an iOS example, the determination is made with respect to Apple's ATT service. If blocking is not selected, then processing proceeds in the normal manner within the program's messaging environment by providing a "Deal ID," which is a representative identifier used by buyers and publishers within messaging auctions in the program's real-time bidding ecosystem. The SDK 118 may receive the Deal ID 120 by sending a request for a Deal ID to the ATS API 114. This request may be fulfilled in real time. If blocking is selected, then the SDK 118 instead generates a RampID envelope, in this particular example. The RampID envelope, a product of LiveRamp, Inc., is an identifier and associated metadata that may be used for identification on the device and in connection with Bloom filter functionality as described above.

[0033] Since the system provides the console platform 108 with the opportunity to select among various Bloom filters to be deployed in the Bloom filter selection step 110, the system also includes a process for Bloom filter synchronization to meet such requirements. Synchronization may be performed manually by the app developer or automatically as part of SDK 118 initialization as described above. The configuration will indicate whether the SDK 118 should automatically synchronize Bloom filters or wait for a manual command from the console platform 108. In some embodiments, even in the case of a configuration process for automatic Bloom filter synchronization, the app developer may manually initiate Bloom filter synchronization via the console platform 108 at any desired time to maintain the highest level of functionality of the publisher app 124.

[0034] When synchronization is triggered (manually or automatically), the SDK 118 determines whether the latest Bloom filters have already been downloaded. If so, then the SDK 118 enters a ready state since no further processing is required. If the latest Bloom filters have now been downloaded, or if the SDK 118 has no Bloom filters downloaded at all, then the synchronization process begins. After the current and desired Bloom filters have been successfully downloaded to the SDK 118, they are then stored on the user device and made available to the publisher app 124 for execution.

[0035] If the download of the current and desired Bloom filter(s) fails and there is no current Bloom filter previously downloaded to the SDK 118, then the SDK 118 enters an error state and a corresponding error event is triggered. If the SDK 118 has previously used and downloaded a Bloom filter, then the SDK 118 may operate in an offline mode using the previously cached filter. In certain embodiments, there may also be an event triggered indicating that the SDK 118 is using a cached filter rather than the latest Bloom filter that may be available for download.

[0036] 8, the process for synchronizing Bloom filters with respect to the SDK 118 may be described in further detail. The process begins with a get transaction ID step 130, which in certain implementations are then salted and hashed for security purposes in a salt and hash identifiers step 132. With the identifiers now ready for processing, synchronization begins in a synchronize Bloom filters step 134. The synchronization itself is performed within a synchronization block 136, which signals that background synchronization has begun in a start synchronization step 138.

[0037] From a synchronization start step 140 in synchronization block 136, a configuration update begins at step 142. If it is determined at decision step 144 that one or more Bloom filters have been deleted, then SDK 118 deletes all transactions having the transaction ID from cache database 176 at step 146 and deletes the corresponding Bloom filter information from cache database 176 at step 148. The appropriate synchronization process then begins at step 150 and, for each Bloom filter, a query is made at decision 152 whether the Bloom filter has been updated from the version stored in SDK 118. If the Bloom filter has been updated, then all transactions having the transaction ID are deleted from cache database 176 corresponding to the updated Bloom filter at step 154 ​​and the Bloom filter is then updated at step 156. If the Bloom filter has not been updated at query step 152, then a determination is made at query step 158 whether this is a new Bloom filter. If so, then the new Bloom filter is stored in the cache database 176 in step 160 .

[0038] If there is an updated or new Bloom filter as determined by the process as described above, then the process next proceeds to determine whether the salted and hashed identifier from step 132 is found in the updated or new Bloom filter in step 162. Again, this process occurs for each updated or new Bloom filter as it is processed. Once an identifier is found, the identifier is stored in the database in step 164 and an update is made to the last accessed register for that identifier in step 166. At this point, a determination is made in step 168 as to whether the synchronization is finished. The synchronization will also indicate that it is finished if there is no updated or new Bloom filter. In either case, a background synchronization done signal is sent in step 170.

[0039] After the synchronization process is completed as described above, processing may move to using a Bloom filter on the hashed identifier for resolution. In step 172, the transaction ID is retrieved from a cache database of hashed identifiers 176, and in step 174, the transaction is returned.

[0040] 8 also shows a possible structure of each identifier 178, user transaction 180, and bloom filter 182 stored in cache database 176. Identifier 178 may be composed of an identifier ID, which is a variable type integer and may be automatically generated, a hashed identifier, which is a string variable type, which is a hashed version of the identifier used in step 172, a last access field, which is a type date, which is a timestamp indicating when identifier 178 was last accessed, and finally a type field, which is an enumerated variable type and may be a data field such as a phone number, email address, or customer ID used to match a particular individual.

[0041] A user transaction 180, as stored in the cache database 176, consists of a corresponding identifier ID as a set described in terms of identifier 178, as well as a transaction ID of a variable type string indicating the transaction ID from the Bloom filter that was matched in the filter calculation.

[0042] The Bloom filter 182, as stored in the cache database 176, consists of a transaction ID string, which is the transaction ID from the Bloom filter 182, as previously described, a filter field which identifies the contents of the Bloom filter, an expiration date which identifies when the Bloom filter expires, if an expiration date is given, and a last updated field which is also of type date, indicating when the Bloom filter 182 was last updated.

[0043] In conjunction with Bloom filter synchronization as described above, SDK 118 data refresh may be triggered with each SDK 118 initialization and with each event that the app 124 is sent from background to foreground within the device operating system. This may be performed automatically if so defined in the configuration. If the SDK 118 is in offline mode (i.e., no Internet connection or no Wi-Fi in "mobile only" mode), then all cached filters with past expiration dates should be considered stale and deleted. Figure 9 provides an overview of such a process. From a start step 180, the remainder of the identifier 182 is provided along with input parameters 184. The input parameters 184 include the user identifier converted to a byte array type as provided in a certain programming language such as Python, a salt, an iteration index determined by the number to be calculated, a size representing the calculated size of the Bloom filter depending on the input size and the desired precision, an "input size" field representing the number of user identifiers in the user identifier list 182, and a precision value representing the false positive precision. These are fed into a process for creating a Bloom filter object 186. In step 188, the identifier is converted to a byte array format (i.e., an array of bytes) and a numHash calculation is performed in step 192. This depends on the "size" value divided by the "input size" value multiplied by ln(2), which is converted to an integer variable type in step 190.

[0044] In step 194, the system calculates which bits in a bitset (a string of bits used for bitwise operations) will be turned on, and the step is repeated depending on the value of numHash. The sub-steps of step 194 begin with step 202, where an index value is appended to a salt value to generate a salt input value. This is appended to an identifier in sub-step 204, and then hashed using the SHA256 algorithm. The salt input value is then appended to the result of sub-step 204, and hashed with the MD5 algorithm in sub-step 206. A final sub-step 208 is performed by calculating the modulus of the output of sub-step 206 with respect to the size value, and the absolute value of the result is taken.

[0045] In step 196, the result of step 194 is exported to a file. This includes sub-step 198 of adding the base 64 representation to the Bloom filter metadata, and then converting the bitset variables to byte arrays and then to base 64 in sub-step 200. The process ends with a refresh in the final step 210.

[0046] In the implementations described herein, and in various alternative implementations, the invention may be implemented by any combination of hardware and software. For example, in one embodiment, the systems and methods may be implemented by a computer system or collection of computer systems, each including one or more processors that execute program instructions stored on a computer-readable storage medium coupled to the processor. The program instructions may implement the functionality described herein. The various systems and displays shown in the figures and described herein represent example implementations. The order of any method may be changed, and various elements may be added, modified, or omitted.

[0047] The computing system or computing device described herein may implement the hardware portion of a cloud computing system or a non-cloud computing system as forming part of various implementations of the present invention. The computing system may be any of various types of devices including, but not limited to, a commodity server, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a handheld computer, a workstation, a network computer, a consumer device, an application server, a storage device, a telephone, a mobile phone, or generally any type of computing node, computing node, computing device, and / or computing device. The computing system includes one or more processors (any of which may include multiple processing cores, which may be single or multi-threaded) coupled to a system memory via an input / output (I / O) interface. The computing system may further include a network interface coupled to the I / O interface.

[0048] In various embodiments, the computer system may be a single processor system including one processor, or a multiprocessor system including multiple processors. The processor may be any suitable processor capable of executing computing instructions. For example, in various embodiments, the processor may be a general purpose or embedded processor implementing any of a variety of instruction set architectures. In a multiprocessor system, each of the processors may generally, but not necessarily, implement the same instruction set. The computer system also includes one or more network communication devices (e.g., network interfaces) for communicating with other systems and / or components over a communications network, e.g., a local area network, a wide area network, or the Internet. For example, a client application executing on the computing device may use the network interface to communicate with a server application executing on a cluster of servers implementing one or more of the components of the system described herein in a cloud computing or non-cloud computing environment, either on a single server or as implemented in various subsystems. In another example, an instance of a server application executing on a computer system may use the network interface to communicate with other instances of the application that may be implemented on other computer systems.

[0049] The computing device also includes one or more persistent storage devices and / or one or more I / O devices. In various embodiments, the persistent storage devices may correspond to disk drives, tape drives, solid state memory, other mass storage devices, or any other persistent storage devices. A computer system (or a distributed application or operating system running thereon) may store instructions and / or data in the persistent storage devices as desired and may retrieve the stored instructions and / or data as needed. For example, in some embodiments, a computer system may implement one or more nodes of a control plane or control system, and the persistent storage may include SSDs attached to the server nodes. Multiple computer systems may share the same persistent storage device or may share a pool of persistent storage devices, where the devices in the pool represent the same or different storage technologies.

[0050] A computer system includes one or more system memories capable of storing code / instructions and data accessible by a processor. System memory may include, for example, multiple levels of memory and memory caches in a system designed to swap information in memory based on access speed. Interleaving and swapping may extend to persistent storage in virtual memory implementations. Techniques for implementing memory may include, by way of example, static random access memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, or flash type memory. As with persistent storage, multiple computer systems may share the same system memory, or may share a pool of system memory. The one or more system memories may include program instructions executable by a processor to implement the routines described herein. In various embodiments, the program instructions may be encoded in binary, assembly language, any interpreted language such as Java, compiled language such as C / C++, or any combination thereof, and the specific languages ​​illustrated herein are merely illustrative. In some embodiments, the program instructions may implement multiple separate client, server nodes, and / or other components.

[0051] In some implementations, the program instructions may include instructions executable to implement an operating system (not shown), which may be any of a variety of operating systems, e.g., UNIX, LINUX, Solaris, MacOS, or Microsoft Windows. Any or all of the program instructions may be provided as a computer program product or software, which may include a non-transitory computer-readable storage medium having instructions stored thereon that may be used to program a computer system (or other electronic device) to execute a process according to various implementations. A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software, processing application) that can be read by a machine (e.g., a computer). Generally speaking, a non-transitory computer-accessible medium may include a computer-readable storage medium or memory medium, such as a magnetic or optical medium, e.g., a disk or DVD / CD-ROM coupled to a computer system via an I / O interface. A non-transitory computer-readable storage medium may also include any volatile or non-volatile medium, such as a RAM or ROM, that may be included in some embodiments of a computer system as a system memory or another type of memory. In other implementations, the program instructions may be communicated using optical, acoustic or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) transmitted over a communications medium such as a network and / or a wired or wireless link, which may be implemented, for example, via a network interface. The network interface may be used to interface with other devices, which may include other computer systems or any type of external electronic device.Generally, system memory, persistent storage, and / or remote storage accessible by other devices over a network may store data blocks, copies of data blocks, metadata associated with the data blocks and / or their state, database configuration information, and / or any other information usable in implementing the routines described herein.

[0052] In certain implementations, the I / O interface may coordinate I / O traffic between the processor, system memory, and any peripheral devices in the system, including through a network interface or other peripheral interface. In some embodiments, the I / O interface may perform any necessary protocol, timing, or other data media conversion to convert data signals from one component (e.g., system memory) into a format suitable for use by another component (e.g., processor). In some embodiments, the I / O interface may include support for devices attached via various types of peripheral buses, e.g., variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. Also, in some embodiments, some or all of the functionality of the I / O interface, e.g., the interface to the system memory, may be incorporated directly into the processor.

[0053] The network interface may enable data to be exchanged between the computer system and other devices attached to the network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only nodes, and / or clients of the database system described herein). In addition, the I / O interface may enable communication between the computer system and various I / O devices and / or remote storage. In some embodiments, the input / output devices may include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for inputting or obtaining data by one or more computer systems. These may be directly connected to a particular computer system or may generally connect to multiple computer systems in a cloud computing environment, grid computing environment, or other system that includes multiple computer systems. Multiple input / output devices may be in communication with the computer system or may be distributed among various nodes of a distributed system that includes the computer system. The user interfaces described herein may be visible to a user using various types of display screens, which may include CRT displays, LCD displays, LED displays, and other display technologies. In some implementations, input may be received via a display using touch screen technology, while in other implementations, input may be received via a keyboard, mouse, touchpad, or other input technology, or any combination of these technologies.

[0054] In some embodiments, the similar input / output devices may be separate from the computer system and may interact with one or more nodes of a distributed system including the computer system via a wired or wireless connection, e.g., via a network interface. The network interface may generally support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11, or another wireless networking standard). The network interface may support communication over any suitable wired or wireless general data network, e.g., other types of Ethernet networks. In addition, the network interface may support communication over a telecommunications / telephone network, such as an analog voice network or a digital fiber communications network, over a storage area network, such as a Fibre Channel SAN, or over any other suitable type of network and / or protocol.

[0055] Any of the distributed system embodiments described herein, or any of their components, may be implemented as one or more network-based services in a cloud computing environment. For example, read / write nodes and / or read-only nodes in a database tier of a database system may present database services and / or other types of data storage services using the distributed storage system described herein to clients as network-based services. In some embodiments, the network-based services may be implemented by software and / or hardware systems designed to support interoperable machine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format, e.g., Web Services Description Language (WSDL). Other systems may interact with the network-based service in a manner prescribed by the description of the network-based service's interface. For example, a network-based service may define various operations that other systems can invoke and may define a particular application programming interface (API) to which other systems may be expected to conform when requesting the various operations.

[0056] In various embodiments, a network-based service may be requested or invoked through the use of a message that includes parameters and / or data associated with the network-based service request. Such messages may be formatted according to a particular markup language, such as Extensible Markup Language (XML), and / or may be encapsulated using a protocol, such as Simple Object Access Protocol (SOAP). To perform a network-based service request, a network-based service client may assemble a message that includes the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) that corresponds to the web service using an Internet-based application layer transport protocol, such as HyperText Transfer Protocol (HTTP). In some embodiments, a network-based service may be implemented using Representational State Transfer (REST) ​​techniques rather than message-based techniques. For example, a network-based service implemented according to REST techniques may be invoked via parameters included in an HTTP method, such as PUT, GET, or DELETE.

[0057] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of exemplary methods and materials are described herein. It will be apparent to one of ordinary skill in the art that many more modifications are possible without departing from the inventive concepts herein.

[0058] All terms used herein should be interpreted in the broadest possible manner consistent with the context. When a group is used herein, it is intended that all individual members of the group and all possible combinations and subcombinations of the group are included individually. When a range is stated herein, it is intended that the range includes all subranges and individual points within the range. All references cited herein are incorporated by reference unless there is a discrepancy with the disclosure of this specification.

Claims

1. 1. A method for providing identity resolution at a device, comprising: receiving, at a resolution provider, a plurality of audience member records; resolving each of the plurality of audience member records to an audience member link to create a plurality of audience member links; creating a data structure mapping each of said audience member links to a corresponding hashed personal identifier; pseudonymizing the data structure to generate a plurality of pseudonymized hashed personal identifiers; in at least one Bloom filter including a bit vector including a plurality of bits for each of the pseudonymized hashed personal identifiers, setting each bit in the bit vector in the index to the pseudonymized hashed personal identifier to a value of one; sending the at least one Bloom filter to a software development kit (SDK) on a user device, the SDK including an app; receiving, in the app, an item of personal information (PI) from an issuer; creating tokens from items of said PI; querying the token against the at least one Bloom filter to determine a match or non-match result; sending the results of the query to an ad exchange; if the result is a match, flagging a predefined transaction identifier that corresponds to the particular message viewer; receiving a conversion event from the publisher; A method comprising:

2. The method of claim 1 , wherein the item of PI is an email address or a phone number.

3. The method of claim 2 , wherein the conversion event does not include PI.

4. The method of claim 3 , further comprising allocating, via the app, an amount of storage on the user device for the at least one Bloom filter.

5. The method of claim 4 , wherein the step of allocating an amount of storage on the user device via the app is performed via a remote management platform.

6. The method of claim 5 , further comprising sending a transaction ID and an expiration date of the at least one Bloom filter to the app.

7. 7. The method of claim 6, further comprising fetching an online configuration of the SDK from the remote management platform using an application programming interface (API) key.

8. 8. The method of claim 7, further comprising creating the at least one Bloom filter as a JavaScript Object Notation (JSON) object and then converting the JSON object into a binary format using Bloom filter metadata.

9. The method of claim 8 , wherein the at least one Bloom filter is selected from among a plurality of Bloom filters via the remote management platform.

10. The method of claim 9 , further comprising receiving a user identifier from the issuer.

11. The method of claim 10 , wherein the user identifier is a transaction ID or an ID envelope.

12. 12. The method of claim 11, further comprising synchronizing the at least one Bloom filter by deleting all transaction IDs in the at least one Bloom filter when the at least one Bloom filter is deleted or updated.

13. 13. The method of claim 12, wherein the synchronizing the at least one Bloom filter further comprises receiving a Bloom filter identifier and updating a last accessed register with the Bloom filter identifier.

14. 14. The method of claim 13, wherein the Bloom filter identifier is a variable type integer, a hashed string, a last accessed field, or a type field containing a phone number, an email address, or a customer ID.

15. 13. The method of claim 12, further comprising: performing an SDK refresh upon initialization and upon each one of an event in which the app is sent from background to foreground on the user device.

16. 16. The method of claim 15, wherein the step of performing an SDK fresh further comprises deleting the at least one Bloom filter if the at least one Bloom filter becomes stale.

17. The method of claim 1 , wherein the match results include probabilistic results.

18. 20. The method of claim 17, further comprising the step of limiting a rate of calls to the at least one Bloom filter.

19. 1. A system for providing identity resolution at a device, comprising: a software development kit (SDK) on a user device, the SDK including a Bloom filter, the Bloom filter including a bit vector including a plurality of bits; the SDK further includes an app configured to receive items of personal information (PI) from a publisher, use the items of PI to determine whether a match occurs within the Bloom filter to generate a result, and transmit the result to an ad exchange; The system further comprises: A system comprising: a remote development platform configured to allocate an amount of storage at the user device for the Bloom filter and to return an online configuration of the SDK in response to a call with an application programming interface (API) key.

20. 20. The system of claim 19, wherein the app further comprises a rate limiting meter configured to limit calls to the Bloom filter.

Images