Patent Description:
As people continue to shop online, more and more third parties may obtain information about their computing devices, often without the people knowing. Third parties can use the information stored on the content servers to provide content to the computing devices as the computing devices visit further web pages. While there are laws that require the third parties to identify whether they have information about computing devices upon request, computing devices may provide device information (e.g., device identifiers associated with the computing devices) to the third parties when making requests if the third parties did not already have information about the device. Further, the third parties may be reluctant to reliably answer the requests from the computing devices because malicious parties may eavesdrop on the requests to determine how much information the third parties have.

<CIT> describes systems and methods for audience measurement in which an audience measurement server captures content identifiers and client identifiers of devices receiving content, a panel provider generates a probabilistic data structure via a hash of the client identifiers, the audience measurement server utilizes the filter array to extract a subset of measurement data including the data of the panel members, as well as data of some non-panel members as false positives, without being able to distinguish between the members and non-members.

<CIT> describes systems and methods for obfuscated audience measurement wherein, if the audience measurement server determines that the size of any subset of client identifiers selected by applying a filter or data array is less than a predetermined threshold, the audience measurement server may calculate a hash of each client identifier in the subset, and a clock time may be used as salt for each hash calculation, such that the hash for each subset is salted with a different clock value.

The systems and methods discussed herein provide a method of secure identification retrieval so computing devices need not provide information to content servers or content providers that the content servers or content providers do not already have when making a request to determine whether the content servers or content providers have already collected data about the computing devices. The computing devices may calculate query tokens specific to each computing device and, in some implementations, based on a periodic variable with a value
that continually changes over time. The computing devices may be synchronized with various content servers so the content servers can calculate stored query tokens for device identifiers in databases of the content servers using the same periodic variable and crypto technique as the computing devices. To avoid any synchronizing errors between the content servers and the computing devices, in some implementations, the content server may calculate multiple query tokens for each device identifier in a database of the content server. When the content servers receive requests including the query tokens, the content servers may compare the query tokens to the stored query tokens in the database to identify a match. If a content server identifies a match, the content server may transmit a response signal (e.g., an answer) indicating a match was found. The content server may also include an identification of characteristics about the computing device associated with the matching stored query token in the response signal. If a content server is not able to identify a matching stored query token to a query token of a query, the content server may send a response signal to the computing device associated with the query indicating that no match was found.

To protect the privacy of the computing devices querying the content servers and the data confidentiality of the content servers themselves (e.g., keep an amount of data and data collection capabilities of the content servers private), content servers may confirm that a computing device is associated with the queries that the content servers receive and encrypt any answers that the content servers send to the querying computing devices. The content servers may verify the identity of computing devices by using public keys associated with device identifiers of the computing devices on a digital signature generated by the computing devices to sign their queries. The content servers may encrypt answers to the computing devices using the public keys associated with the computing devices. Consequently, only the computing devices associated with their device identifiers may obtain information from content servers about whether the content servers have collected data about them. In some implementations, the response signal indicating no match may be padded to a predetermined length, may include default or null information, and/or may be hashed or encrypted such that the negative response signal appears similar to a positive response signal to any eavesdropping device or to a malicious computing device attempting to probe for information.

The systems and methods described herein may also be used by browsers to determine which domains have collected data about the browsers. The browsers can use similar crypto techniques as described above, but with values of domains and cookies to calculate cookie query tokens. The domains can calculate stored cookie query tokens for browsers for which the domains have stored data using the same techniques and values that the browsers use to calculate cookie query tokens. The domains can compare the cookie query tokens they receive from the browsers to the stored cookie query tokens to determine if the domains have stored data for the browser. The domains may store data about the browser at a server that is hosting the domain. The domains can send a response signal to the browsers indicating whether any information about the browsers is stored and categories of the information. The domain can encrypt the response signal so malicious third parties may not be able to determine how much or what type of data the domain has gathered.

Advantageously, by implementing the systems and methods discussed herein, computing devices may securely query content servers for identifications of whether the content servers have information about the computing devices without providing content providers with any device identifying information that the content servers did not already have stored. The query tokens may continually change so content servers that did not have device identifiers of the querying devices may not obtain any lasting information about the devices. Similarly, the systems may be secure against probing attempts for information, through the use of hashed or encrypted responses and padding of negative acknowledgements. Further, the communication between the devices and the content servers may be secure to protect the content servers from providing data to malicious third parties indicating how much information the content servers have collected. Consequently, the systems and methods discussed provide a secure method of communication between computing devices and content servers so the computing devices may ask for information from content server without providing any new device identifying information and the content servers may respond without providing data to malicious third parties.

In an aspect described herein, a method for secure identification retrieval is described. The method may include retrieving, by a server device, a value of a periodic variable and calculating, by the server device, a plurality of query tokens from a corresponding plurality of client device identifiers and the value of the periodic variable. Each query token may be associated with a corresponding client device identifier in a first database. The method may further comprise receiving, by the server device from a first client device, a first query token calculated from a client device identifier of the first client device and the value of the periodic variable; identifying, by the server device, a second query token of the calculated plurality of query tokens in the first database matching the first query token; and, responsive to the identification, retrieving, by the server device, the associated client device identifier. The method may further comprise retrieving, by the server device from a second database, one or more characteristics of the first client device according to the associated client device identifier and transmitting, by the server device to the client device, the retrieved one or more characteristics.

In some implementations, the method may further comprise generating, by the server device, a probabilistic data structure based on the calculated plurality of query tokens; and comparing, by the server device, the first query token to the probabilistic data structure. Identifying the second query token may be performed responsive to the first query token matching the probabilistic data structure.

In some implementations, the probabilistic data structure may comprise a Bloom filter. In some implementations, the periodic variable may comprise a present date a stock exchange closing price, or a mutually verifiable value. In some implementations, calculating the plurality of query tokens may comprise calculating a second plurality of query tokens from the corresponding plurality of client device identifiers and a previous value of the periodic variable, the second plurality of query tokens stored in the first database in association with the corresponding client device identifier.

In some implementations, the method may further comprise removing, by the server device, a third plurality of query tokens from the first database, the third plurality of query tokens calculated from the plurality of client device identifiers and a twice-previous value of the periodic variable. In some implementations, calculating the plurality of query tokens further comprises calculating, for each of the plurality of query tokens, a one-way hash (e.g., any of the hashing functions published by the National Institute of Standards and Technology such as Secure Hash Algorithm-<NUM>) of a combination of the value of the periodic variable and the corresponding client device identifier. In some implementations, retrieving the one or more characteristics of the first client device further comprises retrieving a public encryption key of the first client device from the second database. Transmitting the retrieved one or more characteristics may further comprise encrypting the one or more characteristics with the retrieved public encryption key of the first client device.

In some implementations, the method may further comprise receiving, by the server device from a second client device, a third query token calculated from a client device identifier of the second client device and the value of the periodic variable; and determining, by the server device, that an entry does not exist in the first database corresponding to the third query token.

In some implementations, the method may further comprise, responsive to the determination that an entry does not exist in the first database corresponding to the third query token, transmitting, by the server device to the second client device, one of a random data string or a null data string. In some implementations, the plurality of client device identifiers may comprise cookie values. In some implementations, the plurality of query tokens may be calculated from the periodic value, the cookie values, and a plurality of domain identifiers, each cookie value corresponding to a domain identifier of the plurality of domain identifiers. In some implementations, a first cookie value may be associated with a first domain and shared with a second domain. In some implementations, the server device may be associated with one of the first domain or the second domain, and a second server device is associated with the other of the first domain or the second domain.

In some implementations, retrieving the associated client device identifier may further comprise retrieving a first cookie value and a first domain identifier. Transmitting the retrieved one or more characteristics may further comprise encrypting, by the server device that is associated with the second domain, the retrieved one or more characteristics with the first cookie value and the first domain identifier.

In another aspect described herein, a server device for secure identification retrieval is described. The server device may comprise a network interface in communication with a first client device of a plurality of client devices; a memory device storing a first database comprising a plurality of query tokens and a corresponding plurality of associated client device identifiers, and a second database comprising the plurality of client device identifiers and associated device characteristics; and a processor. The processor may be configured to retrieve a value of a periodic variable, calculate the plurality of query tokens from the corresponding plurality of client device identifiers and the value of the periodic variable, and receive, via the network interface from the first client device, a first query token calculated from a client device identifier of the first client device and the value of the periodic variable. The processor may be further configured to identify a second query token of the calculated plurality of query tokens in the first database matching the first query token and, responsive to the identification, retrieve, from the first database, the associated client device identifier. The processor may be further configured to retrieve, from the second database, one or more characteristics of the first client device according to the associated client device identifier, and transmit, via the network interface to the client device, the retrieved one or more characteristics.

In some implementations, the processor may be further configured to generate a probabilistic data structure based on the calculated plurality of query tokens; and compare the first query token to the probabilistic data structure. Identifying the second query token may be performed responsive to the first query token matching the probabilistic data structure.

In some implementations, the processor may be further configured to calculate a second plurality of query tokens from the corresponding plurality of client device identifiers and a previous value of the periodic variable, the second plurality of query tokens stored in the first database in association with the corresponding client device identifier. In some implementations, the processor may be further configured to remove a third plurality of query tokens from the first database, the third plurality of query tokens calculated from the plurality of client device identifiers and a twice-previous value of the periodic variable. In some implementations, the processor may be further configured to calculate, for each of the plurality of query tokens, a one-way hash of a combination of the value of the periodic variable and the corresponding client device identifier.

Optional features of one aspect may be combined with any other aspect.

Other features, aspects, and advantages of the disclosure will become apparent from the description, the drawings, and the claims, in which:.

As users browse the Internet, content servers may obtain device identifiers and various other data about the computing devices that users use to browse, often without the user knowing the content servers have collected such data. By obtaining device identifiers and the various other data, content servers may individually identify the computing devices to provide them with targeted content (e.g., content based on data about the computing devices). Because device identifiers of computing devices can be retrieved and stored by content server as the computing devices visit various web pages, people using the computing devices may not be able to stop their computing device from being identified by content servers. While the computing devices may query content servers to determine if the content servers have collected data about the computing devices, the content servers generally store the data based on device identifiers of the computing devices. Consequently, in such implementations, client devices that send queries to content servers for a device identification may not be able to send the queries without providing device identifiers of the client devices for the content servers to identify. Once content servers have identified the device identifiers, the content servers may store the device identifiers to provide targeted content to the computing devices in the future.

For example, referring first to <FIG>, illustrated is a block diagram of two sequences <NUM> and <NUM>, each sequence <NUM> and <NUM> including a device sending a query to a content server asking whether the content server has stored data about the device and, if the content server has stored data about the device, the type or category of the data, in some implementations. Sequence <NUM> may be a sequence of a client device <NUM> sending a query to a content server <NUM> for an indication of whether content server <NUM> has collected data about client device <NUM>. Content server <NUM> may have collected data about client device <NUM> while client device <NUM> browsed the Internet and viewed various web pages and/or domains. Client device <NUM> may include a device identifier of client device <NUM> in the query so content server <NUM> may identify the data that content server <NUM> has stored and that is associated with client device <NUM>.

At sequence <NUM>, client device <NUM> may send a query to content server <NUM> asking if content server <NUM> has data about client device <NUM>. Client device <NUM> may include a device identifier (e.g., Device <NUM>) of client device <NUM> in the query that can individually identify client device <NUM>. Content server <NUM> may include a database <NUM> that includes a list of device identifiers (e.g., device <NUM>, device <NUM>, device <NUM>, etc.) of the various devices for which content server <NUM> has collected data. Content server <NUM> may process database <NUM> and compare the device identifier of the query with the device identifiers in database <NUM>. If content server <NUM> identifies a matching identifier in device database <NUM>, content server <NUM> may transmit a signal to client device <NUM> indicating that content server <NUM> has collected data about client device <NUM>. If content server <NUM> does not identify a matching identifier in database <NUM>, however, content server <NUM> may transmit a signal to client device <NUM> indicating that content server <NUM> has not collected data about client device <NUM>.

In some implementations, if content server <NUM> determines that there is not a matching device identifier in database <NUM>, content server <NUM> may add the device identifier of client device <NUM> to database <NUM>. Content server <NUM> may inform client device <NUM> that it has added the device identifier to database <NUM> or, in some cases, indicate that content server <NUM> does not have data about client device <NUM> while nonetheless storing the device identifier of client device <NUM>. Consequently, by querying content server <NUM> to determine if content server has data about client device <NUM>, client device <NUM> may, in turn, unintentionally or undesirably provide data (e.g. client device <NUM> IP address) about client device <NUM> to content server <NUM>. In some implementations, content server <NUM> may be able to obtain additional information about client device <NUM> along with the query, such as a device type, browser type, operating system type, or other such information (e.g. from metadata in an HTTP request such as a user agent field, identification of whether the device has a touchscreen or not (indicating that the device may be a mobile device), etc.).

Conversely, sequence <NUM> illustrates an example sequence of a client device <NUM> sending a similar query to a content server <NUM>. In sequence <NUM>, however, client device <NUM> may send an encrypted (or crypto-hashed, e.g. via SHA256) device identifier to content server <NUM> in the query. Specifically, in some implementations of sequence <NUM>, client device <NUM> may send a query to content server <NUM> asking if content server <NUM> has data about client device <NUM> without including explicit or unencrypted device identifiers or other data as part of the query. To send the query, client device <NUM> may first calculate a query token based on a device identifier of client device <NUM>. The query token may also be calculated based on a value of a periodic variable (e.g. a variable updated hourly, daily, weekly, or any other such interval) and a crypto technique (e.g., a one-way hashing technique like SHA256) that is known to both content server <NUM> and client device <NUM>. The periodic variable may be a mutually verifiable variable that may be verified by client device <NUM> and content server <NUM>. As will be described in greater detail below, in some implementations, client device <NUM> may calculate the query token by concatenating the device identifier of client device <NUM> with a value of the periodic variable and performing the crypto technique known to both client device <NUM> and content server <NUM>. Client device <NUM> may calculate the query token (e.g., 27D2C8BC4 in the example illustrated) and send the query token to content server <NUM> with the query.

Content server <NUM> may be a server that collects data about client devices such as client device <NUM> and stores the data in a database <NUM> of content server <NUM>. Content server <NUM> may collect and store device identifiers that are associated with each client device that content server <NUM> has stored data for. Content server <NUM> may calculate multiple stored query tokens for each device identifier. Content server <NUM> may calculate the stored query tokens using values of the same periodic variable and the same crypto technique as client device <NUM>. In some implementations, content server <NUM>, may store multiple stored query tokens for each device identifier in case content server <NUM> and client device <NUM> are not perfectly synchronized (e.g., are relying on data from different sources that do not match such as clocks that provide different times), which could cause a false negative if content server <NUM> searches database <NUM> for a stored query token that was calculated based on a value of the periodic variable that is different from the value that client device <NUM> used to calculate the query token.

Content server <NUM> may compare the query token that client device <NUM> sent to content server <NUM> to the stored query tokens in database <NUM>. If content server <NUM> identifies a matching query token, content server <NUM> may transmit a signal to client device <NUM> indicating that a match was found. In some implementations, content server <NUM> may also retrieve previously stored information about client device <NUM> (e.g. from a separate database or associated with the token identifiers in the same database), and may transmit a signal indicating categories of data that content server <NUM> has collected for client device <NUM>. If content server <NUM> determines that there is not a matching value, however, content server <NUM> may transmit a signal to client device <NUM> indicating that no match was found and, consequently, content server <NUM> has not collected data about client device <NUM>. Client device <NUM> may send similar queries to any number of content servers to determine a number of content servers that have collected data about client device <NUM>.

Advantageously, as represented in sequence <NUM>, because client device <NUM> uses a crypto technique on the device identifier of client device <NUM>, client device may transmit queries to various content servers without individually identifying itself and providing the device identifier associated with client device <NUM> to the content servers. While content servers that have collected data about client device <NUM> may be able to identify the device identifier that is associated with client device <NUM> based on the query token that client device <NUM> sends, these content servers already have the device identifier of client device <NUM> stored in a database. Content servers that determine that they do not have a matching query token in a database of the content servers may not be able to identify client device <NUM> from the query token because of the crypto techniques performed on the device identifier. For example, in sequence <NUM>, while the content server may be able to add the identifier "27D2C8BC4" to its database, because this identifier is calculated based on the periodic variable and device identifier that is unknown to the content server, it may not be able to calculate a subsequent identifier (e.g. for the next value of the periodic identifier). Thus, any attempt to gain information about client devices not previously known to the content server may, at best, be valid only for a short time. Consequently, these content servers may only be able to transmit a signal back to client device <NUM> indicating that there is not a matching query in a database without identifying any information (e.g., a device identifier) of the device that sent the query.

For example, referring now to <FIG>, an implementation of a system <NUM> for secure identification retrieval is shown, according to some implementations. System <NUM> is shown to include a client device <NUM>, a network <NUM>, and a content server <NUM>. Client device <NUM> can browse the Internet by visiting web pages and domains associated with different third parties. Client device <NUM> can browse the Internet via network <NUM>. Network <NUM> can include synchronous or asynchronous networks. As client device <NUM> browses the Internet, content servers (e.g., content server <NUM>) can collect and store data about client device <NUM>. The data may include one or more characteristics (geographic location, web pages visited, content of the visited web pages, IP address, etc.) of client device <NUM>. The content servers may identify the device identifier associated with client device <NUM> and store the device identifier in databases of the content servers. Client device <NUM> may send a request to (e.g., query) content server <NUM> for an identification of whether content server <NUM> has stored characteristics (e.g., data) about client device <NUM>.

Client device <NUM> may comprise any type and form of media device or computing device, including a desktop computer, laptop computer, portable computer, tablet computer, wearable computer, embedded computer, smart television, set top box, console, Internet of Things (IoT) device or smart appliance, or any other type and form of computing device. Client device(s) may be referred to variously as a client, device, client device, user device, computing device, anonymized computing device or any other such term. Client device(s) may receive data via any appropriate network, including local area networks (LANs), wide area networks (WANs) such as the Internet, satellite networks, cable networks, broadband networks, fiber optic networks, microwave networks, cellular networks, wireless networks, or any combination of these or other such networks. In many implementations, the networks may include a plurality of subnetworks which may be of the same or different types, and may include a plurality of additional devices (not illustrated), including gateways, modems, firewalls, routers, switches, etc..

Client device <NUM> may comprise one or more client devices configured to securely retrieve an identification from content servers (e.g., content server <NUM>) that indicates whether the content servers have collected data about client device <NUM>. Client device <NUM> is shown to include a processor <NUM> and memory <NUM>, in some implementations. One or more components within client device <NUM> can facilitate communication between each component within client device <NUM> and external components such as content server <NUM> and other content servers (not shown).

Processor <NUM> may comprise one or more processors configured to perform instructions on modules and/or components in memory <NUM> within client device <NUM>, in some implementations. Memory <NUM> is shown to include a variable retriever <NUM>, a query token calculator <NUM>, a browser <NUM>, and a decryptor <NUM>, in some implementations. Memory <NUM> may include any number of components. By executing the instructions on modules in memory <NUM> to perform the operations of each component <NUM>, <NUM>, <NUM>, and <NUM>, processor <NUM> can prevent content server <NUM> (or any other content server) from identifying client device <NUM> from a request made by client device <NUM> to determine if content server <NUM> has collected data about client device <NUM>.

In brief overview, processor <NUM> can calculate a query token that uniquely identifies client device <NUM> without providing a device identifier of client device <NUM> to content server <NUM> if content server <NUM> does not already have it (or providing a hashed identifier or token that may be valid for only a limited period of time, and from which other subsequent identifiers or tokens may not be calculated). Processor <NUM> can retrieve a value of a periodic variable that changes over time. Processor <NUM> can concatenate the value of the periodic variable with a device identifier of client device <NUM> to calculate a concatenated identifier, or may otherwise combine the periodic value and device identifier (e.g. multiply, bitwise XOR, etc., referred to generally as concatenated identifiers). Processor <NUM> can send the concatenated identifier to content server <NUM> in a query to determine if content server <NUM> has one or more characteristics about client device <NUM>. Processor <NUM> can receive an encrypted answer from content server <NUM>, encrypted with a public key of client device <NUM>, and decrypt the answer using a private key specific to client device <NUM>. In some implementations, the answer or response may not be encrypted (e.g., in some implementations in which negative responses or affirmative responses without additional data are utilized, or in which other security measures are utilized to prevent interception such as transport layer security).

Memory <NUM> is shown to include variable retriever <NUM>. Variable retriever <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to retrieve values of periodic variables, in some implementations. Variable retriever <NUM> may receive a request, in some cases from an administrator or user of client device <NUM>, to query various content servers <NUM> to determine which content servers have collected data about client device <NUM>. Upon receiving the request, variable retriever <NUM> may retrieve a value of a periodic variable.

Periodic variables may be variables with values that continually change over time and that are determined, in some cases by an administrator, such that two independent parties may independently retrieve the same values of the periodic variable when given the same information. The values may be strings including alphanumeric characters and/or symbols. For example, a periodic variable may be a current time in Chicago (e.g., <NUM>:00PM or <NUM>:<NUM>). If two parties in two different locations may retrieve the current time in Chicago at the same time, both parties would likely retrieve the same value. If the parties retrieved the current time in Chicago five minutes after the initial retrieval, the two parties would retrieve a different time from the time of the first retrieval, but the parties would retrieve the same time as each other. In this example, the time may be the value. Other examples of periodic variables include, but are not limited to, a present date in a specified time zone (e.g., <NUM>/<NUM>/<NUM>), a closing value of a stock on the New York Stock Exchange (e.g., $<NUM>), a nonce value that continually increments at a set frequency, etc. Accordingly, the periodic variable may comprise any information or combination of information that updates periodically and is independently determinable or retrievable both by client devices and content servers.

As described, the values of the periodic variable may be represented in any form and may include any type of characters or symbols. For example, a present value of a stock on the New York Stock Exchange may be represented by the strings $<NUM> or <NUM>, the present date may be represented by the strings <NUM>/<NUM>/<NUM> or <NUM>-<NUM>-<NUM>, and the present time may be represented by the strings <NUM>:00PM or <NUM>:<NUM>. The values may be represented in any form. An administrator may determine a type and form of values of the periodic variable.

Variable retriever <NUM> may retrieve values of the periodic variable by retrieving them from various databases of client device <NUM> or from various servers over network <NUM>, depending on the periodic variable. For example, if the periodic variable is the present date in Chicago, client device <NUM> may maintain an internal calendar based on the present date in Chicago and identify the present date from the internal calendar. In some instances, variable retriever <NUM> may identify the value of the periodic variable from servers across network <NUM>. In one example, variable retriever <NUM> may identify and retrieve a current value of a stock on the New York Stock Exchange from servers that store such data across network <NUM>. Variable retriever <NUM> may identify and retrieve values from any source.

Memory <NUM> is shown to include query token calculator <NUM>. Query token calculator <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to calculate query tokens and send them to content server <NUM>, in some implementations. Query tokens may be one-way hashes of device identifiers concatenated with values of the periodic variable. Query token calculator <NUM> may identify the value of the periodic variable that was retrieved by variable retriever <NUM> and a device identifier associated with client device <NUM>. Query token calculator <NUM> can concatenate the value of the periodic variable to the end or to the beginning of the device identifier to obtain a concatenated device identifier, or may perform other operations to combine the periodic variable and device identifier (e.g. multiplication, addition, subtraction, etc.). In some instances, query token calculator <NUM> can concatenate multiple instances of the value of the periodic variable to the device identifier.

Query token calculator <NUM> can perform a crypto technique on the concatenated device identifier to obtain a query token. The crypto technique can be a one-way crypto technique such as a one-way hash (e.g., SHA-<NUM>, SHA-<NUM>, SHA-<NUM>, MD5, etc.). Advantageously, by using a one-way crypto technique on the concatenated device identifier, query token calculator <NUM> may calculate a query token that cannot be deciphered by a second party or device (e.g., content server <NUM>) to recover the device identifier in plaintext (although if the second party or device knows what the device identifier is, what the value of the periodic variable is, and which crypto technique was used to calculate the query token, the second party or device may generate a token with a matching value, and may compare the generated token and query token to identify that the underlying data (e.g. device identifier and periodic variable value) match. Consequently, client device <NUM> may send the query token to any content server without providing any content servers with a device identifier of client device <NUM> if the content servers did not already have it.

When sending the query token to content server <NUM>, query token calculator <NUM> or any other component of client device <NUM> may digitally sign the message that the query token is contained in with a private key associated with client device <NUM>. As described below, if content server <NUM> has collected data about client device <NUM>, content server <NUM> may retrieve a public key associated with the device identifier of client device <NUM> and, based on the digital signature, verify that the message including the query token was received from the client device associated with the device identifier. If content server <NUM> determines that the message was not sent by client device <NUM> (e.g., if digital signature verification fails), content server <NUM> may not respond to the message and/or tear down any TCP/IP socket connection that content server <NUM> has with the computing device that sent the message.

Query token calculator <NUM> can send the calculated query token to content server <NUM> upon calculating the query token. In some implementations, query token calculator <NUM> may send the calculated query token to content server <NUM> after identifying content server <NUM> from a list of content servers that could have potentially collected data about query token calculator <NUM>. Query token calculator <NUM> can download the list of content servers from a server that stores the list across network <NUM>. Query token calculator <NUM> can identify each content server on the list of content servers and send the query tokens to each of or a portion of the identified content servers. Client device <NUM> may receive answers from each content server on the list and determine a number of content servers that have collected data about client device <NUM>.

Content server <NUM> may comprise one or more servers or processors configured for secure identification retrieval when determining whether content server <NUM> has collected data about various computing devices (e.g., client device <NUM>), in some implementations. Content server <NUM> is shown to include a processor <NUM> and memory <NUM>, in some implementations. In brief overview, through processor <NUM>, content server <NUM> can be configured to retrieve values for periodic variables, calculate stored query tokens that are associated with client devices for which content server <NUM> has collected data, receive a query token from a client device, compare the query token to stored query tokens in a database, identify a matching stored query token in the database, retrieve a device identifier associated with the matching stored query token from a second database, retrieve one or more characteristics of client device <NUM> based on the device identifier, and transmit the one or more characteristics to client device <NUM>. One or more components within content server <NUM> can facilitate communication between each component within content server <NUM> and external components such as client device <NUM>. Content server <NUM> can include multiple connected devices (e.g., as a server bank, a group of blade servers, or a multi-processor system), each device can provide portions of the necessary operations.

Processor <NUM> may comprise one or more processors configured to perform instructions on modules or components in memory <NUM> within content server <NUM>, in some implementations. In some implementations, processor <NUM> may execute modules within memory <NUM>. Memory <NUM> is shown to include a variable retriever <NUM>, a query token calculator <NUM>, a structure generator <NUM>, a query token matcher <NUM>, an encryptor <NUM>, a server application <NUM>, an identifier database <NUM>, and a characteristic database <NUM>, in some implementations.

Memory <NUM> is shown to include variable retriever <NUM>. Variable retriever <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to retrieve values of periodic values, in some implementations. Variable retriever <NUM> may retrieve values of periodic variables in a manner similar to how variable retriever <NUM> of client device <NUM> retrieves values of periodic variables. Variable retriever <NUM> may be in communication with client device <NUM> or receive an input from an administrator so variable retriever <NUM> retrieves values of periodic variables of the same type and/or from the same source as variable retriever <NUM> of client device <NUM>. For example, variable retriever <NUM> of client device <NUM> may be configured to retrieve values of periodic variables corresponding to the present date in Chicago. Variable retriever <NUM> of content server <NUM> may, as a result of communication with client device <NUM> or from an administrator input, also be configured to retrieve values of periodic variables corresponding to the present date in Chicago. Consequently, variable retriever <NUM> and variable retriever <NUM> may retrieve the same values of the periodic variable when conducting the processes described herein (e.g., variable retriever <NUM> and variable retriever <NUM> may be synchronized).

Variable retriever <NUM> may retrieve multiple values of periodic variables. For example, if the periodic variable is the present date in Chicago, variable retriever <NUM> may retrieve values of the present date in Chicago, a date of the previous day to the present date, and/or a date of the day after the present date, thus providing a sliding window of values of the periodic variable for which query tokens may be compared. In another example, if the periodic variable is the value of a stock on the New York Stock Exchange at close, the variable retriever <NUM> may retrieve values associated with the stock at close for one or more days before the present date and/or the present date. Variable retriever <NUM> may retrieve any number of values.

In some implementations, variable retriever <NUM> may retrieve values of periodic variables responsive to receiving a query token from client device <NUM>. Variable retriever <NUM> may receive the query token, identify the periodic variable (e.g., time of day in New York, date in New York, etc.), and retrieve the corresponding value of the periodic variable. Advantageously, by retrieving the periodic variable after receiving the query token, content server <NUM> may not have to continuously store values of encrypted device identifiers in a database, saving memory and storage space. However, in such implementations, the content server may need to generate sets of tokens for each device identifier in its database before processing the query token, which may require significant processing resources. In a similar implementation, the content server may iteratively generate a token for each identifier in its database using the value of the periodic variable retrieved after receiving the query token and compare each generated token to the received query token before proceeding to the next identifier, which may, on average, reduce processing time (e.g. if a match is identified after processing only a subset of the identifiers). In other implementations, as discussed below, a probabilistic data structure may be used to drastically reduce processing time for non-matching tokens.

Memory <NUM> is shown to include query token calculator <NUM>. Query token calculator <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to calculate query tokens for various device identifiers for which content server <NUM> has stored data. Query token calculator <NUM> may calculate query tokens for device identifiers in a similar manner to how client device <NUM> calculates query tokens. For each device identifier that is stored in a data structure of identifier database <NUM>, described below, query token calculator <NUM> may concatenate the retrieved value of the periodic variable to the end or beginning of the device identifier to obtain a concatenated stored device identifier. Query token calculator <NUM> may perform a crypto technique on the concatenated stored device identifier that corresponds to (e.g., is the same as) the crypto technique that client device <NUM> performs on the concatenated device identifier of client device <NUM> to calculate a stored query token. Query token calculator <NUM> may calculate stored query tokens associated with each of or a portion of the device identifiers in identifier database <NUM>.

In some implementations, query token calculator <NUM> may calculate multiple stored query tokens for each device identifier in identifier database <NUM>. For example, as shown in the table below, query token calculator <NUM> may calculate stored query tokens for a device identifier that corresponds to values of yesterday's date, today's date, and tomorrow's date.

In the table, ∥ denotes any method that concatenates strings (e.g., device identifiers and value of periodic variables) together and SHA<NUM> denotes an SHA-<NUM> hashing function. Any type of value or crypto technique may be used to calculate stored query tokens. The data of the table may be stored in identifier database <NUM>, as described below.

Memory <NUM> is also shown to include identifier database <NUM>, in some implementations. Identifier database <NUM> can be a dynamic database including device identifiers associated with computing devices for which content server <NUM> has collected data. Identifier database <NUM> can be a graph database, MySQL, Oracle, Microsoft SQL, PostgreSql, DB2, document store, search engine, key-value store, etc. Identifier database <NUM> can be configured to hold any amount of data and can be made up of any number of components. The device identifiers may be associated with stored query tokens that are calculated by query token calculator <NUM>. The device identifiers may be associated with the stored query tokens in a look-up table (e.g., a hash table) that matches the device identifiers to stored query tokens calculated by query token calculator <NUM>. Each device identifier may be matched with multiple stored query tokens that were calculated based on different values of periodic variables. In some implementations, the device identifiers and the corresponding stored query tokens may be associated with a probabilistic data structure of identifier database <NUM>.

In some implementations, stored query tokens of identifier database <NUM> may be periodically added and/or removed from identifier database <NUM> at fixed or variable rates by content server <NUM>. For example, one day, query token calculator <NUM> may calculate query tokens for each device identifier in identifier database <NUM> based on values of today's date, yesterday's date, and tomorrow's date. On a second day, query token calculator <NUM> may remove the stored query tokens that correspond to the date two days before the date of the second day from identifier database <NUM>. Query token calculator <NUM> may also add query tokens corresponding to the date of the date after the second day to identifier database <NUM>. Consequently, the number of stored query tokens in identifier database <NUM> may be controlled to require a fixed amount of memory of identifier database <NUM> and/or reduce the amount of memory required to store the stored query tokens.

Memory <NUM> is shown to include structure generator <NUM>. Structure generator <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to generate the data structure of identifier database <NUM> that is associated with the stored query tokens that were calculated by query token calculator <NUM>. The data structure may be a probabilistic data structure (e.g., a Bloom filter, HyperLogLog, Count-Min sketch, etc.). In the case of a Bloom filter, structure generator <NUM> may generate the probabilistic data structure so the data structure can indicate that a stored query token may be associated with the probabilistic data structure or that the stored query token is definitely not associated with the probabilistic data structure.

Structure generator <NUM> may generate the probabilistic data structure as an array associated with the stored query tokens. Query token calculator <NUM> may calculate binary arrays (e.g., arrays of a binary value) for each stored query token and add the binary arrays to the array of the probabilistic data structure. For example, structure generator <NUM> may calculate a binary array for a stored query token with a value of <NUM> to be [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>]. Structure generator <NUM> may add the binary array to the probabilistic data structure by performing an OR operation between the probabilistic data structure and the binary array of the stored query token. Structure generator <NUM> may add binary arrays of each stored query token in identifier database <NUM> to the probabilistic data structure. In some implementations, query token calculator <NUM> may have already calculated and/or stored the stored query tokens as binary arrays.

In some implementations, structure generator <NUM> may generate the probabilistic data structure by performing various hash functions on the stored query tokens and setting indices that correspond to outputs of the hash functions to one. Indices that do not correspond to the outputs may remain at zero.

When a query is made to determine whether a matching stored query token is in identifier database <NUM>, query token matcher <NUM>, described below, may calculate a binary array for the query token that query token matcher <NUM> received from client device <NUM>. Query token matcher <NUM> may calculate the binary array by converting the string of the query token to binary (if the string is not already in binary) or performing various hash functions on the query token and setting the indices of the array that correspond to the output of the hash functions to one while the rest of the indices remain zero, depending on how structure generator <NUM> is configured to generate the probabilistic data structure. If query token matcher <NUM> calculates the binary array using hash functions, query token matcher <NUM> may use the same hash functions that structure generator <NUM> used to generate the probabilistic data structure to generate the binary array of the query token. Query token matcher <NUM> may compare the index values of the binary array with the array of the probabilistic data structure. Query token matcher <NUM> can compare the "<NUM>" values of the indices of the binary array of the query token with the corresponding indices of the probabilistic data structure (e.g., perform a bitwise AND operation between the query token and the probabilistic data structure). If each index value of the comparison is a one, a matching query token may be in identifier database <NUM> (allowing for false positives). If one index value of the comparison is a zero, however, a matching query token is not in identifier database <NUM>. Such probabilistic data structures or filters may not result in false negatives, allowing a quick verification of whether a match exists before engaging in a more intensive token-by-token comparison.

In some implementations, structure generator <NUM> may update the probabilistic data structure by generating a new data structure at each instance that data is removed from identifier database <NUM>. Structure generator <NUM> may perform the techniques described above to generate the new data structure. For example, if query token calculator <NUM> calculates stored query tokens for values of periodic variables corresponding to today's date, yesterday's date, and tomorrow's date each day, identifier database <NUM> may, upon determining it is a new day based on an internal calendar and clock, be configured to remove stored query tokens that correspond to the date of the day before yesterday's date and add new stored query tokens based on tomorrow's date to identifier database <NUM>. Structure generator <NUM> may generate a new data structure each day that corresponds to the updated data in identifier database <NUM>.

In some implementations, instead of generating a new data structure each day, structure generator <NUM> may generate a counting filter. Counting filters may be similar to bloom filters but instead of each index having a value of one or a zero, the counting filters may increment a counter for each index value that corresponds to the number of stored query tokens with a one value at the index. For example, if three stored query tokens have a one value at the same index, the index of the probabilistic data structure may have a value of three. As data structure generator <NUM> removes and/or adds stored query tokens to the counting filter, the value of the index may be reduced or increment, respectively. When query token matcher <NUM> compares the query token to the counting filter, query token matcher <NUM> can determine if each index value is non-zero or zero instead of one or zero to determine if the query token has a matching query token in identifier database <NUM>.

Memory <NUM> is shown to include query token matcher <NUM>. Query token matcher <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to determine whether there is a matching stored query token in identifier database <NUM>. Query token matcher <NUM> may compare query tokens that content server <NUM> receives from client device <NUM> to the data structure of identifier database <NUM> and/or stored query tokens of identifier database <NUM>. If query token matcher <NUM> determines that there is a matching stored query token in identifier database <NUM>, query token matcher <NUM> may identify the matching stored query token. Query token matcher <NUM> may identify the matching stored query token from a look-up table of identifier database <NUM> that stores stored query tokens and corresponding device identifiers.

Query token matcher <NUM> may determine that there is a matching query token by comparing the query token that content server <NUM> receives from client device <NUM> to the probabilistic data structure. Query token matcher <NUM> can identify the query token that content server <NUM> received from client device <NUM> and compare it to the bloom filter associated with the data structure of identifier database <NUM> as described above. Query token matcher <NUM> may determine a binary value (e.g., yes or no) indicating whether the query token has a matching stored query token in identifier database <NUM>. Query token matcher <NUM> may receive a true answer if there may be a matching stored query token and a false answer if there is not a matching stored query token. If query token matcher <NUM> receives a false answer, encryptor <NUM> may transmit a signal to client device <NUM> indicating that there was not a match. If query token matcher <NUM> receives a true answer, encryptor <NUM> may transmit a signal to client device <NUM> indicating that there was a match.

In some implementations, if query token matcher <NUM> determines that there was a match based on the comparison with the probabilistic data structure, query token matcher <NUM> may compare the query token to the stored query tokens of a look-up table in identifier database <NUM>. Advantageously, by comparing the query token to the look-up table in identifier database <NUM>, query token matcher <NUM> may eliminate or reduce the possibility of false positives that could be generated based on the comparison with the probabilistic data structure. In some implementations, query token matcher <NUM> may initially compare the query token to the look-up table without comparing the query token to the probabilistic data structure. Query token matcher <NUM> may determine that there is a matching query token in identifier database <NUM> if query token matcher <NUM> identifies a stored query token with the same hash value (e.g., string) as the query token that content server <NUM> received from client device <NUM>. Query token matcher <NUM> may determine that there is not a matching query token if query token matcher <NUM> does not identify a stored query token with a matching hash value.

Memory <NUM> is shown to include encryptor <NUM>. Encryptor <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to encrypt the answer that content server <NUM> transmits to client device <NUM> in response to queries from client device <NUM>. In cases where query token matcher <NUM> does not identify a matching stored query token in identifier database <NUM>, encryptor <NUM> may transmit, to client device <NUM>, a random string or a null data string. In one example, the random string may include multiple instances of a time stamp. Consequently, when client device <NUM> receives the random string or null data string, client device <NUM> may attempt to decrypt it and determine that it is random. Based on the determination that the string is random, client device may determine that content server <NUM> may not have stored information about client device <NUM>. Advantageously, by including multiple instances of a time stamp, entropy of the encryption may be increased, making it more difficult for third parties to decrypt the signal from content server <NUM> to client device <NUM>. Content servers or other third parties that intercept the answer from content server <NUM> may not be able to decrypt or know the meaning of the random string or null data string.

However, if query token matcher <NUM> determines that there is a matching query token in identifier database <NUM>, encryptor <NUM> may identify a device identifier associated with the matching query token and compare the device identifier to a look-up table in characteristic database <NUM>. Each of or a portion of the device identifiers in identifier database <NUM> may be associated with a public key. The public keys may be stored in characteristic database <NUM> and associated with the device identifiers. Encryptor <NUM> may compare the device identifier to the table of characteristic database <NUM> and retrieve the public key that is associated with the device identifier. Encryptor <NUM> may encrypt answers that encryptor <NUM> sends back to client device <NUM> with the public key. The encrypted answer may include an identification indicating that content server <NUM> has collected data about client device <NUM> and/or one or more characteristics including information and categories of information that content server <NUM> has stored about client device <NUM>. Encryptor <NUM> may transmit the encrypted answer to client device <NUM>. Decryptor <NUM> of client device <NUM> can decrypt the encrypted answer as described below.

In some implementations, encryptor <NUM> may further encrypt the answer that is sent to client device <NUM> using nonce values and a time stamp. Encryptor <NUM> may use the following equation to encrypt the answer:<MAT>) As described above, ∥ depicts concatenating values of separate strings into one string. Answerplaintext may be the answer that encryptor <NUM> encrypts, and may include identifiers of information stored about client device <NUM>. Encryptor <NUM> may retrieve a value of the nonce through the use of counter that is constantly incrementing (e.g., incrementing corresponding to time, messages sent between server <NUM> and client device <NUM>, etc.). The nonce may be synchronized between content server <NUM> and client device <NUM> so client device <NUM> will know the nonce that encryptor <NUM> used to encrypt the answer. In some implementations, all or a portion of the nonce may be sent to client device <NUM> with the answer so client device <NUM> can identify the nonce and decrypt the answer, or may be received from client device <NUM> as part of the query. Encryptor <NUM> may generate the time stamp by retrieving the time from an internal clock of server <NUM>. Each of the nonce and the timestamp may be concatenated with the answer in any order and any number of times.

Memory <NUM> is also shown to include characteristic database <NUM>, in some implementations. Characteristic database <NUM> can be a dynamic database including device identifiers, public keys associated with the device identifiers, and one or more characteristics of the computing devices that are associated with the device identifiers. The private keys that correspond to the public keys may be confidentially stored on the devices that are associated with the device identifiers or other devices of the same user. Characteristic database <NUM> can be a graph database, MySQL, Oracle, Microsoft SQL, PostgreSql, DB2, document store, search engine, key-value store, etc. Characteristic database <NUM> can be configured to hold any amount of data and can be made up of any number of components. The device identifiers may be associated with stored query tokens that are calculated by query token calculator <NUM>. The device identifiers may be associated with corresponding device identifiers of identifier database <NUM>. Each of or a portion of the device identifiers of characteristic database <NUM> may be associated with a public key and/or one or more characteristics. The public key and/or one or more characteristics may be stored in a look-up table matching them to corresponding device identifiers. The one or more characteristics may include one or more of the geographic location, web pages visited, content of the visited web pages, etc., of the client devices associated with the device identifiers. The one or more characteristics may include any characteristic of the client devices or the user who interacts with the client devices or inferred characteristics of the client devices or the users.

Encryptor <NUM> may compare the identified client device identifier to characteristic database <NUM> to identify and retrieve both the public key associated with the identified device identifier of client device <NUM> and data of the one or more characteristics of client device <NUM>. Using the public key, encryptor <NUM> may encrypt a signal including the one or more characteristics in an answer and transmit the encrypted signal to client device <NUM>.

Referring still to <FIG>, memory <NUM> of client device <NUM> is shown to include decryptor <NUM>. Decryptor <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to receive and decrypt the encrypted signal from content server <NUM>. Decryptor <NUM> may access a private key specific to client device <NUM> from a database (not shown) of client device <NUM>. Decryptor <NUM> may decrypt the encrypted signal using the private key to process the answer in the encrypted signal to determine if content server <NUM> has collected data about client device <NUM>. Further, decryptor <NUM> can determine a category of data that content server <NUM> has collected if content server <NUM> sends a signal indicating that it has collected data about client device <NUM>.

In some implementations, client device <NUM> may send query tokens to multiple content servers to determine a number of content servers that have collected data about client device <NUM> and categories of any data that each content server has collected. Decryptor <NUM> may increment and maintain a counter for each content server that transmits a signal to client device <NUM> indicating that an identifier of client device <NUM> is in a database of the content server. In some implementations, decryptor <NUM> may also increment and maintain counters associated with each category of data for the number of content servers that have data for client device <NUM> associated with each category. Through the category counters, client device <NUM> may determine counts for the number of content servers that have data associated with each category.

In another implementation, system <NUM> can be implemented so browsers of client devices can determine which content servers have data associated with the browsers. The content servers may have collected data associated with the browsers when the browsers visit domains associated with the content servers. In some instances, multiple content servers may be associated with a single domain. In some instances, a single content server may be associated with multiple domains. The content servers may collect data from browsers using cookies (e.g., third party cookies). The cookies may be device identifiers of computing devices as values of the cookies may be specific to the computing devices. The cookies may also be associated with various domains. In some instances, multiple content servers may have access to the same information that is provided by a cookie of a browser. In such instances, each content server may obtain the same or a portion of the same information from the cookie. For example, a cookie (and a value of the cookie) stored on a browser of a computing device may be associated with a first domain and a second domain. One content server may be associated with the first domain and another content server may be associated with the second domain. Consequently, while the two content servers may be associated with different domains, each content server may receive data for the browser of the computing device from the cookie.

System <NUM> provides a method of determining which content servers have collected data about browsers using the cookie. For example, client device <NUM> is shown to include browser <NUM>. Browser <NUM> may comprise an application, server, service, daemon, routine, or other executable logic to generate cookie query tokens to send to content server <NUM> to determine if the content server has collected data about browser <NUM>. Browser <NUM> can perform operations similar to the operations performed by variable retriever <NUM> and/or query token calculator <NUM> to query content servers to determine which content servers (e.g., content server <NUM>) have collected data about browser <NUM> and any categories the data may fall under. Although referred to as a browser, browser <NUM> may comprise any type and form of application for communicating with content servers, including as part of a productivity application, media application, game application, web browser application, or other such application.

Browser <NUM> can generate a browser query token to send to various applications of content servers (e.g., content server <NUM>) to determine which content servers have collected data about browser <NUM>. Browser <NUM> can retrieve a value of a periodic variable (e.g., a time of day in Chicago, a date in Chicago, value of a stock on the New York Stock Exchange at close, etc.) from various servers across network <NUM> or from an internal database of client device <NUM>. Browser <NUM> may also retrieve and/or identify, from files stored on client device <NUM>, a value of a cookie (e.g., a cookie value) that is associated with a domain associated with the content server that browser <NUM> is querying and that may be specific to browser <NUM>. Browser <NUM> may further retrieve a domain identifier (e.g., www. com) of the domain. Browser <NUM> may concatenate the retrieved values to obtain a concatenated cookie identifier and perform a crypto technique such as SHA-<NUM> to encrypt the concatenated cookie identifier into a cookie query token. An example equation of this process is reproduced below:<MAT> In the example, today's date is the value of a periodic variable that corresponds to the present date. Browser <NUM> may calculate and send the browser query token to the content server associated with the domain to determine if content server <NUM> and any other servers associated with the same domain and/or cookie have collected data about browser <NUM>.

Content server <NUM> is shown to include server application <NUM>. Server application <NUM> may comprise an application, server, FTP server, HTTP server, service, daemon, routine, or other executable logic to receive cookie query tokens from client devices (e.g., client device <NUM>) and determine if server application <NUM> has collected data associated with browsers (e.g., browser <NUM>) of the client devices. Server application <NUM> may calculate stored cookie query tokens for each of or a portion of the browsers from which server application <NUM> has collected data. Server application <NUM> may calculate the stored cookie query tokens by retrieving values of periodic variables in a manner similar to how browser <NUM> of client device <NUM> retrieves values of periodic variables. Server application <NUM> may retrieve the value of the periodic variable based on the same information (e.g., the same variable) and/or data source as browser <NUM> so the value that server application <NUM> retrieves may match the values that browser <NUM> retrieves. Server application <NUM> may retrieve the value at periodic intervals to calculate stored cookie query tokens. For example, both server application <NUM> and browser <NUM> may be configured to retrieve values associated with today's date (e.g., <NUM>-<NUM>-<NUM>). Server application <NUM> may retrieve the value of today's date from an internal calendar of content server <NUM> while browser <NUM> may retrieve the value of today's date from an internal calendar of client device <NUM>. Because the calendars of client device <NUM> and content server <NUM> may be synchronized, both server application <NUM> and client device <NUM> may retrieve the same value. Further, client device <NUM> and content server <NUM> may retrieve the same value in the same form.

In some implementations, server application <NUM> may retrieve multiple values of periodic variables to calculate multiple stored cookie query tokens. For example, if the periodic variable is associated with today's date, server application <NUM> may retrieve values of today's date for the present date, tomorrow's date, and yesterday's date. Server application <NUM> may retrieve any number of values associated with any periodic variables.

Server application <NUM> may calculate stored cookie query tokens for each cookie associated with a domain associated with server application <NUM>. Server application <NUM> may calculate the stored cookie query tokens by concatenating the cookie value with the domain (e.g., a domain identifier) and the retrieved value of the periodic variable. Continuing with the example above, server application <NUM> may concatenate a cookie value of browser <NUM> with a value of the domain (e.g., the name of the domain associated with the cookie) and today's date. Server application <NUM> may perform a crypto technique that matches the crypto technique performed by browser <NUM> to calculate a stored cookie query token. In some cases, cookie values of a domain may be shared among multiple content servers (e.g., in a cookie consortium), each of which has its own domain. In such cases, the stored cookie query token may be associated with (e.g., tagged with) the value of the domain that dropped or created the cookie previously, (e.g., owns the cookie). If cookie value of the domain is not shared with any content servers but content server <NUM> for the domain, the stored cookie query token may not be associated with the value of the domain.

In some implementations, server application <NUM> may calculate multiple stored cookie query tokens for each cookie associated with various browsers. For example, as illustrated in the look-up table below, server application <NUM> may calculate stored cookie query tokens for each cookie associated with values of periodic variables for yesterday's date, today's date, and tomorrow's date.

The look-up table exemplifies look-up tables that server application <NUM> may have stored for cookies that are associated with various browsers. Server application <NUM> may store the calculated stored cookie query tokens in identifier database <NUM>. Server application <NUM> may store any number of stored cookie query tokens for any number of cookies in the database. In some implementations, for each day that passes, server application <NUM> may remove the stored cookie query token associated with the value of yesterday's date and calculate a new stored cookie query token associated with a value of tomorrow's date.

In some implementations, the stored cookie query tokens may be associated with a probabilistic data structure (e.g., a Bloom filter) similar to the probabilistic data structure discussed above. Server application <NUM> may compare the cookie query token that server application <NUM> received from browser <NUM> to the probabilistic data structure to determine whether there is a matching stored cookie query token in identifier database <NUM>. Server application <NUM> may compare the cookie query token to the probabilistic data structure and determine a binary yes or no answer as to whether there is a matching cookie query token in the database. The yes answer may correspond to a high probability that there is a matching stored cookie query token in identifier database <NUM> while the no answer may correspond to there not being a matching cookie query token in identifier database <NUM>.

Server application <NUM> may receive the cookie query token from client device <NUM> via browser <NUM> and determine whether the cookie query token matches any stored cookie query tokens stored in the database. Server application <NUM> may compare the cookie query token to the stored cookie query tokens of the look-up tables in identifier database <NUM> to determine if there is a matching stored cookie query token in identifier database <NUM>. If there is a matching stored cookie query token, that may indicate that server application <NUM> has collected data about browser <NUM> through the cookie associated with browser <NUM>. In such a case, server application <NUM> may confirm that there is a matching cookie query token and identify the value and/or domain of the cookie associated with the matching cookie query token by comparing the cookie query token with the stored cookie query tokens of the look-up tables of identifier database <NUM>.

If server application <NUM> confirms that there is a matching cookie query token, server application <NUM> can identify the value of the cookie that is associated with the matching cookie query token from the look-up table. Server application <NUM> can compare the value of the cookie to a second database (e.g., characteristic database <NUM>) to identify one or more characteristics for which server application <NUM> has collected and stored data associated with browser <NUM>. The one or more characteristics may be stored in a look-up table within characteristic database <NUM> and organized into different categories of data that server application <NUM> has collected about browser <NUM>. For example, server application <NUM> may have collected data associated with browser <NUM> indicating the behavior of browser <NUM> on news' websites, on entertainment websites, on advertisers' websites, etc. Server application <NUM> may transmit a signal back to browser <NUM> including a Boolean response indicating whether server application <NUM> has collected data about client device <NUM> and/or a list of categories (e.g., one or more characteristics) of data that server application <NUM> has collected.

To ensure that malicious parties do not intercept and/or ascertain any information from server application <NUM> in the signal that server application <NUM> sends to browser <NUM>, server application <NUM> may encrypt the signal using various techniques. Server application <NUM> may pad the response to a fixed length so malicious parties may not be able to determine an amount of data that server application <NUM> may have collected. Further, server application <NUM> may protect the signal using HTTPS protocols. Server application <NUM> may encrypt the signal with a symmetric key algorithm (e.g., AES) using the cookie value and domain from the look-up table described above as the encryption key. Server application <NUM> may also include a timestamp in the response before applying a symmetric key encryption technique.

Referring now to <FIG>, a flow chart of a method <NUM> for secure identification retrieval is shown, according to some implementations. Method <NUM> can include any number of operations. The operations can be performed in any order. Method <NUM> can be performed by a server device (e.g., content server <NUM>). At an operation <NUM>, the server device can retrieve a value of a periodic variable. The periodic variable can be a variable with values that continually change at set or varying frequencies. For example, the periodic variable may be a present date, a present time of day, stock prices of various stocks on the New York Stock Exchange at close, nonce values determined based on an incrementing counter, etc. Depending on the periodic variable, the server device may store the values in a database within the server device or retrieve the value from another source (e.g., a database that stores values of stock prices on the New York Stock Exchange).

At an operation <NUM>, the server device can calculate a plurality of query tokens. The server device can calculate the plurality of query tokens by identifying the value of the periodic variable and concatenating the value to the end of any client device identification numbers that the server device has information stored for to obtain a concatenated identifier for each client device. The server device can perform a crypto technique such as a one-way hash on the concatenated identifier associated with each client device to obtain the plurality of query tokens. In some implementations, the server device can calculate a second plurality of query tokens. The second plurality of query tokens can include query tokens associated with the same client devices as the plurality of query tokens but based on different periodic variable values.

At an operation <NUM>, the server device can generate a probabilistic data structure that may be associated with each of the plurality of query tokens. The plurality of query tokens may be stored in a database of the server device. The server device may add and/or remove query tokens from the database at any time including at set intervals. The probabilistic data structure may be a Bloom filter that indicates whether a query token may be in the database to a degree of certainty or is definitely not in the database, in some implementations.

At an operation <NUM>, the server device can receive a first query token from a client device. The client device may generate the first query token using the same or similar techniques that the server device uses to calculate each of the plurality of query tokens. The first query token may be associated with a device identifier of the client device. The client device may calculate the first query token by retrieving a value of a periodic variable and concatenate the value with the device identifier to obtain a concatenated device identifier. The client device may calculate the first query token from the concatenated device identifier by using a crypto technique on the concatenated device identifier to obtain the first query token. The crypto technique may be the same crypto technique that the server device performs to obtain each of the plurality of query tokens. The client device may send the first query token to the server device in a query to determine if the server device has information about the client device. In some implementations, before sending the query, the client device may sign the query with a private key.

At an operation <NUM>, the server device can determine whether the server device has a matching query token to the first query token in a database of the server device. The server device can compare the first query token to the data structure of the database. If the server device does not identify a query token in the data structure that matches (e.g., has the same string of characters) the first query token, the server device may determine that there is not a matching query token of the querying client device in the database. Consequently, at an operation <NUM>, the server device may transmit a signal to the client device indicating that no match was found.

However, if the server device identifies a query token in the data structure that matches the first query token, the server device may determine that there is a matching query token to the query token of the querying client device in the database. Consequently, at an operation <NUM>, the server device may identify the second query token. From the second query token, the server device may identify the device identifier of the client device making a request.

At an operation <NUM>, the server device may retrieve one or more characteristics of the client device from a second database storing characteristics of the client devices. The one or more characteristics may be data about the device that the server device has collected (e.g., geographic location, web pages visited, content of the visited web pages, etc.). The server device may compare the device identifier of the client device to a data structure of the second database to obtain a public encryption key of the client device. The server device may use the public key to verify that the query was received from the client device associated with the device identifier based on the digital signature.

At an operation <NUM>, the server device may use the public key to encrypt the one or more characteristics in an answer to the query from the client device. The encrypted answer may include a concatenated value that the server device calculates by concatenating the answer, a nonce, and a time stamp together. The answer may include binary values (e.g., whether the server device has collected data for the client device) and/or an identification of different categories of user data (e.g., one or more characteristics) that the server device has collected about the client device. At an operation <NUM>, the server device may transmit the one or more characteristics to the client device. The client device may decrypt the encrypted answer using the private key of the client device based on the digital signature.

Advantageously, by calculating query tokens associated with device identifiers of computing devices making requests for identifications from content servers, computing devices may remain anonymous from content servers that do not already have data about them when devices query the content servers. The systems and methods provided herein allow devices to query content servers to determine if the content servers have information about the querying devices by sending queries to the content servers without sending device identifiers of the devices. Instead, the devices may calculate query tokens using a crypto technique (e.g., a one-way crypto technique) and send the query tokens to the content servers. The query tokens may include temporary encrypted values (e.g., a time stamp or a present date), so content servers cannot identify anything about the querying devices based on the query tokens. Content servers may know the crypto technique that is used to generate the query tokens and similarly calculate corresponding stored query tokens for device identifiers that the content servers have stored. Consequently, because the query tokens may be calculated using one-way crypto techniques, content servers can only identify whether they have data about querying devices without being able to identify device identifiers of the querying devices if the device identifiers are not already known. Further, communications between the devices and the content servers may be encrypted so malicious parties may not be able to identify data about the content servers.

In situations in which the systems described herein collect personal information about users or applications installed on a user device, or make use of personal information, the users may be provided with an opportunity to control whether programs or features collect user information (e.g., information about a user's social network, social actions, or activities, profession, a user's preferences, or a user's current location). In addition, certain data may be treated in one or more ways before it is stored or used, so that personal information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about the user and used by a content server.

Implementations of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on one or more computer storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can also be, or be included in, one or more separate components or media (e.g., multiple CDs, disks, or other storage devices). Accordingly, the computer storage medium may be tangible.

The term "client or "server" include all kinds of apparatus, devices, and machines for processing data, such as a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing.

Processors suitable for the execution of a computer program include both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), LCD (liquid crystal display), OLED (organic light emitting diode), TFT (thin-film transistor), plasma, other flexible configuration, or any other monitor for displaying information to the user and a keyboard, a pointing device, e.g., a mouse, trackball, etc., or a touch screen, touch pad, etc., by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; by sending web pages to a web browser on a user's computing device in response to requests received from the web browser.

Communication networks may include a local area network ("LAN") and a wide area network ("WAN"), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations of particular inventions.

Claim 1:
A method for secure identification retrieval, comprising:
retrieving (<NUM>), by a server device, a value of a periodic variable;
calculating (<NUM>), by the server device, a plurality of query tokens from a corresponding plurality of client device identifiers and the value of the periodic variable, each query token associated with a corresponding client device identifier in a first database;
receiving (<NUM>), by the server device from a first client device, a first query token calculated from a client device identifier of the first client device and the value of the periodic variable;
identifying (<NUM>), by the server device, a second query token of the calculated plurality of query tokens in the first database matching the first query token;
responsive to the identification, retrieving, by the server device, from the first database, the associated client device identifier;
retrieving (<NUM>), by the server device from a second database, one or more characteristics of the first client device according to the associated client device identifier;
transmitting (<NUM>), by the server device to the first client device, the retrieved one or more characteristics;
receiving, by the server device from a second client device, a third query token calculated from a client device identifier of the second client device and the value of the periodic variable;
determining, by the server device, that an entry does not exist in the first database corresponding to the third query token; and
responsive to the determination that an entry does not exist in the first database corresponding to the third query token, transmitting, by the server device to the second client device, one of a random data string or a null data string.