Generating a sequence of network data while preventing acquisition or manipulation of time data

Abstract

Methods, systems, and apparatus, including methods for determining network measurements. In some aspects, a method includes receiving, by a first aggregation server, encrypted impression data from each of a plurality of client devices. The first aggregation server and a second aggregation server cooperate to perform secure multi-party computation using a secure multi-party computation protocol to generate an in-time-ordered sequence of encrypted impression data and encrypted conversion data stored by the second aggregation server, and to decrypt the encrypted impression data and the encrypted conversion data.

Description

[0001] This case is a divisional application of the invention patent application filed on December 14, 2020, with application number 202080056658.8 and invention title "Generating a sequence of network data while preventing the acquisition or manipulation of time data". Background Technology

[0002] Client devices transmit data over public networks, such as the Internet. These communications can be intercepted and / or altered by entities that are not intended to receive them. Furthermore, entities can forge network identifiers and send data that appears to originate from these forged identifiers. An example of such forgery is the Sybil attack, in which an entity creates network identifiers to compromise the reputation system of a peer-to-peer network. Summary of the Invention

[0003] This specification describes techniques related to determining network measurements in a way that prevents fraud and protects user privacy.

[0004] In general, one innovative aspect of the subject matter described in this specification can be embodied in some methods, including: receiving impression data from each of a plurality of client devices by a first aggregation server, wherein, for each impression of a digital component recorded by a client device, the impression data includes: (i) a first join key, which is based on a first unique identifier used by the client device or an application on the client device where the impression occurs. (ii) encrypted display data, which has been encrypted using a first public key of a first aggregation server and a second public key of a second aggregation server different from the first aggregation server, and (iii) encrypted display time data indicating the time when the display occurred; the second aggregation server receives conversion data from each of at least a portion of a plurality of client devices, wherein, for each conversion recorded by a client device, the conversion data includes: (i) a second connection key based on a second unique identifier used for the client device or an application on the client device where the conversion occurred, and (ii) a second value including encrypted conversion data encrypted using the first encryption key and the second encryption key, and (iii) encrypted conversion time data indicating the time when the conversion occurred; the first aggregation server and the second aggregation server perform a multi-party computation process to generate a chronological sequence of encrypted display data and encrypted conversion data. The method involves: identifying groups of encrypted conversion data and corresponding encrypted display data based on a first key and a second key; and, for each chronological sequence, sorting the encrypted conversion data and corresponding encrypted display data based on encrypted display time data and encrypted conversion time data; and, using a first private key corresponding to a first public key and a second private key corresponding to a second public key, decrypting the display data and conversion data for each sequence of encrypted display data and encrypted conversion data in multiple stages. Other embodiments of this aspect include corresponding apparatuses, systems, and computer programs configured to perform aspects of a method encoded on a computer storage device. Advantageously, this provides a method / means that attributes conversion data to display data while maintaining user privacy, thereby providing a more secure system / method. As described herein, conversion data corresponds to user interaction with digital components, while display data corresponds to providing digital components to the user.Therefore, coordinating display data and conversion data by attributing conversions to corresponding displays is beneficial for monitoring the interaction between digital components provided to users and users. Providing a secure system that maintains user privacy when monitoring such interactions is generally important, preventing the identification or tracking of users based on conversion or display data. The disclosed techniques provide the technical effect of maintaining user privacy when coordinating display and conversion data, and also provide the technical effect of preventing fraudulent activities when coordinating display and conversion data. Specifically, the encryption techniques detailed above prevent third parties from intercepting sensitive display or conversion data that could potentially lead to the user. Furthermore, these encryption techniques also prevent all entities involved in the above methods (e.g., by matching display and conversion data for a specific user) from learning information about the user, thereby preventing the tracking of users based on display or conversion data. For example, as detailed above, the display and conversion data have been double-encrypted using a first public key of a first aggregation server and a second public key of a second aggregation server. This specific feature is used to improve security and protect user privacy because encrypting the display and conversion data requires decryption by both aggregation servers (i.e., using their respective private keys). In this way, a single server (or interceptor) cannot obtain plaintext displayed or transformed data, thereby improving security. Therefore, the disclosed technology solves the technical problem of providing a secure system for monitoring user interactions with digital components that maintains user privacy.

[0005] Preventing fraud (e.g., simulating fake user interactions with digital components) is often crucial when monitoring user interactions with digital components and when coordinating the presentation and transformation of data. Using multiple aggregation servers to form multi-party computation (MPC) allows each server to check for signs of fraudulent activity on another server (e.g., whether one of the servers has been compromised or is colluding with other entities), and prevents fraud during measurement. Therefore, further technical benefits are achieved by using the disclosed techniques for preventing fraudulent activities while simultaneously protecting user privacy when coordinating the presentation and transformation of data.

[0006] Furthermore, the disclosed technology enables greater flexibility in user interaction with digital components. Specifically, the use of a connection key based on a unique identifier of the client device or application, as detailed above, makes it possible to monitor user interactions on the same platform or across platforms (i.e., displays and transitions occurring via the same or different web browsers or other applications on the user's device).

[0007] Furthermore, the features of generating chronologically ordered sequences by identifying groups of encrypted transformation data and corresponding encrypted display data, and (for each chronologically ordered sequence) sorting the encrypted transformation data and corresponding encrypted display data based on encrypted display time data and encrypted transformation time data, enable improved accuracy in attributing transformations to corresponding displays. This is because transformations are attributed to displays based on the corresponding time data used for transformation and display, which means that user interactions with digital components can be monitored more accurately.

[0008] These and other implementations may each optionally include one or more of the following features. In some aspects, the encrypted display time data is encrypted using a first public key and a second public key. The encrypted display time data may include an encrypted version of the sum of the time the display occurred and the clock offset of the client device where the display occurred. The sum of the time the display occurred and the clock offset of the client device where the display occurred may be encrypted using homomorphic additive probabilistic public key encryption.

[0009] In some respects, the encrypted conversion time data is encrypted using a first public key and a second public key. The encrypted conversion time data includes an encrypted version of the sum of the time the conversion occurred and the clock offset of the client device on which the conversion occurred. The sum of the time the conversion occurred and the clock offset of the client device on which the conversion occurred can be encrypted using homomorphic additive probabilistic public key encryption. Similar to the secondary encryption of the display and / or conversion dates, secondary encryption of the display time data and / or conversion time data is advantageous because it improves security. Secondary encryption of the time data requires the private keys of both aggregation servers to decrypt. In this way, a single server (or interceptor) cannot obtain the plaintext time data, reducing the risk of time interval-based attacks and thus improving security. Using clock offsets in the encrypted display time data and / or conversion time data is particularly useful for distinguishing between same-device conversions and cross-device conversions. As described herein, if the conversion and display occur on the same device, the clock offset for each conversion and display is the same, but is unknown to the aggregation server due to encryption. If the conversion and display occur on different devices, the clock offset for each device is different. In either case, encryption of the sum of the time of the presentation / conversion and the clock offset of the client device where the presentation / conversion occurs provides a technical effect that improves security, as these features make it more difficult to launch time-interval-based attacks to obtain user information or to commit fraud.

[0010] Some aspects may include: for each chronological sequence of encrypted display data and encrypted transformation data, at least in part based on the chronological sequence of encrypted display data and encrypted transformation data, attributing the credit used for the transformation in the encrypted transformation data to each display of the encrypted display data.

[0011] In some respects, performing the multi-party computation process includes: for each presentation, encrypting a first connection key by a first aggregation server, and sending a tuple comprising the encrypted first connection key, encrypted presentation data, and encrypted presentation time data to a second aggregation server; and for each transformation, encrypting a second connection key by the second aggregation server, and sending a tuple comprising the encrypted second connection key, encrypted transformation data, and encrypted transformation time data to the first aggregation server.

[0012] In some respects, the multi-party computation process includes: decrypting each encrypted conversion time data by a first aggregation server; determining a first time deviation value by the first aggregation server; generating second encrypted conversion time data by summing the time the encrypted conversion occurred, the clock deviation of the client device where the conversion occurred, and the first time deviation value; determining the number of unique second connection keys by the first aggregation server for each unique encrypted conversion data; filtering each encrypted conversion data whose number of unique second connection keys is less than a threshold from the set of encrypted conversion data received by the first aggregation server; and providing a data tuple including the second connection key for the encrypted conversion data, the encrypted conversion data, and the second encrypted conversion time data for each remaining encrypted conversion data in the set of encrypted conversion data. The filtering steps detailed above provide a technical effect of increasing data security because each encrypted conversion data requires a threshold number of unique second connection keys, otherwise the data will be filtered out. This is used to improve the protection of user privacy because it makes it difficult to trace back to a specific user based on the conversion data (because the remaining unfiltered conversion data is associated with at least a threshold number of connection keys), thereby improving the anonymity associated with the conversion data.

[0013] In some respects, the multi-party computation process includes: decrypting each encrypted display time data by a second aggregation server; determining a second time deviation value by the second aggregation server; generating second encrypted display time data by summing the time the encrypted display occurred, the clock deviation of the client device where the display occurred, and the second time deviation value; determining the number of unique first connection keys by the second aggregation server for each unique encrypted display data; filtering each encrypted display data whose number of unique first connection keys is less than a threshold from the set of encrypted display data received by the second aggregation server; and providing a data tuple including the first connection key used for the encrypted display data, the encrypted display data, and the second encrypted display time data for each remaining encrypted display data in the set of encrypted display data. The filtering steps detailed above provide a technical effect of increasing data security because each encrypted display data requires a threshold number of unique first connection keys, otherwise the data will be filtered out. This is used to improve the protection of user privacy because it makes it difficult to trace back to a specific user based on the display data (because the remaining unfiltered display data is associated with at least a threshold number of connection keys), thereby improving the anonymity associated with the display data.

[0014] In some aspects, a computer-implemented method is provided, comprising: receiving display data from each of a plurality of client devices by a first aggregation server, wherein for each display of a digital component recorded by the client devices, the display data includes: (i) a first connection key based on a first unique identifier of the client device on which the display occurs or an application on the client device; (ii) encrypted display data encrypted using a first public key of the first aggregation server and a second public key of a second aggregation server different from the first aggregation server; and (iii) encrypted display time data indicating the time at which the display occurs; the first aggregation server and the second aggregation server cooperating to perform a secure multi-party computation using a secure multi-party computation protocol to generate a time-ordered sequence of encrypted display data and encrypted conversion data stored by the second aggregation server; and decrypting the encrypted display data and encrypted conversion data, including: identifying the encrypted conversion data and corresponding second connection keys based on the first connection key and the second connection key corresponding to the conversion data provided by the plurality of client devices to the second aggregation server. The second aggregation server is configured to receive conversion data from each of the plurality of client devices, wherein for each conversion recorded by a client device, the conversion data includes: (i) one of the second connection keys, which is a second unique identifier based on the client device on which the conversion occurred or an application on the client device; and (ii) a second value, which includes the encrypted conversion data that has been encrypted using the first public key and the second public key; and (iii) encrypted conversion time data, which indicates the time when the conversion occurred.

[0015] In some aspects, a system is provided, comprising one or more processors; and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: receiving presentation data from each of a plurality of client devices by a first aggregation server, the presentation data comprising, for each presentation of a digital component recorded by a client device: (i) a first connection key based on a first unique identifier of the client device on which the presentation occurs or an application on the client device; (ii) encrypted presentation data encrypted using a first public key of the first aggregation server and a second public key of a second aggregation server different from the first aggregation server; and (iii) encrypted presentation time data indicating the time at which the presentation occurs; and the first aggregation server and the second aggregation server cooperating to perform a secure multi-party computation using a secure multi-party computation protocol to generate a time-ordered sequence of encrypted presentation data and encrypted transformation data stored by the second aggregation server, and decrypting the encrypted presentation data and encrypted transformation data, including: based on the first connection key and the first connection key and the first connection key, sending data to the second aggregation server via the client devices. The device provides a second connection key corresponding to the conversion of the conversion data, identifying a group of encrypted conversion data and corresponding encrypted display data; and for each time-ordered sequence, sorting the encrypted conversion data and corresponding encrypted display data based on encrypted display time data and encrypted conversion time data corresponding to each second connection key; and decrypting the display data and conversion data for each sequence of encrypted display data and encrypted conversion data in multiple stages using a first private key corresponding to a first public key and a second private key corresponding to a second public key; wherein the second aggregation server is configured to receive conversion data from each of at least a portion of the plurality of client devices, and for each conversion recorded by the client device, the conversion data includes: (i) one of the second connection keys, the second connection key being a second unique identifier based on the client device where the conversion occurred or an application on the client device, and (ii) a second value, the second value including encrypted conversion data that has been encrypted using the first public key and the second public key, and (iii) encrypted conversion time data, the encrypted conversion time data indicating the time when the conversion occurred.

[0016] In some aspects, a non-transitory computer-readable medium is provided, comprising instructions that, when executed by one or more processors of a first aggregation server, cause the one or more processors to perform operations including: receiving display data from each of a plurality of client devices by the first aggregation server, the display data comprising, for each display of a digital component recorded by the client devices: (i) a first connection key based on a first unique identifier of the client device on which the display occurs or an application on the client device; (ii) encrypted display data encrypted using a first public key of the first aggregation server and a second public key of a second aggregation server different from the first aggregation server; and (iii) encrypted display time data indicating the time at which the display occurs; and cooperating between the first and second aggregation servers to perform a secure multi-party computation using a secure multi-party computation protocol to generate a time-ordered sequence of encrypted display data and encrypted conversion data stored by the second aggregation server, and decrypting the encrypted display data and encrypted conversion data, including: providing conversion data to the second aggregation server based on the first connection key and the multiple client devices. The data conversion corresponds to a second connection key, identifying a group of encrypted conversion data and corresponding encrypted display data; and for each time-ordered sequence, the encrypted conversion data and corresponding encrypted display data are sorted based on encrypted display time data and encrypted conversion time data corresponding to each second connection key; and display data and conversion data are decrypted for each sequence of encrypted display data and encrypted conversion data in multiple stages using a first private key corresponding to a first public key and a second private key corresponding to a second public key; wherein, a second aggregation server is configured to receive conversion data from each of at least a portion of the plurality of client devices, and for each conversion recorded by a client device, the conversion data includes: (i) one of the second connection keys, the second connection key being a second unique identifier based on the client device where the conversion occurred or an application on the client device, and (ii) a second value, the second value including encrypted conversion data that has been encrypted using the first public key and the second public key, and (iii) encrypted conversion time data, the encrypted conversion time data indicating the time when the conversion occurred.

[0017] The subject matter described in this specification can be implemented in specific embodiments to achieve one or more of the advantages described below. The cryptographic techniques described in this document enable the computation of measurements on various types of data while protecting user privacy and preventing fraudulent manipulation of the data. For example, the technique can enable the computation of measurements on displays, various types of transformations, and aggregated values ​​of transformations while protecting user privacy and preventing fraud in transformation and display reports. For example, the technique can be used to compute click-through transformations, browsing transformations, application download transformations, cross-device transformations (where the transformation occurs on a different device than the device where the display occurs), and application-to-web transformations (where the display occurs in the application and the transformation occurs in the browser (or vice versa)) while protecting user privacy and preventing fraud. The technique also supports multiple attribution models that provide the same protection, such as recent click attribution, data-driven attribution, and multi-touch attribution.

[0018] Using multiple aggregation servers to form multi-party computation (MPC) enables each server to check for signs of fraudulent activity on another server and ensures that no single server can access any user data in plaintext at any time. Even if one of the servers is compromised or colludes with other entities, MPC, combined with k-anonymity, differential privacy, public-key encryption, and additive / exchange homomorphic encryption as described in this document, protects user privacy and prevents fraud during measurement. Using blind signatures to blind-sign network data enables the checking of such data for fraud while protecting user privacy by not transmitting unblinded data to other entities. Parts of data elements including network data can be blind-signed and / or encrypted by multiple entities to prevent fraud or collusion among them. As described herein, blinded data (e.g., presentation data or transformed data) is data that has been processed blindly using cryptographic techniques. Blinded data is disguised so that entities cannot discern plaintext data from it. Entities can blindly sign data (e.g., a fraud detection system that determines a display is valid can sign blindly displayed data) to verify its legitimacy, but the entity providing the signature can sign the data without actually seeing the plaintext data. Therefore, fraud detection servers can be used to check for fraud without compromising user privacy, because the fraud detection server or any other interceptor cannot see the displayed data in plaintext.

[0019] The features and advantages of the foregoing subject matter will now be described with reference to the accompanying drawings. Additional features and advantages will become apparent from the subject matter described herein and the claims. Attached Figure Description

[0020] Figure 1 This is a block diagram of an example environment where the aggregation server determines aggregated network measurements.

[0021] Figure 2 This is a block diagram illustrating an example process flow for determining aggregate network measurements.

[0022] Figure 3 This is a flowchart illustrating an example process for determining aggregated data.

[0023] Figure 4 This is a flowchart illustrating another example process for determining aggregated data.

[0024] Figure 5 This is a flowchart illustrating an example process for verifying the integrity of data.

[0025] Figure 6 This is a flowchart illustrating an example process for generating the chronological order of events while protecting user privacy.

[0026] Figure 7 This is a flowchart illustrating an example process for using data-driven attribution to attribute a transformation to a given example.

[0027] Figure 8 This is a flowchart illustrating an example process for determining aggregate transformation values.

[0028] Figure 9 This is a flowchart illustrating an example process for determining aggregated transformation data.

[0029] Figure 10 This is a block diagram of an example computer system.

[0030] The same reference numerals and names in the various figures indicate the same elements. Detailed Implementation

[0031] In general, this document describes cryptographic techniques for preventing fraud when determining event levels and aggregating network measurements. For example, the techniques described in this document can prevent fraud when determining event levels and aggregating representations and transformation measurements of digital components used for various types of transformations. The cryptographic techniques described in this document can also protect user privacy, for example, by preventing all entities from being able to track or aggregate user data received from the user's client device.

[0032] System Overview

[0033] Figure 1This is a block diagram of an example environment 100 where aggregation server 180 determines aggregated network measurements. Example environment 100 includes a data communication network 105, such as a local area network (LAN), wide area network (WAN), the Internet, a mobile network, or a combination thereof. Network 105 connects client devices 110, publishers 130, websites 140, a digital component distribution system 150, a fraud detection system 170, a conversion system 172, aggregation server 180, a reporting system 190, and a time server 192. Example environment 100 may include many different client devices 110, publishers 130, and websites 140. In some implementations, environment 100 may also include multiple digital component distribution systems 150, fraud detection systems 170, conversion systems 172, and reporting systems 190. Although two aggregation servers 180-A and 180-B are present in this example, more than two aggregation servers 180-A and 180-B may be used as described below.

[0034] Website 140 is one or more resources 145 associated with a domain name and hosted on one or more servers. An example website is a collection of web pages in HTML format, where the web pages may contain text, images, multimedia content, and programming elements (such as scripts). Each website 140 is maintained by a publisher 130, where the publisher 130 is the entity that controls, manages, and / or owns the website 140.

[0035] Resource 145 is any data that can be provided on network 105. Resource 145 is identified by a resource address (e.g., a Universal Resource Locator (URL)) associated with it. To name just a few examples, resources include HTML pages, word processing documents and portable document format (PDF) documents, images, videos, and feed sources. These resources may include content such as words, phrases, images, and sounds, and may include embedded information (such as meta-information in hyperlinks) and / or embedded instructions (such as scripts).

[0036] Client device 110 is an electronic device capable of communicating on network 105. Example client device 110 includes a personal computer, a mobile communication device (e.g., a smartphone), and other devices capable of sending and receiving data on network 105.

[0037] Client device 110 typically includes applications 112 (such as web browsers and / or native applications) to facilitate sending and receiving data on network 105. Native applications are applications developed for a specific platform or device. Publisher 130 may develop native applications and provide them to client device 110 (e.g., make them downloadable). In some implementations, client device 110 is a digital media device, such as a streaming device plugged into a television or other display to stream video to the television. Digital media devices may also include web browsers and / or other applications that include streaming video and / or rendering resources.

[0038] A web browser can request resource 145 from the web server of website 140, which hosts publisher 130, for example, in response to a user of client device 110 entering a resource address for resource 145 in the web browser's address bar or selecting a link referencing the resource address. Similarly, a native application can request application content from a remote server of publisher 130.

[0039] Some resources 145, application pages, or other application content may include digital component slots for presenting digital components together with resources 145 or application pages. As used throughout this document, the phrase "digital component" refers to a discrete unit of digital content or digital information (e.g., a video clip, audio clip, multimedia clip, image, text, or another unit of content). Digital components may be stored electronically on a physical storage device as a single file or a collection of files, and digital components may take the form of video files, audio files, multimedia files, image files, or text files, and may include advertising information, making advertising a type of digital component. For example, a digital component may be content designed to complement the content of a webpage or other resource presented by application 112. More specifically, a digital component may include digital content related to the resource content (e.g., a digital component may address the same topic as the webpage content, or may address a related topic). Therefore, providing digital components by the digital component distribution system 150 can complement and generally improve webpage or application content.

[0040] When application 112 loads resource 145 (or application content) that includes one or more digital component slots, application 112 may request digital components for each slot from digital component distribution system 150. Digital component distribution system 150 may then request digital components from digital component provider 160. Digital component provider 160 is an entity that provides digital components for presentation together with resource 145.

[0041] In some cases, the digital component distribution system 150 may also request digital components from one or more digital component partners 157. A digital component partner 157 is an entity that selects digital components on behalf of the digital component provider 160 in response to a digital component request.

[0042] The digital component distribution system 150 can select digital components for each digital component slot based on various criteria. For example, among digital components received from digital component provider 160 and / or digital component partner 157, the digital component distribution system 150 can select digital components based on their relevance to resource 145 (or application content), the performance of the digital component (e.g., the rate at which the user interacts with the digital component), etc. The digital component distribution system 150 can then provide the selected digital components(s) to client device 110 for presentation along with resource 145 or other application content.

[0043] When application 112 renders a digital component, application 112 (which may be a browser) may store presentation data 114 for the presentation of the digital component. Presentation data 114 for a specific presentation of the digital component may include a URL or domain for the digital component's landing page (e.g., a page linked to the digital component that the application / browser presents to the user when the user clicks on or interacts with the digital component), one or more identifiers for the digital component, event-level data associated with the presentation, a deadline specifying when the presentation data should be removed from client device 110, and / or a reporting URL or domain to which conversion reports for the digital component are to be sent. This data may be provided by the digital component, for example, as metadata of the digital component or anchor tags of the digital component. As described in more detail below, instead of storing raw presentation data for each presentation of the digital component or otherwise, application 112 may store presentation data blind-signed by fraud detection system 170.

[0044] Application 112 may also store conversion data 116 in response to a detected conversion. A conversion for a digital component is the completion of a user action specified after the digital component is presented to the user and / or after the user interacts with the digital component. The conversion data 116 for the conversion may include data indicating the type of conversion, as there are multiple types of conversions required for various conversion measurements. The type of conversion may specify the subsequent action after the conversion is completed. For example, a conversion may be adding an item to an online shopping cart. In this example, a first type of conversion may be adding an item but not checking out (e.g., not completing the purchase), while a second type of conversion may be adding an item and checking out. As described in more detail below, the conversion data for the conversion may be a set of one or more bits indicating the type of conversion, and the application may store the conversion data blind-signed by the digital component distribution system 150 (or the conversion system in which the conversion actually occurs).

[0045] A fraud detection system 170, which can be implemented as one or more servers, can evaluate fraud signals received from client device 110 and / or application 112 to determine whether a presentation is valid or fraudulent. As described below, the fraud detection system 170 can also determine whether a conversion is valid or fraudulent based on fraud signals received from conversion system 172. Fraud signals can be application-dependent and can vary in different implementations.

[0046] During the presentation, application 112 (or the operating system on client device 110) can collect fraud detection signals and provide them to fraud detection system 170. In addition to the fraud detection signals, application 112 can also send blind presentation data for the presentation to fraud detection system 170. Blind presentation data is presentation data that has been blinded (e.g., disguised) using cryptographic techniques. If fraud detection system 170 determines that the presentation is valid, it can sign the blind presentation data and provide the signed blind presentation data to application 112. Example techniques for generating and signing blind presentation data will be described below.

[0047] Fraud detection system 170 may be operated by digital component distribution system 150. In some implementations, fraud detection system 170 may be operated by one or more third parties. For example, application providers (e.g., entities that develop and provide web browsers or native applications, and / or digital component distributors that operate digital component distribution system 150) may authenticate one or more third parties to operate fraud detection system 170 to detect fraud and blindly sign blind data received from applications (e.g., web browsers and / or native applications) from multiple different developers.

[0048] A conversion system 172, which can be implemented as one or more servers, can determine whether a conversion has occurred. For example, each digital component provider 160 can operate the conversion system 172 to determine whether a conversion of its digital component has occurred. In a particular example, the conversion could be obtaining a product from a website. In this example, the conversion system 172 and the website could be maintained by the product distributor. The conversion system 172 can receive data from a web server hosting the website indicating that a specific product has been obtained, and determine that a conversion has occurred based on said data.

[0049] In another example, the conversion could be an application download. In this example, when an application is downloaded to client device 110, the app store can provide data specifying that the application has been downloaded to client device 110 to the application developer's conversion system 172. In some implementations, the app store also operates the conversion system 172.

[0050] The conversion system 172 can also interact with the fraud detection system 170 to determine whether the conversion is valid or fraudulent. For example, the conversion system 172 can provide blind conversion data and fraud detection signals to the fraud detection system 170. Blind conversion data is conversion data that has been blinded (e.g., disguised) using cryptographic techniques. If the fraud detection system 170 determines that the conversion is valid and / or the user interaction is genuine, the fraud detection system 172 can sign the blind conversion data and provide the signed blind conversion data to the application 112. Example techniques for generating and signing blind conversion data will be described below.

[0051] Aggregator server 180 can generate aggregated network measurements based on data received from client device 110. Aggregator server 180 can generate displays and / or conversion counts for various types of conversions based on data received from client device 110. For example, for digital components, aggregation server 180 can determine counts for click-through conversions, browsing conversions, application download conversions, cross-device conversions, and application-to-web and web-to-application conversions, while protecting user privacy and preventing fraud. As described below, aggregation server 180 implements the MPC protocol and uses exchange encryption technology to protect user privacy and prevent fraud when determining and reporting network measurements.

[0052] A click-based transition is a transition where a user interacts with a digital component and subsequently performs a specific action. A browse-based transition is a transition where a digital component is presented to a user and the user subsequently performs a specific action. An app download transition is a transition where a digital component is presented to a user and the user subsequently downloads an app referenced (e.g., promoted) by the presented digital component. In this example, downloading the app is the specific action. A cross-device transition is a transition where the specific action occurs on a device different from the device where the digital component is presented. An app-to-web transition is a transition where the display occurs (e.g., the digital component is presented) within the app and the specific event occurs in a browser.

[0053] Aggregation server 180 can report display data (e.g., display counts) and conversion data (e.g., conversion counts) to reporting system 190. Reporting system 190 can be implemented as a reporting domain that receives a reporting URL carrying input requests carrying display data, conversion data, and / or relevant network measurements. Reporting system 190 can be maintained by the digital component distributor or by another entity that reports data to digital component distribution system 150 or the digital component distributor.

[0054] Environment 100 may also include a time server 192. The time server 192 may be used in some of the techniques described below. As described below, the time server 192 can be used to decrypt some data encrypted using a public key of the time server 192. The time server 192 may confidentially maintain a private key corresponding to the public key and use the private key to decrypt the data.

[0055] Example process flow for determining network measurements

[0056] Figure 2 This is a block diagram of an example process flow 200 used to determine aggregation network measurements. Process flow 200 is shown as being composed of... Figure 1 The system is executed by a number of components, including one or more client devices 110, a fraud detection system 170, a conversion detection system 172, aggregation servers 180-A and 180-B, and a reporting system 190.

[0057] Each instance of application 112 (which may be a web browser or a native application) can have a unique identifier for the conversion measurement. In other words, an instance of a specific web browser on one client device will be different from another instance of a specific web browser running on a different client device and will have a different unique identifier. The unique identifier used for application 112 can be generated randomly or pseudo-randomly, and application 112 can be configured to never leak the unique identifier outside of application 112. As described below, the characteristics and use of the unique identifier can vary depending on the type of conversion being measured. In some implementations that support cross-device measurements, all (multiple) applications 112 on all client devices 110 owned by the same user can have the same unique identifier for the conversion measurement.

[0058] When the digital component is presented on the client device 110 by application 112, application 112 can record the display data (m i The data includes the destination (dc_destination), the conversion measurement deadline, and the report domain (report_domain) that will receive the conversion report from the digital component. The data can be presented as an opaque byte array and may include one or more identifiers, for example, for the digital component and / or event-level data associated with the digital component display at application 112.

[0059] The destination can include a generic resource identifier (URI), URL, or domain for a landing page used for the digital component (e.g., a page linked to the digital component that the application / browser presents to the user when the user clicks on or interacts with the digital component). Examples of URIs include links to app stores for downloading the application and deep links to in-app purchase locations. Therefore, the destination can also be referred to as a destination domain. The conversion measurement cutoff date can be the time (or period) from which the displayed data will be removed from client device 110. The reporting domain can be the reporting URL or domain to which conversion reports for the digital component are sent; for example, the digital component provider 160 may wish to send conversion reports to its reporting system 190's reporting URL or domain.

[0060] In some implementations, application 112 may also record click data (clicked data), which specifies whether a user interacted with the digital component (e.g., selected or clicked the digital component) when application 112 presented it. Click data may be a Boolean variable, for example, a value of 1 if interacted with, and a value of 0 if not interacted with. In some other implementations, application 112 may also record other types of metadata indicative of how a user interacted with the digital component, such as when a user completed a survey or muteed the digital component. For example, a user could mute a digital component to indicate that they do not want to see the same (or similar) digital component in the future.

[0061] As described above, application 112 can also interact with fraud detection system 170 to determine whether the display of the digital component is valid or fraudulent. If the display is valid, application 112 can also request fraud detection system 170 to blind-sign the information related to the display.

[0062] In some implementations, the digital component may invoke computer-readable code (e.g., a script) that collects fraud detection signal 202 and sends it to fraud detection system 170 for evaluation. If the presentation is valid, application 112 may carry this invocation to fraud detection system 170 (e.g., add data to it) by requesting fraud detection system 170 to blind-sign information related to the presentation.

[0063] In some implementations, application 112 may send blind display data 201 to fraud detection system 170. Blind display data 201 may include two blind display data elements to be blind-signed by fraud detection system 170. Binding and / or encrypting these data elements protects user privacy by preventing fraud detection system 170 from receiving unencrypted user data and preventing user tracking.

[0064] The first encrypted data element is an encrypted crypto-hashed version of a combination (e.g., concatenation or some other combination) of a unique identifier (ID) for the application, a destination (dc_destination), and a report domain (report_domain). This first encrypted data element can be defined as CryptoHash(ID, dc_destination, report_domain). The cryptographic hash in this example can be a one-way cryptographic hash function that maps the tuple (ID, dc_destination, report_domain) to a hash value.

[0065] In one example, the cryptographic hash function is based on a hash-based Message Authentication Code (HMAC), for example, HMAC SHA256 Message code. For example, the first encrypted data element could be an HMAC that uses the ID as the key and nests an HMAC. SHA256 (HMAC SHA256 (ID, dc_destination), report_domain). In another example, the first encrypted data element could be: SHA256(ID || dc_destination || report_domain). For the purposes of this document, the symbol || denotes a method of composing a complex message from a simple message, where this combination is reversible, i.e., the simple message can be extracted back from the complex message. One example method is a protocol buffer with serialization / deserialization. Other examples include Java. TM Serialization, JavaScript Object Notation (JSON), etc.

[0066] The second encrypted data element is the display data (m) i An encrypted version of a combination of data indicating whether a digital component has been clicked or otherwise interacted with. For example, application 112 could generate a complex message (m i ||clicked), and encrypts the complex message using a public key obtained from reporting system 190 (e.g., fetch). This complex message indicates whether the displayed data and the digital component have been clicked or otherwise interacted with. Application 112 can use the public key of reporting system 190 to encrypt the complex message, ensuring that only reporting system 190 can decrypt the displayed and clicked data using a private key corresponding to (e.g., mathematically linked to) the public key. Reporting system 190 can keep the private key confidential, preventing other entities from accessing the information. This second encrypted data element can be defined as: PubKeyEncrypt(m i || clicked, report_domain). In this representation, including "report_domain" after the comma indicates that the public key used to encrypt complex messages is the public key of reporting system 190.

[0067] Fraud detection system 170 can receive blind display data 201 and fraud detection signal 202, and evaluate the fraud detection signal to determine whether the display of the digital component is valid or fraudulent. If fraud detection system 170 determines that the display is valid, it can use blind signature technology to blind sign the blind display data 201. For example, fraud detection system 170 can generate a first blind signature for a first data element of blind display data 201 and a second blind signature for a second encrypted data element of blind display data 201. In some implementations, the blind signature technology can be provided by Cloudflare. TM Supported privacy protocols or trust tokens from Chrome are both based on the Internet Engineering Task Force (IETF) draft standard for verifiable unintentional pseudo-random functions (VOPRF).

[0068] The VOPRF blind signature protocol is particularly advantageous because the amount of information exposed to the fraud detection system 170 should be limited, and application 112 needs to ensure that the signature is valid and does not contain any additional information beyond the signature itself, which could be used to track the user. For the techniques described in this document, the VOPRF protocol is considered deterministic because it applies a function without adding any arguments to the function. Application 112 can learn the signature scheme to allow for signature verification and deblinding of the presented data.

[0069] The fraud detection system 170 can send blind signature display data 203 to the application 112. The blind signature display data 203 includes a first encrypted data element, a second encrypted data element, and their corresponding blind signatures.

[0070] Application 112 can use the first encrypted data element and a blind signature for the first encrypted data element to generate a key. This key can be called the blind signature concatenation key and can be defined as BlindlySignedKey(ID, dc_destination, report_domain), which in turn represents CryptoHash(ID, dc_destination, report_domain) combined with the blind signature of the first encrypted data element received from the fraud detection system 170.

[0071] Application 112 can also use a second encrypted data element received from the fraud detection system 170 and a blind signature of the second encrypted data element to generate multiple encrypted presentation data. For example, application 112 can generate multiple encrypted presentation data by blindly signing the second encrypted data element (PubKeyEncrypt(m iThe complex message encryption of the second encrypted data element (|| clicked, report_domain) and the blind signature of the second encrypted data element generates secondary encrypted display data (ImpressionData2). ImpressionData1 represents the single encrypted data (second encrypted data element). This secondary encrypted display data can be defined as ImpressionData2 = PubKeyEncrypt(ImpressionData1 || blind_signature, S...). i ), where blind_signature represents the blind signature of the second encrypted data element, S i This represents the public key of the aggregation server 180-A that collects and displays the data. In other words, application 112 can generate a complex message by blindly signing the single encrypted data (ImpressionData1) and the single encrypted display data (ImpressionData1), and then encrypt the complex message using the public key of the aggregation server 180-A to generate secondary encrypted display data (ImpressionData2).

[0072] Then, application 112 can use the secondary encrypted display data (ImpressionData2) and the public key of the aggregation server 180-B that collects the converted data to generate tertiary encrypted display data (ImpressionData3). In some implementations, the tertiary encrypted display data (ImpressionData3) is generated using probabilistic public key encryption. In this example, the tertiary encrypted display data can be defined as:

[0073] ImpressionData 3p = PubKeyEncrypt Probabilistic (ImpressionData2, S c ).

[0074] At this point, the display data is encrypted three times sequentially using the public keys from reporting system 190, aggregation server 180-A, and aggregation server 180-B. In this way, application 112 can securely display the three-times encrypted display data (ImpressionData). 3p The data is sent to an aggregation server 180-A with sufficient privacy protection because the innermost single-pass encrypted display data (PubKeyEncrypt(m)) is sent to the aggregation server 180-A. i || clicked, report_domain)) protects the display data m during transmission from application 112 to reporting system 190. iThe outermost probabilistic public-key encryption using the public key of aggregation server 180-B prevents collusion between reporting system 190, aggregation server 180-A, and digital component distribution system 150. The colluding parties may use a stable blind signature to reveal the connection key (BlindlySignedKey(ID, dc_destination, report_domain)) and reconstructable single-pass encrypted reveal data (PubKeyEncrypt(m...)). i || clicked, report_domain)) to track users across publisher domains. As described below, only when both aggregation servers 180-A and 180-B are certain (PubKeyEncrypt(m i When all applicable thresholds are reached, aggregation servers 180-A and 180-B collaboratively decrypt the three encrypted display data to discover the PubKeyEncrypt(m) that was independently sent to reporting system 190 by each of aggregation servers 180-A and 180-B. i ||clicked, report_domain)).

[0075] In some implementations, the fraud detection system 170 uses two different keys to blindly sign the first encrypted data element to generate a blindly signed display connection key (BlindlySignedKey(ID, dc_destination,report_domain)) and to blindly sign the second encrypted data element (ImpressionData1). This prevents malicious applications (e.g., malicious browsers) from requesting the blind signature used to display the data and subsequently claiming it as the signature used to blindly sign the display connection key, or vice versa.

[0076] For each display for which display data has already been recorded, application 112 can upload the display data (e.g., triple-encrypted display data) to aggregation server 180-A. For example, application 112 can periodically upload multiple batches of encrypted display data (e.g., triple-encrypted display data). In some implementations, for each display, application 112 uploads a key-value pair M. i 205, where key-value pairs M i 205 includes a blindly signed display connection key (BlindlySignedKey(ID, dc_destination, report_domain)) used as the key and triple-encrypted display data (ImpressionData) as the value.3p ).

[0077] Upload key-value pairs M for each presentation when the presentation occurs. i In comparison, this batch upload has several advantages. For example, batch uploads can hide the actual display time from the aggregation server 180-A, thus avoiding timing-based attacks. This can also reduce the load, such as the queries per second (QPS) load on the aggregation server 180-A. It can also reduce the bandwidth and battery consumption of the client device 110 (e.g., if the batch upload occurs while the mobile device is connected to Wi-Fi and charging). This also allows for the selection of keys for each batch protocol instance that manages the cryptographic keys; for example, if the communication between the client device 110 and the aggregation server 180-A is over Hypertext Transfer Protocol Security (HTTPS), the same encryption key can be used for the entire batch.

[0078] When the conversion system 172 determines that a genuine conversion has occurred for client device 110, the conversion system 172 can interact with the fraud detection system 170 to determine whether the conversion is valid or fraudulent. For example, the conversion system 172 can obtain a fraud detection signal 211 from client device 110 and send the fraud detection signal 211 to the fraud detection system 170. The fraud detection system 170 can evaluate the fraud detection signal 211 to determine whether the conversion is valid or fraudulent, whether client device 110 is trustworthy (relative to root privileges, an emulator in the data center, or otherwise compromised), and / or whether the user's interaction is genuine.

[0079] If the conversion is successful when the fraud detection signal is utilized, the conversion system 172 can also send a third encrypted data element that will be blind-signed by the fraud detection system 170. This third encrypted data element may include an encrypted version of a combination of a unique identifier (ID) used for application 112 and a conversion domain (conversion_domain) where the conversion occurred. The conversion domain may be the website where the conversion occurred. Similar to the first encrypted data element used to encrypt the displayed data, this data can be encrypted using the public key used by the reporting system 190 for the conversion. For example, the third encrypted data element can be defined as CryptoHash(ID, conversion_domain, report_domain) and can be encrypted using the same cryptographic hash function used to generate the first encrypted data element.

[0080] Fraud detection system 170 can blind-sign the third encrypted data element using the same protocol used to blind-sign the first encrypted data element being displayed. Fraud detection system 170 can then send blind-signed conversion data 212 to conversion system 172. This blind-signed conversion data 212 can include the blind-signed third encrypted data element and a blind signature of the third encrypted data element. Conversion system 172 can use the blind-signed conversion data 212 to generate a blind-signed conversion key. The blind-signed conversion key (BlindlySignedKey(ID, conversion_domain, report_domain)) is a combination of the third encrypted data element and the blind signature of the third encrypted data element received from fraud detection system 170. In this way, if the conversion is indeed triggered by a display, the dc_destination at the time of display and the conversion_domain at the time of conversion will be the same. Therefore, the blind-signed display key will match the blind-signed conversion key.

[0081] The conversion system 172 can also use conversion metadata m for conversion. c The private key of the conversion system 172 is used to generate signed conversion data. Conversion metadata m c This can include transformation-related data, such as transformation type, label, and quantized transformation value. Signature transformation data can be defined as PrivateKeySign(m c (conversion_domain). Based on the digital signature algorithm, generating signature conversion data may include using a private key and a public key to attach a digital signature to the conversion metadata. The conversion system 172 may provide the blind signature conversion key and signature conversion data 213 to the application 112.

[0082] Application 112 can use signature transformation data (PrivateKeySign(m c Multiple encrypted conversion data can be generated using `conversion_domain`. Application 112 can encrypt and sign the conversion data using the public key of the reporting system 190 used for the conversion (PrivateKeySign(m, conversion_domain)). c This generates a single encrypted conversion data (ConversionData1). This single encrypted conversion data can be defined as PubKeyEncrypt(PrivateKeySign(m, conversion_domain)). c (conversion_domain), report_domain). In some implementations, conversion system 172 (instead of application 112) may generate multiple encrypted conversion data, or at least generate a single encrypted conversion data.

[0083] Encryption combined with digital signatures protects the transformation of data m c To prevent tampering and eavesdropping during transmission from conversion system 172 to reporting system 190 via multiple intermediaries (e.g., aggregation servers 180-A and 180-B), the encryption and digital signatures in ConversionData1 should be deterministic within a time / batch processing window to ensure that the same plaintext is mapped to the same ciphertext, facilitating aggregation and implementation of k-anonymity in subsequent stages.

[0084] In some cases, transforming metadata m c There might not be much entropy. Therefore, the single encrypted conversion data (ConversionData1) might have a finite cardinality and is easily predictable. In this case, by adjusting the conversion metadata m... c The cryptographic hashes of the conversion domain and report domain are used to compose and encrypt complex messages. Pseudo-entropy (e.g., a randomness-based cryptographic key) can be added to the conversion metadata m. c In this example, a single encrypted conversion data (ConversionData1) can be defined as:

[0085] PubKeyEncrypt(PrivateKeySign(m c HMAC SHA256 (conversion_domain,report_domain), conversion_domain), report_domain), where HMAC SHA256 (conversion_domain, report_domain) is a cryptographic hash of the conversion domain and the report domain, with pseudo-entropy added. In this example, the private key of the conversion domain is used to sign complex messages, and the public key of the report domain is used to encrypt the signed complex messages.

[0086] Application 112 can encrypt the single-pass encrypted conversion data (ConversionData1) using the public key of the aggregation server 180-B that collects the conversion data, generating a second-pass encrypted conversion data (ConversionData2). The second-pass encrypted conversion data (ConversionData2) can be defined as PubKeyEncrypt(ConversionData1, S... c ), where S cThis represents the public key of aggregation server 180-B. Application 112 can then encrypt the secondary encrypted conversion data (ConversionData2) using the public key of aggregation server 180-A, which collects and displays the data, to generate tertiary encrypted conversion data (ConversionData3). In some implementations, the tertiary encrypted conversion data (ConversionData3) is generated using probability public key encryption. In this example, the tertiary encrypted conversion data can be defined as: PubKeyEncrypt Probabilistic (ConversionData2, S i ), where S i This represents the public key of the aggregation server 180-A.

[0087] For each transformation for which transformation data has been recorded, application 112 can upload the transformation data to aggregation server 180-B. For example, application 112 can periodically upload multiple encrypted transformation data in batches (e.g., three encrypted transformation data). In some implementations, for each transformation, application 112 uploads key-value pairs M. c 215, where key-value pairs M c 215 includes a blindly signed conversion key (BlindlySignedKey(ID, conversion_domain, report_domain)) used as the key and three encrypted conversion data (ConversionData3 or ConversionData) as the value. 3p This third (outermost) encryption can use a stable blind signature conversion key and secondary encryption of conversion data (ConversionData2) to prevent the aggregation server from tracking users across multiple domains during report conversions using a 180-B protocol.

[0088] Example MPC process for decrypting presentation and transformation data

[0089] Aggregator servers 180-A and 180-B can use a multi-step MPC process to aggregate and subsequently decrypt subsets of received data that meet thresholds and / or other privacy-preserving standards, and send a report to reporting system 190. This process... Figure 3 As shown in the figure, Figure 3 This is a flowchart illustrating an example process 300 for determining aggregated transformation data. Process 300 can be performed, for example, through multiple aggregation servers (e.g., Figure 1 and Figure 2 This is achieved using aggregation servers 180-A and 180-B.

[0090] Aggregator server A and aggregation server B can use a swapped encryption technique "H" with swapped properties. In other words, given any message m and two distinct encryption keys K1 and K2, the swapped encryption technique has the following property: H(H(m,K1), K2) = H(H(m, K2), K1). In other words, swapped encryption involves double encryption using distinct encryption keys, where the order of encryption (which key is used first to encrypt the data) is irrelevant because the same result can be obtained regardless of the method used.

[0091] Each of Aggregator Server 180-A and Aggregator Server 180-B can select a secret encryption key pair. i (It represents a key pair) and Key c (This represents a key pair). As described below, the key is... ii One of them can be used to encrypt the connection key, Key i2 One of them can be used to encrypt / decrypt displayed data. Similarly, the key... c1 One of them can be used to encrypt the connection key, and the key is Key c2 One of them can be used to encrypt / decrypt transformed data. Aggregator Server 180-A and Aggregator Server 180-B can periodically select new key pairs based on specified time periods, by batch of displayed or transformed data, or based on other appropriate criteria.

[0092] Aggregator server 180-A receives display data (302). For example, aggregation server 180-A can receive batches of display data from multiple client devices. As described above, each client device can periodically send batches of display data to aggregation server 180-A.

[0093] For each display, the display data can be sent in the form of key-value pairs. Each key-value pair can include a blindly signed display key (BlindlySignedKey(ID, dc_destination, report_domain)) as the key and triple-encrypted display data (ImpressionData) as the value. 3p ).

[0094] Aggregator server 180-B receives transformation data (304). For example, aggregation server 180-B can receive batches of transformation data from multiple client devices. As described above, each client device can periodically send batches of transformation data to aggregation server 180-B.

[0095] For each conversion, the conversion data can be sent in the form of key-value pairs. Each key-value pair can include a blindly signed conversion key (BlindlySignedKey(ID, conversion_domain, report_domain)) as the key and three-dimensional encrypted conversion data (ConversionData) as the value. 3p ).

[0096] For each display, the aggregation server 180-A uses exchange encryption and the selected encryption key Key. i1 To encrypt the connection key (306). In this example, the connection key used for the display is the blind-signed connection display key (BlindlySignedKey(ID, dc_destination, report_domain)). Then, for each display, aggregation server 180-A can provide aggregation server 180-B with the encrypted connection key and the triple-encrypted display data. In other words, for each display, aggregation server 180-A can send the pair: {H(BlindlySignedKey, Key...} i1 ImpressionData 3p These pairs can be sent in a random or pseudo-random order.

[0097] For each conversion, the aggregation server 180-B uses the exchange encryption and the selected encryption key Key. c1 To encrypt the connection key (308). In this example, the connection key used for the conversion is the blindly signed conversion key (BlindlySignedKey(ID, conversion_domain, report_domain)). Then, for each conversion, aggregation server 180-B can provide aggregation server 180-A with the encrypted connection key and the three-way encrypted conversion data. In other words, for each presentation, aggregation server 180-B can send the pair: {H(BlindlySignedKey, Key...} c ),ConversionData 3p These pairs can be sent in a random or pseudo-random order.

[0098] For each pair of received encrypted connection keys and three encryption transformations of data {H(BlindlySignedKey, Key...} c1 ), ConversionData 3pThe aggregation server 180-A re-encrypts the connection key and transforms the data (310). In some implementations, the aggregation server 180-A can use its private key (which, along with the public key S) i The corresponding private key is used to decrypt the three-stage encryption conversion data (ConversionData). 3p This is used to recover the second-order encrypted conversion data (ConversionData2). Then, the aggregation server 180-A can use its chosen encryption key Key. i2 To re-encrypt the converted data (ConversionData2), a deterministic symmetric encryption technique can be used. This encrypted converted data can be called ConversionData. 3’ This is because the transformed data has been deterministically encrypted three times in sequence using keys from three domains (Reporting System 190, Aggregator Server 180-B, and Aggregator Server 180-A).

[0099] The Aggregator Server 180-A can also use its selected encryption key. i2 The key (H(BlindlySignedKey, Key)) has already been exchanged for encrypted blind signature display. c The exchange encryption is applied on top of this. The result of this step is... and ConversionData 3’ For each pair of received encrypted connection keys and encrypted triple-transformation data, aggregation server 180-A sends both results to aggregation server 180-B.

[0100] For each pair of received encrypted connection keys and encrypted display data (encrypted three times), {H(BlindlySignedKey, Key...} i1 ), ImpressionData 3p The aggregation server 180-B re-encrypts the connection key and displays the data (312). In some implementations, the aggregation server 180-B may use its private key (which, along with the public key S) c The corresponding private key is used to decrypt the three-times encrypted display data (ImpressionData). 3p This is used to recover the secondary encrypted display data (ImpressionData2). Then, the aggregation server 180-B can use its chosen encryption key Key. c2 The second encryption of the display data (ImpressionData2) will be performed. This encryption will use deterministic symmetric encryption technology. This encrypted display data can be referred to as ImpressionData. 3’This is because the data being displayed has been deterministically encrypted three times in sequence using keys from three domains (Reporting System 190, Aggregator Server 180-A, and Aggregator Server 180-B).

[0101] The aggregation server 180-B can also use its selected encryption key. c2 The key (H(BlindlySignedKey, Key)) has already been exchanged for encrypted blind signature display. i1 The exchange encryption is applied on top of this. The result of this step is... and ImpressionData 3’ For each pair of received encrypted connection keys and triple-encrypted display data, aggregation server 180-B sends both results to aggregation server 180-A.

[0102] Aggregator server 180-A joins and filters encrypted display and encrypted transformation data (314). After receiving results from aggregation server 180-B, aggregation server 180-A has result pairs for each display. and ImpressionData 3’ For each transformation, aggregation server 180-A also has result pairs { and ConversionData 3’}

[0103] Since the blind signature key has already been encrypted once by each of aggregation servers 180-A and 180-B using exchange encryption, it is used to encrypt the blind signature key ( The displayed cryptographic blind signature key that matches the given key. The conversion is generated by the display of the digital components because these keys are based on the unique identifier used for application 112, the domain of reporting system 190, and the domain of the landing page for the digital components. Therefore, aggregation server 180-A can use the cryptographic blind signature key ( To connect the corresponding display data with the corresponding transformation data, you can link the display data to the transformation data. For example, the aggregation server 180-A can generate a key using a cryptographic blind signature (…). This can be a table or other data structure used as the row key. Each row can include the row key and the joined presentation and transformation data. Table 1 below shows an example table. In other examples, joining presentation and transformation data can include generating a tuple containing the row key and the joined presentation and transformation data for each joined set.

[0104] Table 1

[0105]

[0106] Then, the aggregation server 180-A can filter the data to meet the k-anonymity criterion. The aggregation server 180-A can determine a unique cryptographic blind signature key associated with each triple-encrypted presentation of data. The number of triple-encrypted display data. Each triple-encrypted display data can also be referred to as the occurrence of display data. Since display data is not application-specific but based on the presented digital components, multiple displays can have the same triple-encrypted display data but different cryptographic blind signature keys ( ).

[0107] The Aggregator Server 180-A can associate a distinct cryptographic blind signature key with each unique display of data. The number of occurrences is compared to a k-anonymity threshold. If the number is below the threshold, the aggregation server 180-A can filter the occurrences of the data from tables or other data structures.

[0108] The aggregation server 180-A can also determine a unique cryptographic blind signature key associated with each triple-encrypted transformation of the data. The number of times the data undergoes a three-stage encryption transformation can be considered as the occurrence of transformation data. Since transformation data is not application-specific but based on data associated with a transformation event, multiple transformations can have the same three-stage encryption transformation data but different cryptographic blind signature keys. ).

[0109] The Aggregator Server 180-A can associate a distinct cryptographic blind signature key with each unique transformed data. The number of occurrences is compared to a k-anonymity threshold. If the number is below the threshold, the aggregation server 180-A can filter out the occurrences of the transformed data from tables or other data structures.

[0110] The Aggregator Server 180-A can also determine a unique cryptographic blind signature key associated with each combination of the triple-encrypted presentation data and the triple-encrypted transformation data. The number of times this occurs. In other words, it is a count of the number of unique blind signature keys that have the same triple-encrypted presentation data and the same triple-encrypted transformation data. Each combination of triple-encrypted presentation data and the same triple-encrypted transformation data can also be referred to as the occurrence of impression cross conversion data.

[0111] The Aggregator Server 180-A can compare the number of occurrences of each display and transformation intersection with a k-anonymity threshold. If the number is below the threshold, the Aggregator Server 180-A can filter the occurrences of display and transformation intersections from tables or other data structures.

[0112] Then, the aggregation server 180-A can use the filtered remaining data to generate new tables or data structures, as shown in Table 2 below. Each row in Table 2 corresponds to a combination of occurrences of `impressionData3'` and the corresponding occurrence of `ConversionData3'`. The table records the number of occurrences for each combination, for example, the unique cryptographic blind signature key associated with each combination (…). The number of digital component conversions is equal to the number of digital component conversions generated based on the display of digital components with the same display data.

[0113] Table 2

[0114]

[0115] Aggregator server 180-B connects to and filters encrypted display data and encrypted transformation data (316). After receiving results from aggregation server 180-A, aggregation server 180-B has result pairs for each display. and ImpressionData 3’ For each transformation, the aggregation server 180-B also has result pairs { and ConversionData 3’ Therefore, aggregation server 180-B has the same data as aggregation server 180-A.

[0116] Aggregator server 180-B can use the same data to perform the same calculations and filtering as aggregation server 180-A to obtain the same results. In other words, aggregation server 180-B can generate a table that matches Table 2 generated by aggregation server 180-A.

[0117] In some implementations, both aggregation server 180-A and aggregation server 180-B can perform optional operations (such as using downsampling) to ensure differential privacy. Differential privacy is a technique for sharing data about a dataset by describing a pattern within the dataset without providing individual data within the dataset. To this end, each aggregation server can first sample the data with a certain probability β (e.g., rows in Table 1). Then, the aggregation server applies the k-anonymity generalization described above only to the sampled data. That is, for each type of occurrence, the aggregation server can determine a unique cryptographic blind signature key (…). The number of samples can be determined, and the aggregation server can filter out those samples that do not meet the k-anonymity threshold.

[0118] For subsampling, to ensure that two aggregation servers replicate exactly the same samples and perform the same differential privacy techniques, the aggregation servers can use sampling based on pseudorandomness. The randomization of the samples can be determined based on a common seed collaboratively determined by the two servers (e.g., using a Diffie-Hellman key exchange). The result of the exchange is the seed of the same pseudorandom generator (e.g., a pseudorandom generator based on the Advanced Cryptography Standard (AES) algorithm). This ensures that the same subset is sampled in both aggregation servers and that the same results will be computed, because once the pseudorandomness is the same, the rest of the process is deterministic.

[0119] After joining and filtering, both aggregation servers 180-A and 180-B have the same data; for example, each of them includes {count, ImpressionData}. 3’ ConversionData 3’ A table or list of tuples containing ImpressionData. A count is a tuple containing ImpressionData. 3’ The number of conversions for displaying the same data.

[0120] For each tuple, the aggregation server 180-A decrypts the three-times encrypted conversion data. 3’ (318). Aggregator Server 180-A can use its chosen encryption key Key i2 To decrypt the three-times encrypted conversion data (ConversionData) 3’), to obtain {count, ImpressionData 3’ ConversionData 2’ Aggregator server 180-A can send these result tuples to aggregation server 180-B.

[0121] Similarly, for each tuple, the aggregation server decrypts the encrypted impression data three times using 180-B. 3’ (320). Aggregator Server 180-B can use its chosen encryption key Key c2 To decrypt the three-times encrypted display data (ImpressionData) 3’ ), to obtain {count, ImpressionData2, ConversiodData 3’ Aggregator server 180-B can send these result tuples to aggregation server 180-A.

[0122] The aggregation server 180-A decrypts each received result tuple {count, ImpressionData2, ConversionData}. 3’ The data consists of two encrypted display data (ImpressionData2) and three encrypted conversion data (ConversionData). 3’ (322). Aggregator server 180-A can use the public key S of aggregation server 180-A. i The corresponding private key is used to decrypt the second-order encrypted display data (ImpressionData2) and the third-order encrypted conversion data (ConversionData). 3’ For each received tuple, the decryption produces a tuple {count, ImpressionData1, ConversionData2}. Aggregator server 180-A can then send each of these tuples {count, ImpressionData1, ConversionData2} to aggregation server 180-B.

[0123] The aggregation server 180-B decrypts each received result tuple {count, ImpressionData}. 3’ The three-fold encrypted display data (ImpressionData) of ConversionData2} 3’ ) and secondary encrypted conversion data (ConversionData2) (324). The aggregation server 180-B can use the public key S of the aggregation server 180-B. cThe corresponding private key is used to decrypt the three-times encrypted display data (ImpressionData). 3’ The first tuple receives a tuple and the second tuple receives a tuple, which is then encrypted and converted into a second tuple (ConversionData2). For each received tuple, the decryption produces a tuple {count, ImpressionData2, ConversionData1}. Aggregator server 180-B can then send each of these tuples {count, ImpressionData2, ConversionData1} to aggregation server 180-A.

[0124] Aggregator server 180-A decrypts the display data (326) of each received tuple {count, ImpressionData2, ConversionData1}. Aggregator server 180-A uses the public key S of aggregation server 180-A. i The corresponding private key is used to decrypt the display data for each received tuple {count, ImpressionData2, ConversionData1}. For each received tuple, this decryption produces the tuple {count, ImpressionData1, ConversionData1}.

[0125] In this tuple, the display data (ImpressionData1) is (PubKeyEncrypt(m i || clicked,report_domain) || blind_signature), therefore including the presentation data encrypted using the public key of the reporting system 190 and the blind signature of the second data element generated at the time of presentation. Conversion data (ConversionData1) is PubKeyEncrypt(PrivateKeySign(m c , conversion_domain), report_domain), therefore including conversion data encrypted using the public key of the reporting system 190.

[0126] Aggregator server 180-B decrypts the transformed data (328) of each received tuple {count, ImpressionData1, ConversionData2}. Aggregator server 180-B uses the public key S of aggregation server 180-B. cThe corresponding private key is used to decrypt the transformed data of each received tuple {count, ImpressionData1, ConversionData2}. For each received tuple, this decryption produces the tuple {count, ImpressionData1, ConversionData1}.

[0127] Similar to the tuple decrypted by the aggregation server 180-A, in this tuple, the presentation data (ImpressionData1) is (PubKeyEncrypt(m i || clicked, report_domain) || blind_signature), therefore including the display data encrypted using the public key of the reporting system 190 and the blind signature of the second data element generated at the time of display. Conversion data (ConversionData1) is PubKeyEncrypt(PrivateKeySign(m c ,conversion_domain), report_domain), therefore including conversion data encrypted using the public key of the reporting system 190.

[0128] For each decrypted tuple, aggregation server 180-A sends a transformation report to reporting system 190 (330) for tuples. Similarly, for each decrypted tuple, aggregation server 180-B sends a transformation report to reporting system 190 (332) for tuples. The transformation report may include the decrypted tuple or data included in the decrypted tuple.

[0129] Aggregator servers 180-A and 180-B can obtain the URL for the reporting system for each tuple in various ways, thus obtaining each transformation. In one example, application 112, where the presentation occurs, can send the report_domain (e.g., the URL for reporting system 190) in plaintext to aggregation server 180-A (e.g., at presentation time and as a key-value pair M). i (The part of .). Similarly, the application 112 where the transformation occurs can send the report_domain in plaintext to the aggregation server 180-B (e.g., at the time of transformation and as a key-value pair M). c (part of the text).

[0130] In another example, browser developers (or application developers) can publish a whitelist of allowed reporting systems 190 and their report_domains. Browsers (or applications) can periodically download the whitelist and apply it to send conversion reports.

[0131] In another example, a browser or application could use (t, n)-threshold encryption to encrypt the report-domain and send the encrypted report-domain to aggregation servers 180-A and 180-B. In this example, aggregation servers 180-A and 180-B can only recover the plaintext report-domain if at least t browsers or applications have reported the same report-domain. In another example, for instance, if the report-domain does not have sufficient entropy, a derivation of the report-domain could be used in the (t, n)-threshold encryption. For example, the derivation could be a combination of the report-domain and a cryptographic hash for a landing page used for digital components.

[0132] Back Figure 2 For each pair of single-pass encryption transformation data (ImpressionData1) and PubKeyEncrypt(PrivateKeySign(m c Reporting system 190 receives two conversion reports, 127 and 128, from aggregation servers 180-A and 180-B. For each combination of presentation and conversion, each of conversion reports 127 and 128 may include the number of combinations in the filtered data, for example, as derived from the table described above. For the same batch of presentation and conversion data, the data in conversion report 127 received from aggregation server 180-A should match the data in conversion report 128 received from aggregation server 180-B. Reporting system 190 may compare the two quantities to identify discrepancies in order to look for potential signs of malicious activity.

[0133] The reporting system 190 can also invoke the fraud detection system 170 to verify the blind signature on the displayed data. Then, the reporting system 190 can use its own private key to decrypt the encrypted conversion data. The reporting system 190 can then use the conversion system's public key to verify the digital signature on the conversion data. If both verifications are successful, the reporting system 190 can be confident that the conversion measurement data is valid.

[0134] Recipients of conversion reports should be able to trust the data in the conversion reports. The technique described above, which compares conversion reports received from two aggregation servers 180-A and 180-B and verifies blind signatures, can prevent most fraud in the conversion report pipeline. However, the two aggregation servers might collude to modify conversion counts. To prevent such collusion, conversion server 172 can encrypt and digitally sign the conversion data before providing it to client device 110. For example, conversion system 172 can use asymmetric additive homomorphic encryption that preserves the signature or another signature technique that preserves the structure to encrypt and digitally sign the conversion data. In this way, the digital signature is preserved after being encrypted three times (or otherwise encrypted multiple times), as described above. This encryption prevents aggregation servers 180-A and 180-B from accessing the conversion data and allows the recipient to verify the digital signature to confirm that the conversion data has not been modified. As described below, each conversion value can be encrypted and signed in a similar manner when it is included in the conversion data.

[0135] The conversion reporting technology described above supports various types of conversion events. To support click-based and browser-based conversions within the same browser (or application), the browser or application can select a unique identifier (ID) randomly generated within the browser (or application) specifically for conversion measurement. The browser (or application) can calculate BlindlySignedKey(ID, conversion_domain, report_domain) during display and conversion. To differentiate between click-based and browser-based conversions, during display, the browser or application can simultaneously use the boolean variable clicked and the display data m. i This encodes whether a user interacts with the digital component. In other implementations, the browser or application can encode the type of interaction the user has with the digital component, such as muting the digital component, filling out a survey, etc.

[0136] To support same device conversions between applications and web browsers, both browsers and applications can use a device-level randomly generated (e.g., generated by the device's operating system) unique identifier (ID) to report presentations and conversions. Furthermore, if the conversion occurs in an application rather than a web browser, `conversion_domain` can be the application's name or an application developer certificate identifying the application.

[0137] To support cross-device transitions (e.g., a presentation occurs on one user's device, while the transition occurs on different devices), a unique identifier (ID) can be information about the user or based on that information. For example, a unique identifier (ID) could be a user's login credentials, a phone number or email address provided by the user, or a cryptographic hash of other personally identifiable information provided by the user. For instance, a user can log in to a mobile application. The same user can use the mobile application's login credentials to log in to the publisher's website. The same login credentials can be used as a user identifier (ID) for cross-device transitions occurring between the website and the mobile application.

[0138] Figure 4 This is a flowchart illustrating another example process 400 for determining aggregated transformation data. For example, process 400 may be performed by multiple aggregation servers (e.g., Figure 1 and Figure 2 This is implemented using aggregation servers 180-A and 180-B.

[0139] The first aggregation server 180-A receives presentation data (402) from multiple client devices. For each presentation of a digital component recorded by a client device, the presentation data may include a first key-value pair. The first key-value pair used for the presentation may include a unique identifier based on the client device where the presentation occurs or a first key of an application on the client device. For example, the first key used for the presentation may be a blind-signed presentation key and may be defined as BlindlySignedKey(ID, dc_destination, report_domain) received from the client device, as described above.

[0140] The first key-value pair used for display may also include a first value, wherein the first value includes encrypted display data that has been encrypted using a first public key of a first aggregation server and a second public key of a second aggregation server different from the first aggregation server. For example, the first value may be three encrypted display data (ImpressionData3) received from a client device.

[0141] The second aggregation server receives conversion data (404) from at least a portion of multiple client devices. For each conversion recorded by a client device, the conversion data may include a second key-value pair, wherein the second key-value pair includes a second unique identifier based on the client device where the conversion occurs or a second key of an application on the client device. For example, the second key for the conversion may be a blindly signed conversion key (BlindlySignedKey(ID,conversion_domain, report_domain)) received from the client device.

[0142] The second key-value pair used for conversion may include a second value, which includes encrypted conversion data that has been encrypted using the first and second encryption keys. For example, the second value may be three encrypted conversion data (ConversionData3) received from the client device.

[0143] Aggregator servers 180-A and 180-B perform an MPC process to join encrypted display data and encrypted transformation data, filter the join results, and then decrypt a subset (406) of encrypted display data and encrypted transformation data that meet privacy protection standards. This MPC process may include: identifying encrypted transformation data and corresponding encrypted display data pairs based on a first key and a second key. Then, for each pair of encrypted display data and transformation data, the display data and transformation data can be decrypted in multiple stages using a first private key corresponding to the first public key and a second private key corresponding to the second public key. Each stage may include: one of the first and second aggregation servers decrypting one of the encrypted display data and encrypted transformation data in each pair of encrypted transformation data and corresponding encrypted display data, and sending the resulting data to the other of the first and second aggregation servers. This MPC process can be combined with... Figure 3 The process shown and described above is the same as or similar to process 300.

[0144] Each part of the decrypted display data and each part of the decrypted transformed data are sent to the corresponding reporting system (408). For example, each of aggregation servers 180-A and 180-B can send a transformation report to the corresponding reporting system as described above.

[0145] Verify the integrity of the data on each aggregation server.

[0146] As described above, at the start of process 300, for each display, aggregation server 180-A receives display data (M) in key-value pairs. i For three-stage encrypted display data (ImpressionData) 3p Each key-value pair may include a blindly signed display key (BlindlySignedKey(ID, dc_destination, report_domain)) used for the display. The display data is encrypted three times (ImpressionData). 3p The final encryption is a probabilistic encryption using the public key of aggregation server 180-B. Therefore, no party other than aggregation server 180-B can decrypt the triple-encrypted impression data. 3pThe three encrypted data displays may be cryptographic random numbers for all servers except aggregation server 180-B.

[0147] Furthermore, no party other than application 112 knows the plaintext value of the user identifier (ID). The only information the colluding parties can recover is that the anonymous user behind the blindly signed display key (BlindlySignedKey(ID, dc_destination, report_domain)) has multiple displays with unknown characteristics. The colluding parties cannot infer the total number of displays that application 112 / client device 110 / user has seen because the entire digital component's display is sharded by the destination (dc_destination) and the report domain (report_domain).

[0148] If it is known that there is a problem with the number of displays shown to the user associated with the blindly signed display key (BlindlySignedKey(ID, dc_destination, report_domain)), application 112 may repeatedly send the display data (M) for the display at random or pseudo-random intervals. i Assuming that three encrypted impression data are generated (ImpressionData) 3p When applying probabilistic encryption, the aggregation server 180-A and any colluding party cannot perform deduplication on the received display data. However, the aggregation server 180-B can decrypt the three-times encrypted display data (ImpressionData). 3p Then, duplicate data is removed from the display to restore the secondary encrypted display data (ImpressionData2).

[0149] As described above with reference to process 300, at the beginning of step 310 of process 300, aggregation server 180-A receives the pair {H(BlindlySignedKey, Key...} from aggregation server 180-B. c ), ConversionData 3p}, where the pair cannot be related to the content possessed by aggregation server 180-A in step 302, namely, the key-value pair {(BlindlySignedKey(ID, dc_destination, report_domain)), ImpressionData 3p} connection. Furthermore, the blind signature key H(BlindlySignedKey, Key cThis may only be valid for each execution of the MPC process, and the aggregation server 180-B may discard the selected key after each execution. c1 and Key c2 The aggregation server 180-A can use its public key to decrypt three-times encrypted conversion data (ConversionData). 3p ), to recover the second-order encrypted conversion data (ConversionData2). At this time, aggregation server 180-A has H(BlindlySignedKey, Key c Both the first and second encrypted conversion data (ConversionData2) are encrypted, and only the aggregation server 180-B has the decryption key. As long as aggregation server 180-B is honest, aggregation server 180-A cannot do anything that jeopardizes user privacy.

[0150] At the beginning of step 314 of process 300, for each presentation, aggregation server 180-A receives a secondary encrypted blind signature connection key from aggregation server 180-B. ) and three-fold encrypted display data (ImpressionData) 3’ The three encrypted impression data (ImpressionData) 3’ Finally, encryption is performed using a key owned by aggregation server 180-B, which is only valid for the current execution of the MPC process. The worst thing aggregation server 180-A can do without collusion with aggregation server 180-B is to send a spoofed data tuple {count', ImpressionData}. 3’ ', ConversionData 2’ '} instead of the actual data tuple {count, ImpressionData 3’ ConversionData 2’}

[0151] Figure 5 This is a flowchart illustrating an example process 500 for verifying data integrity. Specifically, process 500 can be executed by one of aggregation servers 180-A and 180-B, in accordance with the MPC process described in this document (e.g., Figure 3 and Figure 4During the MPC process (or the MPC process described below), the integrity of data received from another of aggregation servers 180-A and 180-B is verified. For ease of description, process 500 is described as aggregation server 180-B verifying the integrity of data received from aggregation server 180-A. However, aggregation server 180-A may perform a similar process to verify the integrity of data received from aggregation server 180-B.

[0152] This process 500 can be used to prevent various types of fraud, including the following situation: one of the aggregation servers 180-A and 180-B colludes with the fraud detection system 172, the conversion system 172, and the reporting system 190.

[0153] Aggregator server 180-B verifies the data received from aggregation server 180-A (502). Aggregator server 180-B may execute step 502 as part of step 324 of process 300. (See above for reference.) Figure 3 As described in step 318, the aggregation server 180-A can process data of the form {count, ImpressionData}. 3’ ConversionData 2’ The tuples are sent to the aggregation server 180-B. The aggregation server 180-B can encrypt the secondary encryption conversion data (ConversionData) in each tuple. 2’ In order to generate three encrypted conversion data (ConversionData) for each tuple. 2’ This is made possible by the definition of ConversionData3, which uses the public key of the aggregation server 180-A to perform deterministic public key encryption on the result of ConversionData3.

[0154] Aggregator server 180-B can process each received tuple {count, ImpressionData} 3’ ConversionData 2’} transforms into {count, ImpressionData} 3’ ConversionData 3’}, and after applying thresholding and downsampling to achieve k-anonymity and differential privacy, the comparison aggregation server 180-B in Figure 3 The resulting dataset generated in step 316. For example, aggregation server 180-B can generate a tuple {count, ImpressionData}. 3’ ConversionData3’ The datasets are compared with the rows in Table 2. If the two datasets match, then aggregation server 180-B can be confident that aggregation server 180-A has been honestly executing the cryptographic protocol until... Figure 3 Step 322. Otherwise, Aggregator Server 180-B may terminate the MPC process prematurely and / or report a possible failure of Aggregator Server 180-A.

[0155] As described in reference process 300 above, at the beginning of step 322, aggregation server 180-A receives data from aggregation server 180-B in the form {count, ImpressionData2, ConversiodData}. 3’ The aggregation server 180-A can obtain its own dataset generated in step 314 of process 300 after applying thresholding and downsampling. This dataset includes tuples of the form {count, ImpressionData}. 3’ ConversiodData 3’ Rows (e.g., rows in Table 2) or tuples from the dataset. The aggregation server 180-A can use this data to infer the three-dimensional encrypted impression data (ImpressionData) from the two datasets. 3’ The mapping between the encrypted display data (ImpressionData2) and the secondary encrypted display data.

[0156] Similar to Aggregator Server 180-B, Aggregator Server 180-A can use the public key of Aggregator Server 180-B to verify triple-encrypted ImpressionData. 3’ It is indeed the result of deterministic public-key encryption of the second-order encrypted display data (ImpressionData2). However, due to the design of the public-key encryption algorithm, given the third-order encrypted display data (ImpressionData... 3’ In the case of the mapping between the first and second encrypted presentation data (ImpressionData1), aggregation server 180-A cannot recover the private key of aggregation server 180-B. The worst thing aggregation server 180-A can do is send a fake data tuple {count', ImpressionData1', ConversionData2'} to aggregation server 180-B instead of the actual data tuple {count, ImpressionData1, ConversionData2}.

[0157] Aggregator server 180-B verifies the integrity of the data received from aggregation server 180-A (504). Aggregator server 180-B can use a deterministic public-key algorithm and the public key of aggregation server 180-A to re-encrypt the encrypted presentation data (ImpressionData1) into secondary encrypted presentation data (ImpressionData2). Aggregator server 180-B can use a deterministic public-key algorithm and the public key of aggregation server 180-A to re-encrypt the secondary encrypted conversion data (ConversionData2) into tertiary encrypted presentation data (ConversionData3). Then, aggregation server 180-B can use the encryption results to transform each tuple {count, ImpressionData1, ConversionData2} received from aggregation server 180-A in step 322 of process 300 into a tuple of the form {count, ImpressionData1, ConversionData2}.

[0158] Then, aggregation server 180-B can compare the resulting dataset of this tuple with the dataset that aggregation server 180-B generated and sent to aggregation server 180-A in step 320 of process 300. If the two datasets match, aggregation server 180-B can be confident that aggregation server 180-A has been honestly executing the cryptographic protocol so far in the MPC process of process 300. Otherwise, aggregation server 180-B may prematurely terminate the MPC process and / or report a possible failure of aggregation server 180-A.

[0159] As described above with reference to process 300, at the beginning of step 326 of process 300, aggregation server 180-A receives the tuple {count, ImpressionData2, ConversionData1} from aggregation server 180-B. If aggregation server 180-A does not honestly decrypt the double-encrypted presentation data (ImpressionData2) into single-encrypted presentation data (ImpressionData1) and send the correct tuple {count, ImpressionData1, ConversionData1} to reporting system 190 in step 326 of process 300, then reporting system 190 will detect a difference between the two conversion reports received from aggregation servers 180-A and 180-B. Reporting system 190 may report the difference to at least one of aggregation servers 180-A and 180-B. The most important information that aggregation server 180-A can disclose to reporting system 190 (which can understand the disclosed information) without collusion with reporting system 190 includes the conversion data for each tuple and a histogram of the count. However, the user privacy of this data is subject to threshold requirements and differential privacy downsampling protection applied in steps 314 and 316 of process 300.

[0160] Generate sequences for display and transformation

[0161] Figure 6 This is a flowchart illustrating an example process 600 for generating a chronological sequence of events while protecting user privacy. Process 600 can be used to generate a chronological sequence of presentations and / or transitions, wherein the chronological sequence can be used to support different transition attribution models, such as last-click attribution or rule-based attribution. Process 600 can be executed by aggregation servers 180-A and 180-B.

[0162] Similar to process 300, each of aggregation servers 180-A and 180-B can individually select a secret encryption key pair. i (It represents a key pair) and Key c (This represents a key pair). The aggregation server 180-A can also select a secret key. i, skew Similarly, the aggregation server 180-B can select a secret key. c, skew Aggregator Server 180-A and Aggregator Server 180-B can periodically select new keys based on specified time periods, batches of displayed or transformed data, or other appropriate criteria.

[0163] Aggregator server 180-A receives display data (602). In this example, the display data for each display may include a blindly signed display key (BlindlySignedKey(ID, dc_destination, report_domain)) and triple-encrypted display data (ImpressionData). 3p The blind signature display key and triple-encrypted display data (ImpressionTime2) can be the same as or similar to the blind signature display key and triple-encrypted display data of process 300. The display time data indicates the time when the display occurs and can be encrypted.

[0164] The display time data (ImpressionTime2) can be generated using the public key S of the aggregation server 180-A. i It uses the public key of the aggregation server's 180-B protocol for secondary encryption. For example, the display time data (ImpressionTime2) can be defined as (PubKeyEncrypt(T(t)). m + t device ), S i ), S c In this example, t m It is the time of display or click (e.g., the time when a digital component is presented or interacted with), and t device This refers to the clock skew of client device 110 on which application 112, which presents digital components, is installed. In this example, the sum of the two times is calculated using encryption technology T and the public key S of aggregation server 180-A. i To encrypt, the encryption technique T can be a homomorphic additive probabilistic public-key encryption technique (e.g., the Paillier cryptosystem). The encrypted value is then encrypted using the public key S of the aggregation server 180-B. c This second encryption can be either deterministic or probabilistic encryption techniques.

[0165] The aggregation server 180-B receives the conversion data (604). In this example, the conversion data may include a blindly signed conversion key (BlindlySignedKey(ID, conversion_domain, report_domain)) and three-stage encrypted conversion data (ConversionData). 3p The blind signature conversion key and the triple-encrypted conversion data can be the same as or similar to the blind signature conversion key and the triple-encrypted conversion data of process 300. The conversion time data indicates when the conversion occurred and can be encrypted.

[0166] The conversion time data (ConversionTime2) can be obtained using the public key S of the aggregation server 180-A. i The public key S of the aggregation server 180-B c This allows for secondary encryption. For example, conversion time data (ConversionTime2) can be encrypted using (PubKeyEncrypt(T(z...)). n + t device ), S c ), S i () indicates. In this example, z n It is the conversion time (e.g., the time when the conversion is completed), and t device This refers to the clock skew of client device 110, on which application 112, which presents digital components, is installed. In this example, the sum of the two times is calculated using encryption technology T and the public key S of aggregation server 180-B. c To encrypt, the encryption technique T can be a homomorphic additive probabilistic public-key encryption technique (e.g., the Paillier cryptosystem). The encrypted value is then encrypted using the public key S of the aggregation server 180-A. i This second encryption can be either deterministic or probabilistic encryption techniques.

[0167] For each display, the aggregation server 180-A uses exchange encryption and its chosen encryption key Key. i1 To encrypt the connection key (606). Similar to process 300, the connection key used for the presentation can be a blind-signed connection presentation key (BlindlySignedKey(ID, dc_destination, report_domain)). Then, for each presentation, the aggregation server 180-A can encrypt the connection key, triple-encrypt the presentation data (ImpressionData). 3p The aggregation server 180-B is provided with the secondary encrypted display time data (ImpressionTime2). In other words, for each display, the aggregation server 180-A can send the tuple: {H(BlindlySignedKey, Key...}} i1 ), ImpressionData 3p ,ImpressionTime2}. Tuples can be sent in a random or pseudo-random order.

[0168] For each conversion, the aggregation server 180-B uses the exchange encryption and its chosen encryption key, Key. c1To encrypt the connection key (608). Similar to process 300, the connection key used for the conversion is the blindly signed conversion key (BlindlySignedKey(ID, conversion_domain, report_domain)). Then, for each conversion, the aggregation server 180-B can encrypt the connection key, the three-stage encrypted conversion data (ConversionData). 3p The aggregation server 180-A is provided with the secondary encrypted conversion time data (ConversionTime2). In other words, for each conversion, the aggregation server 180-B can send the tuple: {H(BlindlySignedKey, Key...}} c ), ConversionData 3p ,ConversionTime2}. Tuples can be sent in a random or pseudo-random order.

[0169] For each received tuple, aggregation server 180-A decrypts the conversion time data (610). Aggregation server 180-A can use the public key S of aggregation server 180-A. i The corresponding private key is used to decrypt the conversion time data (ConversionTime2). This decryption recovery (T(z) n + t device ), S c ).

[0170] The Aggregator Server 180-A can also use its selected encryption key. i2 The key H (BlindlySignedKey, Key) is revealed after the encrypted blind signature has been exchanged. c The exchange encryption is applied on top of this. The result is a cryptographic blind signature key. .

[0171] The aggregation server 180-A can calculate the time skew value. i For example, the aggregation server 180-A can calculate the secret key Key. i, skew And the HMAC of the cryptographic blind signature transformation key (e.g., HMAC) SHA256 (Key i, skew , ) as the time skew value i ).

[0172] Then, for each received tuple, the aggregation server 180-A can generate single-pass encryption conversion time data (ConversionTime1). In some implementations, the single-pass encryption conversion time data (ConversionTime1) is generated using homomorphic additive probabilistic public-key encryption technique T (e.g., T(z)). n + t device + time_skew i , S c It is generated by ) . In this example, the conversion time (z n ), clock skew of client devices (t) device ) and time skew value (time_skew) i The sum of ) uses the public key S of aggregation server 180-B. c To encrypt.

[0173] As described in step 310 of reference process 300 above, the aggregation server 180-A can also decrypt and re-encrypt the three-times encrypted conversion data (ConversionData). 3p In other words, the aggregation server 180-A can use its private key (compared to the public key S). i The corresponding private key is used to decrypt the three-stage encryption conversion data (ConversionData). 3p This is used to recover the second-order encrypted conversion data (ConversionData2). Then, the aggregation server 180-A can use its chosen encryption key Key. i2 To re-encrypt the second-level encrypted conversion data (ConversionData2), in order to obtain the third-level encrypted conversion data (ConversionData). 3p ).

[0174] For each unique triple-encrypted conversion data (ConversionData) 3p The aggregation server 180-A can identify the three-stage encrypted conversion data (ConversionData). 3p The associated unique cryptographic blind signature conversion key The quantity. If the data used for conversion is encrypted with three layers of conversion data (ConversionData). 3p The associated unique cryptographic blind signature conversion key If the number of elements reaches a threshold (e.g., based on threshold processing requirements), then aggregation server 180-A will process the tuple { ConversionData 3p ,ConversionTime1} is sent to the aggregation server 180-B.

[0175] For each received tuple, Aggregator 180-B decrypts and displays the time data (612). Aggregator 180-B can use the public key S of Aggregator 180-B. c The corresponding private key is used to decrypt and display the time data (ImpressionTime2). This decryption and recovery (T(t) m + t device ), S i ).

[0176] The aggregation server 180-B can also use its selected encryption key. c2 After exchanging encrypted blind signature conversion keys H(BlindlySignedKey, Key) i The exchange encryption is applied on top of this. The result is a cryptographic blind signature key. .

[0177] The aggregation server 180-B can calculate the time skew value. c For example, the aggregation server 180-B can calculate the secret key Key. c, skew And the HMAC of the cryptographic blind signature transformation key (e.g., HMAC) SHA256 (Key c, skew , ) as the time skew value c ).

[0178] Then, for each received tuple, the aggregation server 180-B can generate single-instance encrypted impression time data (ImpressionTime1). In some implementations, the single-instance encrypted impression time data (ImpressionTime1) uses homomorphic additive probabilistic public-key encryption technology T (e.g., T(t)). m + t device + time_skew c , S i This is generated using time (t). In this example, the display time (t) m ), clock skew of client devices (t) device ) and time skew value (time_skew) c The sum of ) uses the public key S of aggregation server 180-A. i To encrypt.

[0179] As described in step 312 of reference process 300 above, the aggregation server 180-B can also decrypt and re-encrypt the triple-encrypted display data (ImpressionData). 3pIn other words, the aggregation server 180-B can use its private key (compared to the public key S). c The corresponding private key is used to decrypt the three-times encrypted display data (ImpressionData). 3p This is used to recover the secondary encrypted display data (ImpressionData2). Then, the aggregation server 180-B can use its chosen encryption key Key. c2 To re-encrypt the secondary encrypted display data (ImpressionData2), in order to obtain the tertiary encrypted display data (ImpressionData). 3p ).

[0180] For each unique triple-encrypted display data (ImpressionData) 3p The aggregation server 180-B can identify the three-times encrypted display data (ImpressionData). 3p The associated unique cryptographic blind signature conversion key The quantity. If used for display with three-fold encrypted display data (ImpressionData). 3p The associated unique cryptographic blind signature conversion key If the number of elements reaches a threshold (e.g., based on differential privacy threshold requirements), then the aggregation server 180-B will store the tuple { ,ImpressionData3,ImpressionTime1} are sent to aggregation server 180-A.

[0181] Aggregator server 180-A connects to and filters encrypted display and encrypted conversion data received from aggregation server 180-B (614). Aggregator server 180-A can then process tuples received from aggregation server 180-B... ImpressionData3, ImpressionTime1} and the aggregation server 180-A use the cryptographic blind signature key in step 610 ( The generated tuple { ConversionData 3p , ConversionTime1} concatenation. For each cryptographic blind signature key ( ), Aggregator server 180-A in including { ImpressionData 3p , ImpressionTime1, ConversionData 3p The table , ConversionTime1} forms tuples or rows.

[0182] Since application 112 can report multiple presentations for the same digital component, therefore for each cryptographic blind signature key ( In this case, multiple occurrences of the displayed data (ImpressionData3) are possible. This applies to data with the same cryptographic blind signature key. And the same three-times encrypted conversion data (ConversionData) 3p ImpressionData is displayed three times in each of the three encryption methods. 3p The aggregation server 180-A can use its public key S i To decrypt the single encrypted display time data (ImpressionTime1) to obtain the unencrypted time data (ImpressionTime0), which includes t' m = t m + t device + time_skew c The aggregation server 180-A does not know time_skew. c The value of . If the same device attribution is being used, the device's clock skew (t) device The value is fixed, but unknown for the aggregation server 180-A. If cross-device attribution is being used, then for the same cryptographic blind signature key ( The clock skewness (t) of the associated different display devices device The values ​​can differ because the data can come from multiple devices and is unknown to the aggregation server 180-A. In either case, the aggregation server 180-A cannot obtain the data from t' m Inferred display / click time (t) m Therefore, it is not easy to launch time-based attacks to track users.

[0183] The aggregation server 180-A can determine the display time (ImpressionTime0) as t. m + t device + time_skew c + time_skew i For the linked display data (ImpressionData) 3p ) and Conversion Data 3p For each combination of ), the aggregation server 180-A can determine a unique cryptographic blind signature key ( Does the number of tuples reach or exceed a threshold (e.g., a k-anonymity privacy threshold)? If so, then for the combination, the aggregation server 180-A can assign the tuple {( ), ImpressionData 3p The ImpressionTime0 is sent to the aggregation server 180-B. In some implementations, the aggregation server 180-A may also use downsampling techniques for differential privacy, as described above with reference to process 300.

[0184] Aggregator server 180-B also connects to and filters encrypted display data and encrypted transformation data received from aggregation server 180-A (616). Aggregator server 180-B can process tuples received from aggregation server 180-A { ConversionData3, ConversionTime1} and the aggregation server 180-B use the cryptographic blind signature key in step 612 ( The generated tuple { The concatenation of ImpressionData3 and ImpressionTime1 is performed. For each cryptographic blind signature key ( ), Aggregator server 180-A in including { ImpressionData 3p , ImpressionTime1, ConversionData 3p The table ,ConversionTime1} forms tuples or rows.

[0185] For those with the same cryptographic blind signature key ( And the same three-times encrypted conversion data (ConversionData) 3p ImpressionData is displayed three times in each of the three encryption methods. 3p The aggregation server 180-B can use its public key S c To decrypt the single encrypted conversion time data (ConversionTime1) to obtain the unencrypted time data (CompressionTime0), which includes t' m = t m + t device + time_skew i .

[0186] The aggregation server 180-B can determine the conversion time (ConversionTime0) as z. n + t device + time_skew i + time_skew c For the linked display data (ImpressionData)3p ) and Conversion Data 3p For each combination of ), the aggregation server 180-B can determine a unique cryptographic blind signature key. Does the number of tuples reach or exceed a threshold (e.g., a k-anonymity privacy threshold)? If so, then for the combination, the aggregation server 180-B can store the tuple {( ), ConversionData 3p The `ConversionTime0` is sent to the aggregation server 180-A. In some implementations, the aggregation server 180-B may also use downsampling techniques for differential privacy, as described above with reference to process 300.

[0187] At this point, both aggregation server 180-A and aggregation server 180-B can use the cryptographic blind signature key. To connect and transform the data and time of both, for each unique cryptographic blind signature key. To form a record in the following form: {( ImpressionData 3p , ImpresionTime0, ConversionData 3p , ConversionTime0}.

[0188] The aggregation server 180-A generates the time sequence of display and conversion (618). For each unique cryptographic blind signature key ( The aggregation server 180-A can be used for each piece of impression data. 3p The display time (ImpressionTime0) and the data used for each conversion (ConversionData) 3p The conversion time (ConversionTime0) is compared to the time used to generate the cryptographic blind signature key. (Multiple) displays and (multiple) transformations in a chronological sequence.

[0189] The aggregation server 180-B generates the time sequence for display and conversion (620). For each unique cryptographic blind signature key ( The aggregation server 180-B can be used for each piece of impression data. 3p The display time (ImpressionTime0) and the data used for each conversion (ConversionData) 3pThe conversion time (ConversionTime0) is compared to the time used to generate the key for cryptographic blind signature. (Multiple) displays and (multiple) transformations in a chronological sequence.

[0190] Due to each unique cryptographic blind signature key ( ) corresponds to a specific digital component and a specific unique identifier (ID), therefore used for cryptographic blind signature keys ( The chronological sequence includes (e.g., at one or more devices of a user corresponding to a unique identifier) ​​one or more displays of a digital component for the unique identifier and one or more transitions resulting from the presentation of a particular digital component. For example, if a particular digital component is presented to the same user multiple times, the sequence may include multiple displays, and the sequence may include multiple transitions of different types (e.g., one transition for adding an item to a virtual shopping cart and another transition for completing the retrieval of an item).

[0191] These temporal sequences allow aggregation servers 180-A and 180-B to independently perform attribution processes to attribute conversions to impressions. For example, in a last-click attribution model, aggregation servers 180-A and 180-B can identify the last impression for clicks preceding a conversion in the sequence and attribute the conversion to that last impression. Aggregation servers 180-A and 180-B can also validate each other's results (e.g., by comparing their results with those of another aggregation server). Although Figure 6 Not shown, but Aggregator Server 180-A and Aggregator Server 180-B can work together to decrypt, display, and transform data, as referenced above. Figure 3 Steps 318 to 332 are described. Aggregation Server 180-A and Aggregation Server 180-B can report attribution along with other data in the transformation report.

[0192] Additional steps can be taken to prevent or detect time-interval-based attacks. For the same cryptographic blind signature key ( For multiple associated displays / clicks, the aggregation server 180-A will have t' m Where m is an integer. Assume t' m Sort by time from earliest to latest, the aggregation server 180-A can calculate the time interval δ' between two adjacent displays, for example, δ' m = t' m+1 - t' m Assume t device If it is small enough, then δ' m δm =t' m+1 - t' m If a digital component distribution system provides a series of displays to a user, the system can record the time interval between two adjacent displays, i.e., δ. m Based on the above, if the digital component distribution system colludes with aggregation server 180-A, the digital component distribution system may be able to identify individual users based on time intervals. If the digital component distribution system colludes with aggregation server 180-B, the digital component distribution system can also launch similar time-interval-based attacks.

[0193] One option to prevent these time-interval-based attacks is to use a monotonically increasing function Γ, which has the following property: Given two arbitrary numbers a and b, the two values ​​a – b and Γ(a) – Γ(b) are uncorrelated. That is, knowing a – b does not help in predicting Γ(a) – Γ(b), and vice versa.

[0194] The display time data (ImpressionTime2) can be defined using the function Γ as PubKeyEncrypt(T(Γ(t)). m + t device ), S i ), S c In this example, δ' m = Γ(t m+1 + t device + skew) - Γ(t m +t device + skew). Therefore, δ' m ≠ δ m Furthermore, time-based attacks were disrupted.

[0195] Another option to prevent time-interval-based attacks is to modify process 600 to include a dedicated time server 192. At the start of process 600, aggregation server 180-A receives data in the form {BlindlySignedKey(ID, dc_destination, report_domain), ImpressionData}. 3p , T(t m + t device , S time The display data is shown in this example. The display / click time t is also shown. m and the device's clock deviation t device The sum of the public key S used by the time server 192 timeTo encrypt. For example, application 112 or client device 110 can use the public key S time To encrypt time data. Similarly, the aggregation server receives data in the form of {BlindlySignedKey(ID, conversion_domain, report_domain), ConversionData} in 180-B format. 3p , T(z n + t device , S time The conversion data is as follows. In this example, the conversion time z... n and the device's clock deviation t device The sum of the public key S used by the time server 192 time To encrypt. For example, application 112 or client device 110 can use the public key S time To encrypt time data.

[0196] In the modified step 606, the aggregation server 180-A can be changed to use the form {H(BlindlySignedKey,S i ), ImpressionData 3p , T(t m + t device , S time The tuple of} is sent to aggregation server 180-B. That is, aggregation server 180-A can use the secret key S i Use the encrypted blind signature key and transmit the presentation and time data as is.

[0197] Similarly, in the modified step 608, the aggregation server 180-B can be changed to use the form {H(BlindlySignedKey, S...} c ), ImpressionData 3p , T(z n + t device , S time The tuple of )} is sent to aggregation server 180-A. That is, aggregation server 180-B can use the secret key S c Use the encrypted blind signature key and transmit the presentation and time data as is.

[0198] In the modified step 610, the aggregation server 180-A can generate a data structure of the form {H(BlindlySignedKey),ConversionData3, T(z)}. n + t device + time_skew i , Stime The tuple of )} is sent to the aggregation server 180-B. In this example, the conversion data (ConversionData) 3p The probabilistic encryption used in the application is replaced with deterministic encryption to create (ConversionData3). Furthermore, the aggregation server 180-A can add random noise to the encrypted display time, where the noise is based on H (BlindlySignedKey) and the secret key S. i This is derived from the above. Similarly, in step 612, aggregation server 180-B can generate a dataset of the form {H(BlindlySignedKey), ImpressionData3, T(t...}}. m +t device + time_skew c , S time The tuple is sent to the aggregation server 180-A.

[0199] In the modified step 614, the aggregation server 180-A can connect to and filter the dataset, as described in the original step 614 of reference process 600 above. The aggregation server 180-A can determine the encrypted impression time value (ImpressionTime). 3_skew Instead of setting the display time (ImpressionTime0) as t m + t device + time_skew c + time_skew i For example, encrypting the display time value (ImpressionTime). 3_skew ) can be defined as T(t) m +t device + time_skew c + time_skew i , S time In other words, the encrypted display time value (ImpressionTime) 3_skew The public key S is obtained using homomorphic additive probabilistic public-key encryption technology T and time server 192. time The sum of encrypted time values.

[0200] For each combination of the concatenated impression data (ImpressionData3) and conversion data (ConversionData3), the aggregation server 180-A can determine a unique cryptographic blind signature key. Does the number of tuples reach or exceed a threshold (e.g., a difference privacy threshold)? If so, then for the combination, the aggregation server 180-A can process the tuple {( ), ImpressionData3, ImpressionTime 3_skew Send to aggregation server 180-B.

[0201] In the modified step 616, the aggregation server 180-B can join and filter the dataset, as described above with reference to the original step 616 of the original process 600. The aggregation server 180-B can determine the encryption conversion time value (ConversionTime). 3_skew Instead of determining the conversion time (ConversionTime0) as z n + t device + time_skew c + time_skew i For example, the encryption conversion time value (ConversionTime). 3_skew ) can be defined as T(z) n +t device + time_skew c + time_skew i , S time In other words, the encryption conversion time value (ConversionTime). 3_skew The public key S is obtained using homomorphic additive probabilistic public-key encryption technology T and time server 192. time The sum of encrypted time values.

[0202] For the display data of the connection (ImpressionData) 3p For each combination of ) and conversion data (ConversionData3), the aggregation server 180-B can determine a unique cryptographic blind signature key ( Does the number of tuples reach or exceed a threshold (e.g., a difference privacy threshold)? If so, then for the combination, the aggregation server 180-B can store the tuple {( ), ConversionData3, ConversionTime 3_skew Send to aggregation server 180-A.

[0203] At this point, both aggregation server 180-A and aggregation server 180-B can use the cryptographic blind signature key. To connect and transform the data and time of both, for each unique cryptographic blind signature key. To form a record in the following form: { ,ImpressionData3,ImpressionTime 3_skew , ConversionData3, ConversionTime 3_skew}

[0204] In the presence of the same or multiple cryptographic blind signature keys Within each record comprised of multiple related impression data (ImpressionData3) and conversion data (ConversionData3), the aggregation server 180-A can assign random or pseudo-random indexes to the encryption time value (ImpresionTime). 3_skew and ConversionTime 3_skew Aggregator server 180-A can send these indexes and encrypted time values ​​(but not blind signature keys or displayed or transformed data) together to time server 192. Time server 192 can then use them with public key S time The corresponding private key is used to decrypt the encrypted time values, these decrypted but triple-skewed time values ​​are sorted, and the index is sent back to the aggregation server 180-A in chronological order.

[0205] In this way, time server 192 cannot access any user data. Time server 192 cannot even access the destination of the triple-skewed time values, or whether the set of triple-skewed time values ​​matches the same cryptographic blind signature key. Related. Without collusion with aggregation server 180-A, time server 192 cannot launch time-based or time-interval-based attacks.

[0206] For each record, aggregation server 180-A can sort the impression data (ImpressionData3) and conversion data (ConversionData3) using an index corresponding to the encrypted time value of the data. Through this sorting, aggregation server 180-A can perform an attribution process to attribute conversions to impressions, as described above. Aggregation server 180-B can perform the same process to assign indexes to encrypted time values ​​and interact with time server 192 to sort the data for attribution. Once both aggregation servers 180-A and 180-B have completed this process, they can compare the results.

[0207] Data-driven attribution

[0208] The MPC process described in this document (e.g., Figure 3The process 300 can be adapted to support Data-Driven Attribution (DDA). Data-driven attribution assigns credit to digital components, activities, and / or search keywords used for conversions based on user actions. For example, DDA can use conversion data to calculate the actual contribution of each keyword on the conversion path that led to the conversion. This works by reporting the complete path that reaches an aggregation threshold to a reporting system 190 for subsequent processing to apply credit.

[0209] Figure 7 This is a flowchart illustrating an example process 700 for using data-driven attribution to attribute a transformation. Process 700 can be... Figure 1 and Figure 2 The aggregation servers 180-A and 180-B are executed.

[0210] To track DDA, the digital component and / or conversion system 190 can notify the application 112 of the client device 110 to enable DDA (702). When enabling DDA, the application 112 can modify the definition of the blindly signed connection key to consider whether the digital component has been clicked or otherwise interacted with. For a clicked display of a digital component, the application 112 can modify the definition of the blindly signed display key (BlindlySignedKey(ID, dc_destination, report_domain)) for each display to BlindlySignedKey(ID || clicked, dc_destination, report_domain). In this definition, the blindly signed display key is a complex message that includes a one-way cryptographic hash function, where the function maps the complex message (ID || clicked, dc_destination, report_domain) to a blind signature (blind_singature) and hash value used for the blindly signed display key. When DDA only considers clicked (or interacted) displays, the clicked parameter will always be true or have a value of 1.

[0211] Receive impression data and conversion data (704). For example, as described above, aggregation server 180-A can receive impression data, and aggregation server 180-B can (e.g., in batches) receive conversion data. When application 112 reports an impression as described above, application 112 can include a blindly signed connection key and triple-encrypted impression data. 3p The display data M) iSend to aggregation server 180-A. Similarly, when application 112 reports the conversion as described above, application 112 can send the conversion data, including the blindly signed connection key and the three-stage encrypted conversion data. 3p Transformed data M c Send to aggregation server 180-B. In this example, the blind signature key is a modified version that takes into account the clicked parameter.

[0212] Generate a sequence for display and transformation (706). Before generating the sequence, each of aggregation servers 180-A and 180-B can join and filter data, as described above in steps 306 to 316 of reference process 300. After joining and filtering are complete, for each unique blindly signed join key associated with a given user, each aggregation server has a record of the following form: {ImpressionData} 3,1 ImpressionData 3,2 ImpressionData 3,i …, ConversionData3}. In this form, the presentation and conversion can be ordered chronologically. This chronologically ordered sequence of the connection key used for blind signing can be called a Sequence.

[0213] For each unique sequence, aggregation servers 180-A and 180-B determine the number (708) of blindly signed join keys that have unique sequences. For example, prior to a conversion event, multiple users might have clicked on the same numeric component in the same order. In this case, for each user, the sequence displayed and converted will have a unique blindly signed join key.

[0214] Sequences are filtered (710). For example, each of aggregation servers 180-A and 180-B can filter sequences based on privacy or other threshold processing requirements. In a specific example, aggregation servers 180-A and 180-B can filter out each sequence from the sequences that does not have at least a threshold number of unique blindly signed join keys. The result is determined by {Occurrence} m Sequence mFor a list consisting of m, where m = 1, 2, … M.

[0215] Decrypt the presentation and transformation data (712). The presentation and transformation data can be decrypted using the MPC process in steps 318 to 328 of process 300. Decryption produces a tuple of the following form: {Occurrence1, ImpressionData} 1,1 , … ImpressionData 1,? ConversionData 1,1},{Occurrence2,ImpressionData 1,2 , … ImpressionData 1,? ConversionData 1,2 Each tuple includes a sequence of displayed and transformed data that are encrypted once using the public key in report field 190.

[0216] The displayed and transformed data is sent to its corresponding reporting system (714). The reporting system 190 can then apply its DDA technology (e.g., Shapley value) to the final set of sequences to assign credits.

[0217] Because DDA is a cross-site report across multiple domains, the number of distinct sequences that can meet the threshold requirements may be small, especially if a large amount of information is encoded in impression data and / or conversion data, resulting in each impression data (ImpressionData) being... 3p Many different occurrences and conversion data (ConversionData) 3p Many different occurrences of ) can occur. In this case, differential privacy noise can be added to the number of occurrences for each sequence in the final measurement report to protect user privacy, which may be of low utility to digital component providers.

[0218] This utility can be achieved by reducing the amount of ImpressionData. 3p ) and / or conversion data (ConversionData) 3pThe entropy can be improved by expanding the reporting window while still protecting user privacy. If the order of the displayed data is not important, or duplicate displayed data can be ignored, the digital component provider can notify aggregation servers 180-A and 180-B at the conversion site. In this case, aggregation servers 180-A and 180-B will count the number of unique blindly signed join keys associated with each Set (Sequence) and apply thresholding and downsampling accordingly.

[0219] Determine the aggregation transformation value

[0220] The MPC process described in this document (e.g., Figure 3 The process (300) can be adapted to support reporting conversion values ​​in addition to the number of conversions and impressions. For each conversion, advertisers can attach a numerical conversion value, such as the amount spent on the digital component provider's website. Assume that for a given pair of impressions and conversions, there exist n conversions {V1, V2, … V} with corresponding numerical conversion values ​​attached. n The number of conversions is... The total conversion value is The sum of squares of the transformed values ​​is The average value of the transformed values ​​is And the variance is To compare the effects of two activities, we can assume that the distribution of the transformed values ​​(if a transformation occurs) follows a normal distribution, and then compare whether there is a significant difference between the two normal distributions. For this, we need the second moment variance (A2). i,2 ).

[0221] To enable aggregation servers 180-A and 180-B to securely compute the transformation value (A1), a swap encryption technique H supporting numeric addition can be used. That is, for two arbitrary integer values ​​x and y, H(x + y) = HomomorphicAddition(H(x), H(y)). Given that reporting system 190 computes the transformation quantity A0, this is a secure way to obtain the total transformation value A1 in plaintext and calculate its average.

[0222] Figure 8 This is a flowchart illustrating an example procedure 800 for determining aggregate transformation values. Procedure 800 can be performed by... Figure 1 and Figure 2 The aggregation servers 180-A and 180-B are executed.

[0223] Receive presentation data and conversion data (802). For example, as described above, aggregation server 180-A can (e.g., in batches) receive presentation data from client devices, and aggregation server 180-B can (e.g., in batches) receive conversion data from client devices. When application 112 reports the presentation as described above, application 112 can include a blindly signed connection key and triple-encrypted presentation data. 3p The display data M) i Send to aggregation server 180-A.

[0224] Similarly, when application 112 reports the conversion as described above, application 112 may include the blindly signed key and the three-stage encryption conversion data. 3p Transformed data M c Send to aggregation server 180-B. In this example, the blind signature key is a modified version that takes into account the clicked parameter. However, in this example, for the transformation, the transformed data M... c It may also include the transformation value (V) and / or the square of the transformation value (V). 2 Generally speaking, transforming data M c It can include V i Any number of specified transformation values ​​V1, V2, … V n These V i One of them could be another V j The square of.

[0225] Application 112 can send an encrypted version of the value V i Instead of sending the actual value V i In some implementations, the transformation system 172 can encrypt the value V using a probabilistic homomorphic additive public key (e.g., the Pailler cryptosystem). i And H(V) i The values ​​are sent to application 112 along with the report domain (report_domain) that will receive the transformation report for the digital component, and are encrypted using encryption technology H.

[0226] Application 112 can receive H(V) i , report_domain), and generate one or more cubic encryption transformation values ​​and cubic encryption square transformation values. For example, application 112 can generate PublicKeyEncrypt(H(V i(report_domain), S c , S i The encrypted conversion value is used as the third encryption conversion value. In this example, the encrypted conversion value received from the conversion system 172 uses the public key S of the aggregation server 180-B. c To encrypt, and the result uses the public key S of aggregation server 180-A. i This is used for encryption. The three-stage encryption conversion value can also be called the ConversionValue. 3p Because three encryptions may be probabilistic.

[0227] Encrypting blind signature connection key (804). For example, aggregation server 180-A can use exchange encryption and its selected encryption key Key. i1 To encrypt the blindly signed connection key (BlindlySignedKey) in the received display data, as described in step 306 of reference process 300 above. Then, for each display, the aggregation server 180-A can assign the pair: {H(BlindlySignedKey, Key...} i1 ), ImpressionData 3p Send to aggregation server 180-B.

[0228] Similarly, the aggregation server 180-B can use exchange encryption and its chosen encryption key. c1 To encrypt the blindly signed join key in the received transformed data, as described in step 308 of reference process 300 above. Then, for each transformation, aggregation server 180-B can convert the tuple: {H(BlindlySignedKey, Key...} c1 ), ConversionData 3p ConversionValue 3p Send to aggregation server 180-A.

[0229] Decrypt Conversion Value 3p (806). For example, aggregation server 180-A can use public key S i The corresponding private key is used to decrypt the conversion value. 3p This will result in the recovery being handled by PubKeyEncrypt(H(V)). i (report_domain), S cThe second-order encryption conversion value (ConversionData2) is defined. The aggregation server 180-B can retain this second-order encryption conversion value (ConversionData2) locally.

[0230] Join and filter encrypted display data and encrypted transformation data (808). For example, each of the aggregation servers 180-B can join and filter data. In this example, aggregation server 180-A can use a blind signature key ( To join the conversion value (ConversionValue2), conversion data (ConversionData3), and impression data (ImpressionData3), similar to step 314 of process 300, but with the additional conversion value (ConversionValue2). Then, aggregation server 180-A can filter the joined records based on a threshold, similar to step 314 of process 300. For example, aggregation server 180-A can filter unique blind signature keys from the dataset (…). The number of connection records {ConversionValue2,ConversionData3, ImpressionData3} that failed to reach or exceed the threshold.

[0231] For each remaining join record, the aggregation server 180-A can generate a key / value pair. In this example, the key could be a blind signature key ( The key / value pair is a cryptographic hash of the three-fold encrypted impression data (ImpressionData3) and the three-fold encrypted conversion data (ConversionData3). The value can be a two-fold encrypted conversion value (ConversionValue2). This key / value pair can be defined as {CrytpoHash(H(Key), ImpressionData3,ConversionData3), ConversionValue2}. Aggregator server 180-A can send the key / value pair to aggregation server 180-B.

[0232] Aggregator server 180-B can perform the same filtering on its data to generate a dataset containing tuples {H(Key), ImpressionData3, ConversionData3} that are the same set remaining after filtering. Aggregator server 180-B can perform the same cryptographic hash on the tuples (e.g., CrytpoHash(H(Key), ImpressionData3, ConversionData3)) to obtain a key for each tuple. Aggregator server 180-B can concatenate this data with the key / value pairs received from aggregation server 180-A by matching the generated key with the key of the key / value pair.

[0233] Decrypt the second-level encrypted conversion value (ConversionValue2) (810). The aggregation server 180-B can use it with the public key S. c The corresponding private key is used to decrypt the secondary encrypted conversion value (ConversionValue2) to recover the single encrypted conversion value (ConversionValue1), which is single-encrypted using the public key of reporting system 190 as described above. Aggregator server 180-B can send each single encrypted conversion value (ConversionValue1) and its key (CrytpoHash(H(Key), ImpressionData3,ConversionData3)) to aggregation server 180-A.

[0234] Determine the total conversion value (812). For each record with the same impression data (ImpressionData3) and conversion data (ConversionData3), each of aggregation servers 180-A and 180-B can determine the total conversion value. That is, for each join combination of ImpressionData3 and ConversionData3, aggregation servers 180-A and 180-B can independently determine the sum of the conversion values ​​(ConversionValue1). Since the conversion values ​​are encrypted, the sum can be verified through... To determine.

[0235] The presentation data and conversion data, including the total conversion value, are sent to the reporting system (814). For example, aggregation servers 180-A and 180-B can use the MPC process described in steps 318 to 328 to decrypt the presentation data and conversion data. Then, each of aggregation servers 180-A can generate a report for each presentation and conversion pair and send it to the reporting system 190, wherein the report includes presentation data (ImpressionData1), conversion data (ConversionData1), a count of the number of conversions (count), and a conversion value (...). …( For example, there can be multiple sum values, one sum used to sum the transformed values, and another sum used to sum the squares of the transformed values, such as sum(V1) and sum(V2), where V2 = V1. 2 .

[0236] Reporting system 190 can compare two reports from two aggregation servers 180-A and 180-B to ensure that the two reports match. If the two reports match, reporting system 190 can verify the blind signature from fraud detection system 170 and the conversion server's conversion of the data m. c The signature. If both signatures are verified, the reporting system 190 can decrypt the data in the conversion report to recover {mi || clicked, m} for each display and conversion pair using the private key corresponding to the public key used to encrypt the data. c count, … In other words, the reporting system 190 can restore the displayed data (m). i ), whether the digital component was clicked, and the data conversion (m c ), the count of conversions, and the total conversion value for each display and conversion pair.

[0237] Differential privacy

[0238] Similar to process 300, downsampling can be used in process 800 to achieve differential privacy. In step 808 of process 800, aggregation servers 180-A and 180-B can use downsampling techniques similar to those in steps 314 and 316 of process 300 to convert the total value. Noise is introduced. Furthermore, Aggregator Server 180-A and Aggregator Server 180-B can add random noise to each transformation value before sending the transformation report. For each transformation value () Each of Aggregator Server 180-A and Aggregator Server 180-B can be changed to generate ( Both aggregation servers 180-A and 180-B can initialize the random number generator using a common seed derived jointly by aggregation servers 180-A and 180-B (e.g., using the Diffie-Hellman protocol), generating consistent noise. k ).

[0239] Additional user privacy protections for cross-device measurements

[0240] As described above, when determining display and conversion counts and conversion values ​​across multiple devices, a unique identifier (ID) can be information about the user or based on such information, such as a cryptographic hash of the user's email address. Using the above for ImpressionData... 3p ) and Conversion Data 3p The probabilistic encryption described herein allows Aggregator Servers 180-A and 180-B to determine a certain number of conversions for the user, but not to involve display or conversions themselves. However, Aggregator Servers 180-A and 180-B can detect some online activity of the user.

[0241] Figure 9 This is a flowchart illustrating an example process 900 for determining aggregated transformation data. Process 900 can be executed by aggregation server 180-A and aggregation server 180-B.

[0242] Receive display data and conversion data (902). For example, as described above, aggregation server 180-A can (e.g., in batches) receive display data from client devices, and aggregation server 180-B can (e.g., in batches) receive conversion data from client devices.

[0243] In this example, for each display of the digital component, the display data can be in the form of {H(CryptoHash(ID, dc_destination, report_domain), S}. time ), ImpressionData 3p In this example, the cryptographic hashes of the unique identifier (ID), destination (dc_destination), and report field are obtained using additive homomorphic public-key encryption H and the public key S of time server 192. time This is used for encryption. The cryptographic hash is used as the connection key. The data to be displayed also includes information as shown above. Figure 2Description of the encrypted three-fold encrypted display data (ImpressionData) 3p ).

[0244] For each transformation of the digital component, the transformation data can be in the form of {H(CryptoHash(ID, dc_destination, report_domain), S}. time ), ConversionData 3p In this example, the cryptographic hashes of the unique identifier (ID), destination (dc_destination), and report field are obtained using additive homomorphic public-key encryption H and the public key S of time server 192. time This is used for encryption. The cryptographic hash is used as the conversion join key. The conversion data also includes information as referenced above. Figure 2 Describes the three-stage encryption transformation of the data (ConversionData). 3p Due to the probabilistic nature of encryption technology H, neither aggregation server 180-A nor aggregation server 180-B can recover CryptoHash(ID, dc_destination, report_domain) or make H(CryptoHash(...)) meaningful without collusion with time server 192.

[0245] Select a random number (904). Aggregator Server 180-A and Aggregator Server 180-B can each select a random number before executing the MPC process to decrypt and transform the data. Aggregator Server 180-A can select a random number (nonce). i Furthermore, the aggregation server 180-B can select a random number nonce. c Both aggregation server 180-A and aggregation server 180-B can confidentially retain their respective random numbers.

[0246] Encrypted connection key (906). For example, the aggregation server 180-A can use exchange encryption and its chosen encryption key Key. i1 To encrypt the connection key H(CryptoHash(...)) in the received display data, as described in step 306 of reference process 300 above. Then, for each display, aggregation server 180-A can assign the following key to the connection key: {H(CryptoHash(ID,dc_destination, report_domain) + nonce}. i , S time ), ImpressionData 3p Send to aggregation server 180-B.

[0247] Similarly, the aggregation server 180-B can use exchange encryption and its chosen encryption key. c1 The connection key H(CryptoHash(...)) in the received transformed data is encrypted, as described in step 308 of reference process 300 above. Then, for each transformation, the aggregation server 180-B can assign the following key to the connection key: {H(CryptoHash(ID, dc_destination,report_domain) + nonce}. c , S time ), ConversionData 3p Send to aggregation server 180-A.

[0248] Generate an updated connection key (908). For each pair of received encrypted connection keys and three encrypted transformation data {H(CryptoHash(ID, dc_destination, report_domain) + nonce} i , S time ImpressionData 3p The aggregation server 180-A re-encrypts the connection key and transforms the data. As described in step 310 of reference process 300 above, the aggregation server 180-A can use its private key (which, along with the public key S) i The corresponding private key is used to decrypt the three-stage encryption conversion data (ConversionData). 3p This is used to recover the second-order encrypted conversion data (ConversionData2). Then, the aggregation server 180-A can use its chosen encryption key Key. i2 To re-encrypt the secondary encrypted conversion data (ConversionData2).

[0249] For each pair of received encrypted connection keys and three encrypted transformations of data, the aggregation server 180-A can also generate an updated connection key H(CryptoHash(ID, dc_destination, report_domain) + nonce). c ,S time For example, aggregation server 180-A can generate an updated connection key H(CryptoHash(ID, dc_destination, report_domain) + nonce). c + nonce i , S timeThen, aggregation server 180-A can process the data for {H(CryptoHash(ID, dc_destination, report_domain) + nonce}. c + nonce i , S time ),ConversionData 3p Send to aggregation server 180-B.

[0250] Similarly, as described in step 312 of reference process 300 above, aggregation server 180-B can use its private key (which, along with public key S) c The corresponding private key is used to decrypt the three-times encrypted display data (ImpressionData). 3p This is used to recover the secondary encrypted display data (ImpressionData2). Then, the aggregation server 180-B can use its chosen encryption key Key. c2 To re-encrypt the secondary encryption display data (ImpressionData2).

[0251] For each pair of received encrypted connection keys and three encrypted display data, the aggregation server 180-B can also generate an updated connection key H(CryptoHash(ID, dc_destination, report_domain) + nonce). i ,S time For example, aggregation server 180-B can generate an updated connection key H(CryptoHash(ID, dc_destination, report_domain) + nonce). i + nonce c , S time Then, aggregation server 180-B can process the data for {H(CryptoHash(ID, dc_destination, report_domain) + nonce}. i + nonce c , S time ImpressionData 3p Send to aggregation server 180-A.

[0252] Obtain the connection key (910). For example, each of aggregation servers 180-A and 180-B can interact with time server 192 to obtain the connection key for each piece of display data and each piece of transformation data. For each piece of display data and each piece of transformation data, aggregation server 180-A can use H(CryptoHash(ID, dc_destination,report_domain) + nonce i + nonce c , S time The data is sent to time server 192. Time server 192 can use deterministic symmetric key encryption and the encryption key selected for the current batch (process) to decrypt and re-encrypt H(CryptoHash(ID, dc_destination, report_domain) + nonce. i + nonce c , S time The result of the re-encryption is used to display the ImpressionData. 3p ) and corresponding conversion data (ConversionData) 3p The connection key is used to establish the connection. Aggregator server 180-B can interact with time server 192 in a similar manner to obtain the same connection key.

[0253] Decrypt the display data and transform the data (912). With the connection key obtained, aggregation servers 180-A and 180-B can perform the remainder of the MPC process to decrypt the display data and transform the data, as described above in steps 314 to 328 of reference process 300.

[0254] The decrypted display data and transformation data are sent to the reporting system (914). For example, each of aggregation servers 180-A and 180-B can send the transformation report to the corresponding reporting system, as described above in steps 330 and 332 of reference process 300.

[0255] To provide greater privacy protection, in some implementations, random or pseudo-random numbers can be used on the unique identifier (ID). This random or pseudo-random number can be based on the unique identifier (ID). For example, the random number can be based on HMAC. SHA256(e-mail address, email_provider_private_key). In this example, the random number used for the unique identifier (ID) in the key described above can be the HMAC of the user's email address (or other user information) using the private key of the email provider (or other user-authorized entity). The email provider (or user-authorized entity) can then synchronize the random number used for the unique identifier (ID) to all of the user's devices and applications. This random number can then be used in place of the unique identifier (ID) when reporting presentation and conversion data to aggregation servers 180-A and 180-B.

[0256] Figure 10 This is a block diagram of an example computer system 1000 that can be used to perform the operations described above. System 1000 includes a processor 1010, a memory 1020, a storage device 1030, and an input / output device 1040. Each of components 1010, 1020, 1030, and 1040 may be interconnected, for example, using a system bus 1050. Processor 1010 is capable of processing instructions for execution within system 1000. In some embodiments, processor 1010 is a single-threaded processor. In another embodiment, processor 1010 is a multi-threaded processor. Processor 1010 is capable of processing instructions stored in memory 1020 or on storage device 1030.

[0257] The memory 1020 stores information within the system 1000. In one embodiment, the memory 1020 is a computer-readable medium. In some embodiments, the memory 1020 is a volatile memory cell. In another embodiment, the memory 1020 is a non-volatile memory cell.

[0258] Storage device 1030 is capable of providing large-scale storage for system 1000. In some embodiments, storage device 1030 is a computer-readable medium. In various different embodiments, storage device 1030 may include, for example, a hard disk drive, an optical disk drive, a storage device shared by multiple computing devices over a network (e.g., a cloud storage device), or some other high-capacity storage device.

[0259] Input / output device 1040 provides input / output operations for system 1000. In some embodiments, input / output device 1040 may include one or more network interface devices, such as Ethernet cards, serial communication devices (e.g., RS-232 ports), and / or wireless interface devices (e.g., 802.11 cards). In another embodiment, input / output device may include a driver device configured to receive input data and send output data to external device 1060 (e.g., keyboard, printer, and display devices). However, other embodiments are also possible, such as mobile computing devices, mobile communication devices, set-top box television client devices, etc.

[0260] although Figure 10 Example processing systems have been described, but implementations of the subject matter and functional operations described in this specification may be realized in one of the following: other types of digital electronic circuits, computer software, firmware and hardware including structures disclosed in this specification and their structural equivalents, and combinations of one or more of the foregoing.

[0261] The embodiments of the subject matter and operation described in this specification can be implemented in one of the following ways: digital electronic circuits, computer software, firmware, and hardware including structures disclosed in this specification and their structural equivalents, and combinations of one or more of the foregoing. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs (i.e., one or more computer program instruction modules) encoded on a computer storage medium (or media) for execution by or control of the operation of a data processing device. Alternatively or additionally, the program instructions can be encoded on artificially generated propagating signals (e.g., machine-generated electrical, optical, or electromagnetic signals), wherein the propagating signals are generated to encode information for transmission to a suitable receiver device for execution by the data processing device. The computer storage medium can be a computer-readable storage device (or included therein), a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of the foregoing. Furthermore, although the computer storage medium is not a propagating signal, it can be a source or destination of computer program instructions encoded in artificially generated propagating signals. Computer storage media can also be one or more individual physical components or media (e.g., multiple CDs, disks, or other storage devices) (or included therein).

[0262] The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0263] The term "data processing apparatus" includes all types of devices, apparatuses, and machines for processing data, such as programmable processors, computers, systems-on-a-chip, or a combination thereof. Apparatus may include special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, apparatus may also include code that creates the execution environment for the computer program in question, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. Apparatus and execution environments can implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0264] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. Computer programs may (but do not necessarily) correspond to files in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinating files (e.g., files storing one or more modules, subroutines, or code portions). A computer program may be deployed to execute on a single computer, or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communication network.

[0265] The processes and logic flows described in this specification can be executed by one or more programmable processors that execute one or more computer programs to perform actions by manipulating input data and generating outputs. The processes and logic flows can also be executed by dedicated logic circuits, and the devices can also be implemented as dedicated logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).

[0266] For example, processors suitable for executing computer programs include general-purpose microprocessors and special-purpose microprocessors. Generally, a processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for performing actions according to instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices (e.g., disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled to receive data from or transfer data to mass storage devices, or both. However, a computer does not necessarily have such devices. Furthermore, a computer can be embedded in another device, such as (to name just a few), a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive). Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as: semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by dedicated logic circuitry or integrated into dedicated logic circuitry.

[0267] To provide interaction with the user, embodiments 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) or LCD (liquid crystal display)) for displaying information to the user and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Furthermore, other types of devices can be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from a device used by the user (e.g., by sending a webpage to a web browser on the user's client device in response to a request received from a web browser).

[0268] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes back-end components (e.g., a data server), or middleware components (e.g., an application server), or front-end components (e.g., a client computer with a graphical user interface or web browser through which a user can interact with an implementation of the subject matter described in this specification), or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), inter-networks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0269] A computing system may include clients and servers. Clients and servers are generally geographically distant and typically interact via a communication network. The client-server relationship is established by computer programs running on respective computers that have a client-server relationship with each other. In some embodiments, the server sends data (e.g., HTML pages) to a client device for purposes such as displaying data to a user interacting with the client device and receiving user input from that user. Data generated at the client device (e.g., the result of user interaction) can be received from the client device at the server.

[0270] While this specification contains numerous specific implementation details, these details should not be construed as limiting the scope of any invention or what may be claimed, but rather as descriptions of features specific to particular embodiments of a particular invention. Specific features described in the context of individual embodiments in this specification may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments, or in any suitable sub-combination. Furthermore, although features may be described above as functioning in a particular combination, and even initially claimed in this way, in some cases one or more features may be removed from the claimed combination, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0271] Similarly, although operations are described in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or as requiring all of the shown operations to obtain the desired result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated into a single software product or packaged into multiple software products.

[0272] Therefore, specific embodiments of the subject matter have been described. Other embodiments fall within the scope of the appended claims. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific order or sequential sequence shown to achieve the desired result. In certain embodiments, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method, comprising: The first aggregation server receives display data from each of a plurality of client devices. For each display of a digital component recorded by the client device, the display data includes: (i) a first connection key based on a first unique identifier of the client device on which the display occurs or an application on the client device; (ii) encrypted display data encrypted using a first public key of the first aggregation server and a second public key of a second aggregation server different from the first aggregation server; and (iii) encrypted display time data indicating the time when the display occurred. The first and second aggregation servers collaborate to perform secure multi-party computation using a secure multi-party computation protocol to generate a time-ordered sequence of encrypted display data and encrypted transformation data stored by the second aggregation server, and to decrypt the encrypted display data and encrypted transformation data, including: Based on the first connection key and the second connection key corresponding to the conversion data provided by multiple client devices to the second aggregation server, a group of encrypted conversion data and corresponding encrypted display data is identified; and For each chronological sequence, the encrypted transformation data and the corresponding encrypted display data are sorted based on the encrypted display time data and the encrypted transformation time data corresponding to each second connection key; and Using a first private key corresponding to a first public key and a second private key corresponding to a second public key, the displayed data and the transformed data are decrypted for each sequence of the encrypted displayed data and the encrypted transformed data in multiple stages; The second aggregation server is configured to receive conversion data from at least a portion of the plurality of client devices. For each conversion recorded by a client device, the conversion data includes: (i) one of a second connection key, which is a second unique identifier based on the client device on which the conversion occurred or an application on the client device; (ii) a second value, which includes encrypted conversion data that has been encrypted using a first public key and a second public key; and (iii) encrypted conversion time data, which indicates the time when the conversion occurred.

2. The computer-implemented method according to claim 1, wherein, The encrypted display time data is encrypted using a first public key and a second public key, and / or the encrypted conversion time data is encrypted using a first public key and a second public key.

3. The computer-implemented method according to claim 1, wherein, Based on the first connection key and the second connection key corresponding to the conversion of conversion data provided by multiple client devices to the second aggregation server, the group that identifies the encrypted conversion data and the corresponding encrypted display data includes encrypted display data and encrypted conversion data that identify the connection where the second connection key matches the corresponding first connection key of the encrypted display data.

4. The computer-implemented method according to claim 1 further includes: For each chronological sequence of encrypted display data and encrypted transformation data, credit for transformations in the encrypted transformation data is attributed to each display of the encrypted display data, based at least in part on the chronological sequence of the encrypted display data and encrypted transformation data.

5. The computer-implemented method according to claim 1, wherein, Performing secure multi-party computation includes: for each display, encrypting a first connection key by a first aggregation server, and sending a first tuple including the encrypted first connection key, encrypted display data, and encrypted display time data to a second aggregation server by the first aggregation server.

6. The computer-implemented method according to claim 5, wherein, Performing secure multi-party computation includes: for each transformation, the first aggregation server receiving from the second aggregation server a second tuple comprising an encrypted second connection key generated by the second aggregation server using an encrypted second connection key, encrypted transformation data, and encrypted transformation time data.

7. The computer-implemented method according to claim 6, wherein, Performing multi-party computation includes: Each encrypted conversion time data is decrypted by the first aggregation server; The first time deviation value is determined by the first aggregation server; The second encryption conversion time data is generated by summing the time when the encryption conversion occurs, the clock deviation of the client device where the conversion occurs, and the first time deviation value. For each unique encrypted transformation data, the number of unique second connection keys is determined by the first aggregation server; Filter the set of encrypted conversion data received from the first aggregation server for each encrypted conversion data where the number of unique second connection keys is less than a threshold; and For each remaining encrypted conversion data in the set of encrypted conversion data, a data tuple is provided, including a second connection key for the encrypted conversion data, the encrypted conversion data, and the second encrypted conversion time data.

8. The computer-implemented method according to claim 7, wherein, The second aggregation server is configured as follows: Decrypt each encrypted display time data; The second time deviation value is determined by the second aggregation server; The second encrypted display time data is generated by summing the time when the encrypted display occurs, the clock deviation of the client device where the display occurs, and the second time deviation value. For each unique encrypted transformation data, determine the number of unique first connection keys; Filter each encrypted display data from the set of encrypted display data received from the second aggregation server, where the number of unique first connection keys is less than a threshold. as well as For each remaining encrypted transformation data in the set of encrypted display data, a data tuple is provided, including a first connection key for the encrypted display data, the encrypted transformation data, and the second encrypted display time data.

9. A system comprising: One or more processors; as well as One or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: The first aggregation server receives display data from each of a plurality of client devices. For each display of a digital component recorded by the client device, the display data includes: (i) a first connection key based on a first unique identifier of the client device on which the display occurs or an application on the client device; (ii) encrypted display data encrypted using a first public key of the first aggregation server and a second public key of a second aggregation server different from the first aggregation server; and (iii) encrypted display time data indicating the time when the display occurred. The first and second aggregation servers collaborate to perform secure multi-party computation using a secure multi-party computation protocol to generate a time-ordered sequence of encrypted display data and encrypted transformation data stored by the second aggregation server, and to decrypt the encrypted display data and encrypted transformation data, including: Based on the first connection key and the second connection key corresponding to the conversion data provided by multiple client devices to the second aggregation server, a group of encrypted conversion data and corresponding encrypted display data is identified; and For each chronological sequence, the encrypted transformation data and the corresponding encrypted display data are sorted based on the encrypted display time data and the encrypted transformation time data corresponding to each second connection key; and Using a first private key corresponding to a first public key and a second private key corresponding to a second public key, the displayed data and the transformed data are decrypted for each sequence of the encrypted displayed data and the encrypted transformed data in multiple stages; The second aggregation server is configured to receive conversion data from at least a portion of the plurality of client devices. For each conversion recorded by a client device, the conversion data includes: (i) one of a second connection key, which is a second unique identifier based on the client device on which the conversion occurred or an application on the client device; (ii) a second value, which includes encrypted conversion data that has been encrypted using a first public key and a second public key; and (iii) encrypted conversion time data, which indicates the time when the conversion occurred.

10. The system according to claim 9, wherein, The encrypted display time data is encrypted using a first public key and a second public key, and / or the encrypted conversion time data is encrypted using a first public key and a second public key.

11. The system according to claim 9, wherein, Based on the first connection key and the second connection key corresponding to the conversion of conversion data provided by multiple client devices to the second aggregation server, the group that identifies the encrypted conversion data and the corresponding encrypted display data includes encrypted display data and encrypted conversion data that identify the connection where the second connection key matches the corresponding first connection key of the encrypted display data.

12. The system according to claim 9, wherein, The operation includes: for each chronological sequence of encrypted display data and encrypted transformation data, at least in part based on the chronological sequence of encrypted display data and encrypted transformation data, attributing credit for transformations in the encrypted transformation data to each display of the encrypted display data.

13. The system according to claim 9, wherein, Performing secure multi-party computation includes: for each display, encrypting a first connection key by a first aggregation server, and sending a first tuple including the encrypted first connection key, encrypted display data, and encrypted display time data to a second aggregation server by the first aggregation server.

14. The system according to claim 13, wherein, Performing secure multi-party computation includes: for each transformation, the first aggregation server receiving from the second aggregation server a second tuple comprising an encrypted second connection key generated by the second aggregation server using an encrypted second connection key, encrypted transformation data, and encrypted transformation time data.

15. The system according to claim 14, wherein, Performing multi-party computation includes: Each encrypted conversion time data is decrypted by the first aggregation server; The first time deviation value is determined by the first aggregation server; The second encryption conversion time data is generated by summing the time when the encryption conversion occurs, the clock deviation of the client device where the conversion occurs, and the first time deviation value. For each unique encrypted transformation data, the number of unique second connection keys is determined by the first aggregation server; Filter the set of encrypted conversion data received from the first aggregation server for each encrypted conversion data where the number of unique second connection keys is less than a threshold; and For each remaining encrypted conversion data in the set of encrypted conversion data, a data tuple is provided, including a second connection key for the encrypted conversion data, the encrypted conversion data, and the second encrypted conversion time data.

16. The system according to claim 15, wherein, The second aggregation server is configured as follows: Decrypt each encrypted display time data; The second time deviation value is determined by the second aggregation server; The second encrypted display time data is generated by summing the time when the encrypted display occurs, the clock deviation of the client device where the display occurs, and the second time deviation value. For each unique encrypted transformation data, determine the number of unique first connection keys; Filter each encrypted display data from the set of encrypted display data received from the second aggregation server, where the number of unique first connection keys is less than a threshold. as well as For each remaining encrypted transformation data in the set of encrypted display data, a data tuple is provided, including a first connection key for the encrypted display data, the encrypted transformation data, and the second encrypted display time data.

17. A non-transitory computer-readable medium comprising instructions, when executed by one or more processors of a first aggregation server, causing the one or more processors to perform operations including: The first aggregation server receives display data from each of multiple client devices. For each display of a digital component recorded by the client devices, the display data includes: (i) a first connection key, the first connection key being based on a first unique identifier of the client device on which the display occurs or of an application on the client device; (ii) encrypted display data, the encrypted display data being encrypted using a first public key of a first aggregation server and a second public key of a second aggregation server different from the first aggregation server; and (iii) encrypted display time data, the encrypted display time data indicating the time when the display occurred. The first and second aggregation servers collaborate to perform secure multi-party computation using a secure multi-party computation protocol to generate a time-ordered sequence of encrypted display data and encrypted transformation data stored by the second aggregation server, and to decrypt the encrypted display data and encrypted transformation data, including: Based on the first connection key and the second connection key corresponding to the conversion data provided by multiple client devices to the second aggregation server, a group of encrypted conversion data and corresponding encrypted display data is identified; and For each chronological sequence, the encrypted transformation data and the corresponding encrypted display data are sorted based on the encrypted display time data and the encrypted transformation time data corresponding to each second connection key; and Using a first private key corresponding to a first public key and a second private key corresponding to a second public key, the displayed data and the transformed data are decrypted for each sequence of the encrypted displayed data and the encrypted transformed data in multiple stages; The second aggregation server is configured to receive conversion data from at least a portion of the plurality of client devices. For each conversion recorded by a client device, the conversion data includes: (i) one of a second connection key, which is a second unique identifier based on the client device on which the conversion occurred or an application on the client device; (ii) a second value, which includes encrypted conversion data that has been encrypted using a first public key and a second public key; and (iii) encrypted conversion time data, which indicates the time when the conversion occurred.

18. The non-transitory computer-readable medium according to claim 17, wherein, The encrypted display time data is encrypted using a first public key and a second public key, and / or the encrypted conversion time data is encrypted using a first public key and a second public key.

Images