Privacy preserving centroid model using secure multi-party computation

Abstract

The present disclosure relates to a privacy preserving machine learning platform. In one aspect, a method includes receiving, from a client device and by a computing system of a plurality of multi-party computation (MPC) systems, a first request for a user group identifier that identifies a user group to which a user is to be added. The first request includes a model identifier of a centroid model, first user profile data of a user profile of the user, and a threshold distance. A centroid of the user group determined using the centroid model corresponding to the model identifier is identified for each user group of a set of user groups corresponding to the model identifier. The computing system determines a user group result based on at least the first user profile data, the centroid, and the threshold distance. The user group result indicates the user group to which the user is to be added.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Israel Application No. 277760, filed on October 2, 2020. The disclosure of the aforementioned application is incorporated herein by reference in its entirety. Technical Field

[0003] This specification relates to a privacy-preserving machine learning platform that uses secure multi-party computation to train and use machine learning models. Background Art

[0004] Some machine learning models are trained based on data collected from multiple sources (e.g., across multiple websites and / or local applications). However, this data may include private or sensitive data that should not be shared or allowed to be disclosed to other parties. Summary of the Invention

[0005] In general, an innovative aspect of the subject matter described in this specification can be embodied in a method, the method comprising: receiving a first request for a user group identifier from a client device and by a first computing system in a plurality of multi-party computing (MPC) systems, the user group identifier identifying a user group to which a user is to be added, the first request comprising a model identifier of a centroid model, first user profile data of a user profile of a user, and a threshold distance; identifying a set of user groups corresponding to the model identifier; identifying a centroid of the user group determined using the centroid model corresponding to the model identifier for each user group in the set of user groups; determining, by the first computing system, a user group result based at least on the first user profile data, the centroid of each user group in the set of user groups, and the threshold distance, wherein the user group result indicates one or more user groups to which the user is to be added; and transmitting the user group result to the client device. Other embodiments of this aspect include corresponding apparatus, systems, and computer programs encoded on computer storage devices and configured to perform various aspects of the method.

[0006] These and other embodiments can each optionally include one or more of the following features. In some aspects, the first user profile data includes a first portion of the user profile, and wherein the centroid of each user group is determined using a secure MPC process between the first computing system and one or more second computing systems in the plurality of MPC systems. The user group results can include one or more user group identifiers for the one or more user groups. Each second computing system can transmit a second user group result to the client device, the second user group result including one or more second user group identifiers of one of the one or more second user groups to which the user is to be added based on the corresponding second portion of the user profile, the corresponding second centroid of each user group in the set of user groups, and the threshold distance.

[0007] Some aspects may include generating a centroid for each user group in a set of user groups. Generating may include: obtaining a data structure including, for each centroid model and user group identifier pair, a first sum of sharing vectors representing a first share of a set of user profiles and a number of client devices from which the first share of the set of user profiles was received. Generating may also include: for each centroid model and user group identifier pair, determining whether the number of applications meets a threshold; for each centroid model and user group identifier pair for which the number of applications meets the threshold, transmitting a first portion of the first sum of sharing vectors for the centroid model and user group identifier pair to each second computing system in one or more second computing systems of a plurality of MPC systems; receiving from each second computing system in the one or more second computing systems a portion of a corresponding second sum of sharing vectors for the one or more centroid model and user group identifier pairs; for each of the one or more centroid model and user group identifier pairs: determining a sum of each portion of the corresponding second sum of sharing vectors for the centroid model and user group identifier pair and a portion of the first sum of sharing vectors for the centroid model and user group identifier pair; and determining a centroid for the user group identified by the user group identifier based on the sum.

[0008] In some aspects, determining the centroid of the user group identified by the user group identifier based on the sum includes: dividing the sum by the sum of: (i) the number of client devices for the centroid model and user group identifier pair and (ii) the corresponding number of client devices for the centroid model and user group identifier pair received from each second computing system.

[0009] In some aspects, first user profile data for a user profile includes a first secret share for the user profile. For each centroid model and user group identifier pair, a first number having a value of zero or one is determined based on a random or pseudo-random seed received from the client device, and the first number represents a first secret share estimated by an application of the client device as to whether to add the user to the user group identified by the user group identifier. A first secret share indicating whether the application correctly estimated whether to add the user to the user group is derived by performing a first secure MPC process with one or more second computing systems of a plurality of MPC systems using at least the first secret share for the user profile, the first number, a corresponding second secret share for the user profile received by each second computing system, and a corresponding second number received by each second computing system. Some aspects may include performing a second secure MPC process with the one or more second computing systems to reconstruct the estimated flag based on the first secret share for the estimated flag and the corresponding second secret share for the estimated flag derived by each of the one or more second computing systems. The user group result may include an estimated flag for each centroid model and user group identifier pair. Some aspects may include receiving a first request for one or more user group identifiers corresponding to one or more of the estimated flags. The request may include a distribution point function for each estimated marker. Some aspects may include, for each estimated marker, deriving a first user group identifier result using a user group identifier corresponding to the estimated marker and the distribution point function for the estimated marker. The client device may determine the user group identifier corresponding to the estimated marker using the first user group identifier result and a corresponding second user group identifier result received from each second computing system in the plurality of MPC systems.

[0010] The subject matter described in this specification can be implemented in specific embodiments to achieve one or more of the following advantages. The techniques described in this disclosure can identify users with similar interests and expand user group membership while protecting the user's privacy and data security. For example, there is no need to send the user's online activity data to the content platform or otherwise disclose the user's online activity data to any computing system or party. This protects the privacy of users associated with such platforms and protects the security of data from being leaked during transmission or from the platform. Historically, third-party cookies (i.e., cookies from a domain different from the resource presented by the client device) have been used to collect data from client devices on the Internet. However, some browsers block the use of third-party cookies, thereby preventing the use of third-party cookies to collect data. This can cause problems when attempting to use the collected data to segment data, make inferences, or otherwise utilize the data to enhance the online browsing experience. In other words, if third-party cookies are not used, most of the previously collected data will no longer be available, which will prevent the computing system from using this data. Therefore, advantageously, the subject matter described herein allows for the aggregation of data related to different users without compromising user data security or privacy and without requiring third-party cookies.

[0011] Cryptographic techniques, such as secure multi-party computation (MPC), can be used to address issues that arise when data cannot be collected using third-party cookies. For example, cryptographic techniques can expand user groups based on similarities in user profiles without using third-party cookies. This protects user privacy without negatively impacting the ability to expand user groups, and in some cases, provides better user group expansion based on more complete profiles than can be achieved using third-party cookies. MPC techniques can ensure that, as long as one of the computing systems in the MPC cluster does not expose part of its underlying data in plain text, no computing system or other party can obtain user data in plain text. Therefore, the claimed method allows for secure identification, grouping, and transmission of user data without requiring the use of third-party cookies to determine any relationships between user data. This differs from previously known methods that typically require clear text user profiles collected using third-party cookies to determine relationships between data. By grouping user data in this manner, the efficiency of transmitting data content to user devices is improved because data content not related to a specific user does not need to be transmitted. Specifically, third-party cookies are not required, thereby avoiding the need to store third-party cookies and improving memory usage. Exponential decay techniques may be used to construct a user profile at a client device to reduce the data size of raw data required to construct the user profile, thereby reducing data storage requirements.

[0012] The foregoing features and advantages of the subject matter will be described or will become apparent with reference to the following description and accompanying drawings. Additional features and advantages will be apparent from the description that follows, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 is a block diagram of an environment in which a secure MPC cluster generates a machine learning model and the machine learning model is used to expand a user group.

[0014] Figure 2 is a swim lane diagram of an example process for generating a centroid model and using the centroid model to add a user to a user group.

[0015] Figure 3 is a flow diagram illustrating an example process for generating a user profile and sending the user profile to an MPC cluster.

[0016] Figure 4 is a flow diagram illustrating an example process for generating a centroid model.

[0017] Figure 5 is a swim lane diagram illustrating an example process for using a centroid model to add a user to a user group.

[0018] Figure 6 is a swim lane diagram illustrating an example process for generating a centroid model and using the centroid model to add a user to a user group corresponding to the centroid model.

[0019] Figure 7 is a flow diagram illustrating an example process for determining a user group result based on user profile data for a user and a centroid model.

[0020] Figure 8 is a block diagram of an example computer system.

[0021] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0022] In general, the present disclosure describes systems and techniques for extending user group membership while protecting user privacy and ensuring data security, even when third-party cookies are blocked (e.g., blocked by the browser) and / or user profiles cannot be collected for various reasons. Typically, rather than creating and maintaining user profiles at a computing system of another entity such as a content platform, user profiles are maintained at the user's client device. In order to generate a machine learning model that can be used to extend group membership, the user's client device can send its encrypted user profile (e.g., as a secret share of the user profile) along with other data, optionally via the content platform, to multiple computing systems of a secure multi-party computing (MPC) cluster. For example, each client device can generate two or more secret shares of the user profile and send the corresponding secret shares to each computing system. In some embodiments, a different subset of the information in each user profile is provided to each computing system so that there is no overlap in the user profile data sent to each computing system.

[0023] The computing system of the MPC cluster can use MPC technology to generate a machine learning model to recommend a user group to a user based on the user's profile, while preventing any computing system of the MPC cluster (or other parties other than the user) from obtaining the profile of any individual user in plain text, thereby protecting the user's privacy. The machine learning model can be a centroid model. In this example, the centroid model of the user group can represent the center of the user profile, for example, the center (average) of the user profiles of the users who are members of the user group.

[0024] After the machine learning model is generated, it can be used to recommend one or more user groups for each user based on their profile. For example, the user's client device can query the MPC cluster for recommended user groups for the user or determine whether the user should be added to a specific user group. The MPC cluster can use the user's user profile to identify user groups with centroids within a threshold distance of the user's user profile. The user's user group membership can be used in a privacy-preserving and secure manner to provide content to the user.

[0025] Example systems for generating and using machine learning models

[0026] Figure 1is a block diagram of an environment 100 in which a secure MPC 130 cluster generates a machine learning model and the machine learning model is used to expand a group of users. The example environment 100 includes a data communication network 105, such as a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof. The network 105 connects client devices 110, secure MPC clusters 130, publishers 140, websites 142, and content platforms 150. The example environment 100 can include many different client devices 110, secure MPC clusters 130, publishers 140, websites 142, and content platforms 150.

[0027] A client device 110 is an electronic device that can communicate over the network 105. Example client devices 110 include personal computers, mobile communication devices (e.g., smartphones), and other devices that can send and receive data over the network 105. A client device can also include a digital assistant device that accepts audio input through a microphone and outputs audio output through a speaker. When the digital assistant detects a “hotword” or “hotphrase” that activates the microphone to accept audio input, the digital assistant can be put into a listening mode (e.g., ready to accept audio input). The digital assistant device can also include a camera and / or a display to capture images and visually present information. The digital assistant can be implemented in different forms of hardware devices, including a wearable device (e.g., a watch or glasses), a smartphone, a speaker device, a tablet device, or other hardware devices. A client device can also include a digital media device, such as a streaming device that plugs into a television or other display to stream video to the television.

[0028] A client device 110 typically includes applications 112, such as web browsers and / or native applications, to facilitate sending and receiving data over the network 105. A native application is an application developed for a particular platform or a particular device (e.g., a mobile device with a particular operating system). A publisher 140 can develop and provide (e.g., make available for download) a native application to a client device 110. For example, in response to a user of a client device 110 entering a resource address of a resource 145 in an address bar of a web browser or selecting a link that references the resource address, the web browser can request the resource 145 from a web server that hosts a website 142 of the publisher 140. Similarly, a native application can request application content from a remote server of a publisher.

[0029] Some resources, application pages, or other application content can include digital component slots for presenting digital components with the resources 145 or application pages. As used throughout this disclosure, the phrase "digital component" refers to a discrete unit of digital content or digital information (e.g., a video clip, an audio clip, a multimedia clip, an image, text, or other unit of content). Digital components can be stored electronically as a single file or collection of files in a physical storage device, and digital components can take the form of a video file, an audio file, a multimedia file, an image file, or a text file, and include advertising information such that an advertisement is a type of digital component. For example, a digital component can be content that is intended to supplement the content of a web page or other resource presented by the application 112. More specifically, a digital component can include digital content that is related to the resource content (e.g., a digital component can be related to the same topic as the web page content, or related to a related topic). Thus, providing a digital component can supplement and generally enhance the web page or application content.

[0030] When the application 112 loads a resource (or application content) that includes one or more digital component slots, the application 112 can request a digital component for each slot. In some implementations, a digital component slot can include code (e.g., a script) that causes the application 112 to request a digital component from a digital component distribution system that selects a digital component and provides the digital component to the application 112 for presentation to a user of the client device 110.

[0031] The content platform 150 can include supply-side platforms (SSPs) and demand-side platforms (DSPs). Generally, the content platform 150 manages the selection and distribution of digital components on behalf of the publishers 140 and the digital component providers 160.

[0032] Some publishers 140 use an SSP to manage the process of obtaining digital components for their resources' and / or applications' digital component slots. An SSP is a technology platform implemented in hardware and / or software that automates the process of obtaining digital components for resources and / or applications. Each publisher 140 can have a corresponding SSP, or in some rare cases, a corresponding plurality of SSPs. Some publishers 140 can use the same SSP.

[0033] Digital component providers 160 can create (or otherwise publish) digital components that are presented in digital component slots of publishers' resources and applications. Digital component providers 160 can use a DSP to manage the serving of their digital components for presentation in digital component slots. A DSP is a technology platform implemented in hardware and / or software that automates the process of distributing digital components for presentation with resources and / or applications. A DSP can interact with multiple supply-side platforms, SSPs, on behalf of digital component providers 160 to provide digital components for presentation with resources and / or applications of multiple different publishers 140. Generally, a DSP can receive a request for a digital component (e.g., from an SSP), generate (or select) selection parameters for one or more digital components created by one or more digital component providers based on the request, and provide data related to the digital component (e.g., the digital component itself) and the selection parameters to the SSP. The SSP can then select a digital component for presentation at a client device 110 and provide data to the client device 110 that causes the client device 110 to present the digital component.

[0034] In some cases, it is beneficial to users to receive digital components related to webpages, application pages, or other electronic resources that the user has previously accessed and / or interacted with. To distribute such digital components to users, when a user accesses a particular resource or performs a particular action with a resource (e.g., interacts with or adds a particular item presented on a webpage to a virtual shopping cart), the user can be assigned to a user group, e.g., a user interest group, a group of similar users, or other group type involving similar user data. User groups can be generated by digital component providers 160. That is, each digital component provider 160 can assign users to their user groups when the users access the digital component provider's 160 electronic resources.

[0035] To protect user privacy, user group membership can be maintained at a user's client device 110, e.g., by one of the applications 112 or the operating system of the client device 110, rather than by the digital component providers, content platforms, or other parties. In a particular example, a trusted program (e.g., a web browser or operating system) can maintain a list of user group identifiers ("user group list") for a user using the web browser or another application. The user group list can include a group identifier for each user group that the user has been added to. Digital component providers 160 that create user groups can specify a user group identifier for their user groups. The user group identifier for a user group can be descriptive (e.g., a gardening group) or a code representing the group (e.g., a non-descriptive alphanumeric sequence). A user's user group list can be stored in secure storage on the client device 110 and / or can be encrypted when stored to prevent others from accessing the list.

[0036] When application 112 presents a resource or application content related to digital component provider 160 or a web page on website 142, the resource may request application 112 to add one or more user group identifiers to the user group list. In response, application 112 may add the one or more user group identifiers to the user group list and securely store the user group list.

[0037] The content platform 150 can use the user's user group membership to select digital components or other content that may be of interest to the user or that may benefit the user / user device in some way. For example, such digital components or other content may include data that improves the user experience, improves the operation of the user device, or benefits the user or user device in some other way. However, the user group identifiers for the user's user group list can be provided in a manner that prevents the content platform 150 from associating the user group identifiers with a particular user, thereby protecting user privacy and data security when using user group membership data to select digital components.

[0038] The application 112 may provide the user group identifier from the user group list to a trusted computing system interacting with the content platform 150 for selecting a digital component to be presented at the client device 110 based on the user group membership in a manner that prevents the content platform 150 or any other entity other than the user themselves from learning the user's user group membership.

[0039] In some cases, it may be beneficial for the user and the digital component provider to expand the user group to include users with similar interests or other similar data as users who are already members of the user group. Helpfully, this can be achieved without using third-party cookies. For example, a first user may be interested in skiing and may be a member of the user group for a particular ski resort. A second user may also be interested in skiing but is unaware of this ski resort and is not a member of it. If two users have similar interests or data (e.g., similar user profiles), the second user can be added to the user group for the ski resort so that the second user receives content (e.g., digital components) related to the ski resort and which may be of interest to or otherwise beneficial to the second user or their user device. In other words, the user group can be expanded to include other users with similar user data.

[0040] The secure MPC cluster 130 can generate (e.g., train) a machine learning model that recommends user groups to a user (or their application 112) based on the user's profile, or can be used to generate recommendations for user groups. The secure MPC cluster 130 includes two computing systems, MPC1 and MPC2, that perform secure MPC techniques to generate the machine learning model. Although the example MPC cluster 130 includes two computing systems, more computing systems can be used to perform the MPC process as long as the MPC cluster 130 includes more than one computing system. For example, the MPC cluster 130 can include three computing systems, four computing systems, or another suitable number of computing systems. Using more computing systems in the MPC cluster 130 can provide more security and fault tolerance, but can also increase the complexity of the MPC process.

[0041] The computing systems of MPC cluster 130 (e.g., computing systems MPC1 and MPC2) can be operated by different entities. In this way, each entity may not have access to the complete user profile in plaintext. Plaintext is text that is not computer-marked, specially formatted, or written in code or data (including binary files) in a form that can be viewed or used without a key or other decryption device or other decryption process. For example, one of computing systems MPC1 or MPC2 can be operated by a trusted party different from the user, publisher 140, content platform 150, and digital component provider 160. For example, an industry group, a government group, or a browser developer can maintain and operate one of computing systems MPC1 and MPC2. The other computing system can be operated by a different one of these groups, such that a different trusted party operates each computing system MPC1 and MPC2. Preferably, the different parties operating different computing systems MPC1 and MPC2 have no incentive to collude to compromise user privacy. In some embodiments, computing systems MPC1 and MPC2 are architecturally separate and monitored so that they do not communicate with each other except for executing the secure MPC process described in this disclosure.

[0042] In some embodiments, the MPC cluster 130 generates (e.g., trains) one or more centroid models for each content platform 150 (e.g., each DSP and / or each SSP) and / or for each digital component provider 160. For example, a content platform 150 may have the MPC cluster 130 generate a centroid model for any subset of one or more user groups managed by the content platform 150 or for any subset of one or more user groups to which the content platform has at least read access. For example, each content platform 150 may manage the distribution of digital components for one or more digital component providers 160. A content platform 150 may request that the MPC cluster 130 generate a centroid model for one or more of the digital component providers 160 for which the content platform 150 manages the distribution of digital components. In another example, a digital component provider 160 may have the MPC cluster 130 generate a centroid model for one or more of the user groups created and maintained by the digital component provider 160. An example process for generating a centroid model is described in Figure 4 and Figure 6 It is shown in the figure and described below.

[0043] The centroid model can embed users into n-dimensional space. The user in the profile space is represented by an n-dimensional vector X = {x1, x2, ... x n} represents a user group R with m users: {X1,X2,…X m The centroid of the user group R in the model can be Given a user X′={x1′,x2′,…x n ′}, the content platform 150 or the digital component provider 160 may want to find all user groups R such that |X′-Centroid(model,R)| <d,其中d是表示质心模型的阈值距离的参数,例如,由内容平台150指定。

[0044] For ease of subsequent description and brevity, the remaining description is primarily about generating and using centroid models for content platforms 150 (e.g., DSPs and SSPs). However, these systems and techniques can also be implemented to generate centroid models for digital component providers 160 or other entities and query centroid models on behalf of digital component providers 160 or other entities.

[0045] After generating the centroid models for the content platform 150, the content platform 150 can query or cause the application 112 of the client device 110 to query one or more of the centroid models to identify one or more user groups that the user of the client device 110 is to join. For example, the content platform 150 can request that the application 112 query the content platform’s centroid models to determine whether the user should be added to any of the user groups of the content platform 150. Generally, the MPC cluster 130 can determine whether the user’s user profile is within a threshold distance of a centroid of a user group of the content platform 150. If so, for user profiles within the threshold distance of the centroid, the MPC cluster 130 can request that the application 112 add the user to the user group. If approved by the user and / or the application 112, the application 112 can add the user group identifier of the user group to a list of user groups stored at the client device 110.

[0046] In some implementations, the application 112 can provide a user interface that enables the user to manage the user groups to which the user is assigned. For example, the user interface can enable the user to remove a user group identifier, prevent all or certain resources 145, publishers 140, content platforms 150, digital component providers 160, and / or MPC clusters 130 from adding the user to the user group (e.g., prevent the entity from adding the user group identifier to a list of user group identifiers maintained by the application 112). This provides the user with greater transparency, choice / consent, and control.

[0047] In addition to the descriptions throughout this disclosure, a user can be provided with controls (e.g., user interface elements with which the user can interact) that allow the user to make an election as to whether and when the systems, programs, or features described herein can enable collection of user information (e.g., information about a user’s social network, social actions, or activities, a user’s profession, a user’s preferences, or a user’s current location), and if the user is sent content or communications from a server that can be personalized to the user’s interests or location. In addition, certain data can be treated in one or more ways before it is stored or used, so that personally-identifiable information is removed. For example, a user’s identity can be treated so that no personally-identifiable information can be determined for the user, or a user’s geographic location can be generalized where location information is obtained (such as to a city, postal code, or state level), so that a particular location of a user cannot be determined. Thus, the user can have control over what information is collected about the user, how information is used, and what information is provided to the user.

[0048] Example processes for generating and using machine learning models

[0049] Figure 2is a swim lane diagram of an example process 200 for generating a centroid model and using the centroid model to add a user to a user group. The operations of process 200 can be implemented, for example, by client device 110, computing systems MPC1 and MPC2 of MPC cluster 130, and content platform 150. The operations of process 200 can also be implemented as instructions stored on one or more computer-readable media that can be non-transitory, and execution of the instructions by one or more data processing apparatuses can cause the one or more data processing apparatuses to perform the operations of process 200. Although process 200 and other processes below are described in terms of two computing systems MPC cluster 130, MPC clusters with more than two computing systems can also be used to perform similar processes.

[0050] Content platform 150 can initiate generation and / or updating of one or more of its centroid models by requesting applications 112 running on client devices 110 to generate user profiles for their respective users and upload secret shares and / or encrypted versions of the user profiles to MPC cluster 130. For purposes of this disclosure, secret shares of a user profile can be considered encrypted versions of the user profile because the secret shares are not in plaintext form. Upon generation, each application 112 can store data of a user profile and generate an updated user profile in response to a received request from content platform 150. Because the content and machine learning models of user profiles differ for different content platforms 150, an application 112 running on a user’s client device 110 can maintain data of multiple user profiles and generate multiple user profiles, each user profile specific to a particular content platform or specific to a particular centroid model.

[0051] Because content platform 150 (or digital component provider 160) can have multiple centroid models, e.g., one for each set of one or more user groups, content platform 150 (or digital component provider 160) can request applications 112 to generate user profiles and upload multiple centroid models and / or user profiles of multiple user groups simultaneously, e.g., with a single request.

[0052] An application 112 running on a client device 110 establishes a user profile for a user of the client device 110 (202). The user’s user profile can include data related to events initiated by the user and / or events that can have been initiated by the user for an electronic resource (e.g., web page or application content). These events can include views of the electronic resource, views of digital components, user interactions, or lack of user interactions (e.g., selections) with the electronic resource or digital component, conversions that occur (or do not occur) after user interactions with the electronic resource, and / or other appropriate events related to the user and the electronic resource. Because a user profile can change over time, a constructed user profile can be referred to as a current user profile Pcurrent .

[0053] A user profile of a user can be specific to a content platform 150, or a selected centroid model owned by the content platform 150. For example, as described in more detail below with reference to Figure 3 Each content platform 150 can request that the application 112 generate or update a user profile specific to that content platform 150, as described in more detail below with reference to

[0054] A user profile P current of a user can be in the form of a feature vector. For example, a user profile P current may be an n-dimensional feature vector. Each of the n dimensions can correspond to a particular feature, and the value of each dimension can be the value of the user’s feature. For example, one dimension can be for whether a particular digital component was presented to (or interacted with) the user. In this example, the value of the feature can be “1” if the digital component was presented to (or interacted with) the user; the value of the feature is “0” if the digital component has not been presented to (or interacted with) the user. An example process for generating a user profile of a user is illustrated in Figure 3 and described below.

[0055] The application 112 generates a secret share of a user profile P current of a user. In this example, the application 112 generates two secret shares [P current ] and [P current,2 ] of the user profile P current,1 , one for each computing system of the MPC cluster 130. For purposes of this disclosure, the use of brackets [ ] around an element (e.g., a value, a vector, etc.) indicates a secret share of the element, e.g., [secret share] indicates a secret share of the element “secret share.” For example, the application can split the user profile P current into secret shares to protect the values of the user profile P current from a compromised computing system in the MPC cluster 130. Note that each secret share can itself be a random value that does not, by itself, reveal any information about the user profile. The two secret shares need to be combined to get the user profile. If the MPC cluster 130 includes more computing systems that participate in the training of the machine learning model, the application 112 will generate more secret shares, one for each computing system. An example process for constructing a user profile and generating secret shares of a user profile is illustrated in Figure 3 and described below.

[0056] Application 112 provides the user profile P to computing system MPC1 current The first secret sharing [P current,1 ](206). The application 112 also provides the computing system MPC2 with a second secret share of the user profile [P current,2 ](208). Figure 3 As mentioned above, there are multiple ways to provide the user profile P to the MPC cluster 130. current Two secret sharing [P current,1 ] and [P current,2 ], thereby protecting user privacy and data security.

[0057] Computing systems MPC1 and MPC2 generate a centroid model (210). Computing systems MPC1 and MPC2 may generate a centroid model for a plurality of user groups of a content platform 150 or a digital component provider 160 that requests a client device 110 to upload a user profile. Each time a new machine learning model is generated based on user profile data may be referred to as a training session. Computing systems MPC1 and MPC2 may generate a centroid model based on a secret sharing of user profiles received from a plurality of client devices. For example, computing systems MPC1 and MPC2 may generate a centroid model based on a secret sharing of user profiles using MPC techniques. Typically, generating a centroid model for a user group includes calculating the centroid of the user profiles of users that are members of the user group. An example process for generating a centroid model is described in Figure 4 and Figure 6 It is shown in the figure and described below.

[0058] Each centroid model generated and maintained by the MPC cluster 130 may have a corresponding unique identifier. This allows the application 112 to query the centroid model using the model identifier. For example, a request to generate a centroid model may include a model identifier for the centroid model, which may be assigned by an owner (e.g., a content platform 150 or a digital component provider 160). The owner may then use the model identifier to request the application 112 to query the centroid model to determine whether to add a user to the user group corresponding to the centroid model.

[0059] Application 112 submits a user group update request to MPC cluster 130 (212). The user group update request may include the user's current user profile P current In some embodiments, the application 112 may include the complete user profile P current In other embodiments, in order to protect user privacy, the application 112 may send the user profile P to each computing system MPC1 and MPC2. current The corresponding portion or secret share is sent to each computing system MPC1 and MPC2.

[0060] The user group update request may also include a model identifier for each of the one or more centroid models to be queried to determine whether the user should be added to the user group corresponding to the centroid model. In some embodiments, the application 112 sends a separate user group update request for each centroid model. In this example, each user group request includes a model identifier for that centroid model.

[0061] Each user group update request may also include a threshold distance for the query, such as a maximum distance. If the user profile of the user is within the threshold distance of the centroid of the user group, the MPC cluster 130 may request the application 112 to add the user to the corresponding user group. Figure 5 Example data formats and techniques for communicating user group update requests are described.

[0062] MPC cluster 130 determines whether the user should be added to one or more user groups (214). Typically, this may include determining whether the user profile of the user is within a threshold distance of the centroid of each of the one or more user groups. Computing systems MPC1 and MPC2 may perform a secure MPC process to determine whether the user should be added to the one or more user groups, such that neither computing systems MPC1 nor MPC2 have access to any clear text profile of the user or a user group identifier that would be recommended for the user in clear text. An example process for determining a user group for a user is described in Figure 5 and Figure 6 It is shown in the figure and described below.

[0063] The MPC cluster 130 provides zero or more user group identifiers (216) to the application 112. The MPC cluster 130 may provide a user group identifier for each user group to which the user should be added. That is, the MPC cluster 130 may provide a user group identifier for each user group having a centroid of the user profile of the user within a threshold distance thereof. To protect user privacy, each computing system MPC1 and MPC2 provides a portion of the user group identifier or a secret share of the user group identifier, as described below with reference to Figure 5 and Figure 6 As stated.

[0064] The application 112 updates the user group list for the user (218). For example, the application 112 may add the user to each user group for which the user profile is within a threshold distance of its centroid. That is, the application 112 may add each user group identifier received from the MPC cluster 130 to the user group list maintained at the user's client device 110. In some implementations, the application 112 may prompt the user to approve the addition of the user to each user group.

[0065] The application 112 transmits a request for content (220). For example, the application 112 may transmit a request for a digital component to the content platform 150 in response to loading an electronic resource having a digital component slot. In some embodiments, the request may include one or more user group identifiers of user groups that include the user as a member. For example, the application 112 may obtain one or more user group identifiers from a list of user groups and provide the user group identifiers with the request. In some embodiments, techniques may be used to prevent the content platform from being able to associate the user group identifier with the user, the application 112, and / or the client device 110 from which the request was received.

[0066] The content platform 150 delivers the content to the application 112 (222). For example, the content platform 150 can select a digital component based on the user group identifier and provide the digital component to the application 112. In some embodiments, the content platform 150 cooperates with the application 112 or the device operating system to select the digital component based on the user group identifier without leaking the user group identifier outside of the application 112 or the client device 110.

[0067] The application 112 displays or otherwise implements the received content (224).For example, the application 112 may display the received digital component in a digital component slot of the electronic resource.

[0068] Example processes for generating user profiles

[0069] Figure 3 is a flow chart illustrating an example process 300 for generating a user profile and sending the user profile to an MPC cluster. The operations of process 300 may be performed, for example, by Figure 1 The process 300 may be implemented by the client device 110, for example, by the application 112 running on the client device 110 or the operating system of the client device 110. The operations of the process 300 may also be implemented as instructions stored on one or more computer-readable media that may be non-transitory, and execution of the instructions by one or more data processing devices may cause the one or more data processing devices to perform the operations of the process 300.

[0070] Application 112 executing on a user's client device 110 receives data for an event (302). The event can be, for example, the presentation of an electronic resource at client device 110, the presentation of a digital component at client device 110, user interaction with an electronic resource or digital component at client device 110, or a transformation of a digital component, or the lack of user interaction or transformation with the presented electronic resource or digital component at client device 110. When an event occurs, content platform 150 or digital component provider 160 can provide data related to the event to application 112 for use in generating a user profile for the user.

[0071] The application 112 can generate a different user profile for each content platform 150 or digital component provider 160. That is, the user profile of the user and for a specific content platform 150 may only include event data received from that specific content platform 150. This protects user privacy by not sharing data related to events of other content platforms with the content platform. In some embodiments, the application 112 can generate a different user profile for each centroid model owned by the content platform 150 based on the request of the content platform 150. Based on the design goals, different centroid models may require different training data. For example, a first model can be used to determine whether to add a user to a user group. A second model can be used to predict whether the user will interact with the digital component. In this example, the user profile for the second model can include additional data that the user profile for the first model does not have, such as whether the user interacts with the digital component.

[0072] The content platform 150 can update the token M with the profile update Event data is sent in the form of profile update token M update There are the following items as shown and described in Table 1 below.

[0073]

[0074]

[0075] Table 1

[0076] The model identifier identifies the centroid model that the user profile will use to train or perform user group inference. A profile record is an n-dimensional feature vector that includes data specific to an event, such as the type of event, the electronic resource or digital component, the time the event occurred, and / or other appropriate event data that the content platform 150 (or digital component provider 160) wants to use in training the centroid model and performing user group inference. This operation instructs the application 112 to update the user profile based on the profile record. A digital signature is generated based on seven items using the private key of the content platform 150.

[0077] In some embodiments, in order to protect the update token M during transmission update , the content platform 150 will update the token M update Before sending to the application 112, update the token M update For example, the content platform 150 can use the public key of the application, such as PubKeyEnc(M update , application_public_key) to update token M update Encryption is performed.

[0078] In some implementations, content platform 150 can send event data to application 112 without encoding the event data or update request in the form of a profile update token M update . For example, a script originating from content platform 150 running inside application 112 can transmit event data and update requests directly to application 112 via a script API, where application 112 relies on a World Wide Web Consortium (W3C) origin-based security model and / or HTTPS (Hypertext Transfer Protocol Secure) to protect event data and update requests from forgery or leakage or man-in-the-middle attacks.

[0079] Application 112 stores the data of the event (304). If the event data is encrypted, application 112 can decrypt the event data using its private key, which corresponds to the public key used to encrypt the event data. If the event data is sent in the form of an update token M update , application 112 can verify the update token M update before storing the event data. Application 112 can verify the update token M update by (i) verifying the digital signature using the public key of content platform 150 that corresponds to the private key of content platform 150 used to generate the digital signature and (ii) ensuring that the token creation timestamp is not outdated, e.g., the time indicated by the timestamp is within a threshold amount of time of the current time at which the verification is being performed. If the update token M update is valid, application 112 can store the event data, e.g., by storing the n-dimensional profile record. If either verification fails, application 112 can ignore the update request, e.g., by not storing the event data.

[0080] For each centroid model, e.g., for each unique model identifier, application 112 can store event data for the model. For example, application 112 can maintain a data structure for each unique model identifier that includes a set of n-dimensional feature vectors (e.g., profile records of update tokens) and maintains an expiration time for each feature vector, said. An example data structure for a model identifier is shown below

[0081] Table 2.

[0082] Feature vector Expiry n-dimensional feature vector Expiry time … …

[0083] Table 2

[0084] Upon receiving a valid update token M update , application 112 can update the data structure by adding the feature vector and expiration time of the update token M update to the data structure. For example, application 112 can add the feature vector and expiration time of the update token M updateThe data structure of the model identifier in Table 2. Periodically, the application 112 can clear the expired feature vectors from the data structure to reduce the storage size. The expiration time in Table 2 is consistent with the update token M shown in Table 1. update The expiration time is the same as in .

[0085] Application 112 determines whether to generate a user profile (306). For example, application 112 may generate a user profile for a specific centroid model in response to a request from content platform 150. The request may be a request to generate a user profile and upload the user profile to MPC cluster 130. To ensure the security of the request to generate and upload the user profile, content platform 150 may send an upload token M to application 112. upload .

[0086] Upload token M upload Can have the same token as the update token M update Similar structure, but with different operations (e.g., "update server" instead of "accumulate user profile"). Upload Token M upload An additional item for an operation delay may also be included. The operation delay may instruct the application 112 to delay computing and uploading the secret share of the user profile while the application 112 accumulates more event data, such as more feature vectors. This enables the centroid model to capture user event data immediately before and after some key events, such as joining a user group. The operation delay may specify a delay period. In this example, a digital signature may be generated based on the other seven items in Table 1 and the operation delay using the content platform's private key. The content platform 150 may use the application's public key to update the token M update A similar approach is used for uploading token M upload Encryption, for example, PubKeyEnc(M upload ,application_public_key) to protect the upload token M during transmission upload .

[0087] Application 112 can receive the upload token M upload If the upload token M upload If it is encrypted, decrypt it and verify the upload token M upload This verification can be combined with the verification update token M update The application 112 can verify the upload token M in the following way upload : (i) verifying the digital signature using the public key of the content platform 150 corresponding to the private key of the content platform 150 used to generate the digital signature and (ii) ensuring that the token creation timestamp is not out of date, e.g., the time indicated by the timestamp is within a threshold amount of time of the current time at which the verification is performed. uploadIf any of the verifications fail, the application 112 may ignore the upload request, for example, by not generating a user profile.

[0088] In some embodiments, the content platform 150 may request the application 112 to upload the user profile without a profile upload token M. upload For example, a script originating from content platform 150 running inside application 112 can transmit the upload request directly to application 112 via the scripting API, where application 112 relies on the W3C origin-based security model and / or HTTPS to protect the upload request from forgery or leakage or man-in-the-middle attacks.

[0089] If it is determined not to generate a user profile, process 300 may return to operation 302 and await additional event data from content platform 150. If it is determined to generate a user profile, application 112 generates the user profile (308).

[0090] The application 112 may generate a user profile based on stored event data, such as the data stored in the data structure shown in Table 2. The application 112 may generate a user profile based on a model identifier included in the request, such as the upload token M. upload The content platform eTLD+1 domain in item 1 and the model identifier in item 2 are used to access the appropriate data structure.

[0091] Application 112 can calculate a user profile by aggregating n-dimensional feature vectors in the data structure that have not yet expired and are in the learning period. For example, the user profile can be the average of the n-dimensional feature vectors in the data structure that have not yet expired and are in the learning period. The result is an n-dimensional feature vector representing the user in the profile space. Optionally, application 112 can normalize the n-dimensional feature vector to unit length, for example, using L2 normalization. Content platform 150 can specify an optional learning period.

[0092] In some embodiments, the decay rate can be used to calculate the user profile. Since there may be many content platforms 150 using the MPC cluster 130 to train the centroid model, and each content platform 150 may have multiple centroid models, storing user feature vector data may result in a large amount of data storage requirements. To generate the user profile for training the machine learning model, using decay techniques can significantly reduce the amount of data stored at each client device 110.

[0093] For a given centroid model, assume there are k eigenvectors {F1, F2, ... F k}, each feature vector is an n-dimensional vector and its corresponding age (record_age_in_seconds i). The application 112 may calculate the user profile using the following relation 1:

[0094] Relationship 1:

[0095] In this relation, the parameter record_age_in_seconds i is the amount of time in seconds that the profile record has been stored at the client device 110, and the parameter decay_rate_in_seconds is the decay rate of the profile record in seconds (e.g., before updating the token M update 6). In this way, more recent feature vectors are given greater weight. This also enables application 112 to avoid storing feature vectors and only store profile records with constant storage. Instead of storing multiple separate feature vectors for each model identifier, application 112 only needs to store an n-dimensional vector P and a timestamp user_profile_time for each model identifier.

[0096] To initialize the n-dimensional vector user profile P and timestamp, the application can set the vector P to an n-dimensional vector with the value of each dimension zero and set user_profile_time to the epoch. x To update the user profile P, the application 112 may use the following relation 2:

[0097] Relationship 2:

[0098] When updating the user profile using Relationship 2, the application 112 may also update the user profile time to the current time (current_time). Note that if the application 112 calculates the user profile using the above-mentioned decay rate algorithm, operation 304 is omitted.

[0099] The application 112 generates a secret share of the user profile (310). The application 112 may use a pseudo-random function to convert the user profile P current (For example, the n-dimensional vector P current ) is split into secret shares. That is, the application 112 can use a pseudo-random function PRF (P i ) to generate user profile P current The two secret shares {[P current,1 ],[P current,2 ]}. The exact split may depend on the secret sharing algorithm and cryptographic library used by the application 112. In some embodiments, the application uses the Shamir secret sharing scheme.

[0100] In some embodiments, the application uses an additive secret sharing scheme, that is, the application 112 generates a random (or pseudo-random) n-dimensional vector nonce. In this example, the application can generate a first secret share (i.e., P current + nonce) and the second secret share (i.e., P current -nonce). Application 112 may then delete the n-dimensional vector nonce.

[0101] To prevent malicious applications 112 from abusing the upload API to upload secret shares of user profiles, the MPC cluster 130 may require the trust token issuer to sign the secret shares. i For each of the m user groups represented by , and each of the computing systems MPC1 and MPC2 in the MPC cluster 130, the application 112 can initiate a trust token redemption process with the trust token issuer to obtain a signed redemption record (SRR). The m user groups can be: (i) a user group that sends an upload token M upload and (ii) a user group managed by the content platform 150 (or digital component provider 160 ) and (iii) a user group that includes the user as a member, for example, a user group identified in a user group list maintained by the application 112 .

[0102] During the trust token redemption process, the application 112 may redeem a trust token previously issued to the application 112 based on the client device 110 and / or the application 112 being deemed trusted. This may include sending the trust token and information (e.g., the eTLD+1 and binding of the computing system MPC1 or MPC2) to the trust token issuer and requesting the redemption of the trust token. The trust token issuer may respond by providing the SRR to the application 112. The application 112 may redeem the trust token for each SRR. An example format of an SRR is as follows:

[0103] As shown in Table 3.

[0104]

[0105] Table 3

[0106] The application 112 may compute a message authentication code (eg, a hash-based message authentication code (HMAC)) for the model identifier, the secret share of the user profile for which the SRR is generated, the user group L i , and the public key of application 112 (application_public_key), as a binding. For example, the binding can be expressed as HMAC(model_id,share,L i , application_public_key). For a given user profile and a given centroid model, the application 112 may calculate the code twice, the user profile Pcurrent Each secret of is shared once, and thus once for each computing system MPC1 and MPC2. For example, the parameter "share" of the SRR for computing system MPC1 can be [P current,1 ], and the parameter “share” used to calculate the SRR of the system MPC2 can be [P current,2 ].

[0107] The trust token issuer can generate a timestamp and a digital signature. The trust token issuer can generate a digital signature using the trust token issuer's private key. This enables the recipient of the SRR to verify the signature using the public key corresponding to that private key.

[0108] For the user group identifier L i For each of the m user groups represented by , and each of the computing systems MPC1 and MPC2 in MPC cluster 130 , application 112 may then create a user profile update token M for transmission to MPC cluster 130 . profileupdate User profile update token M profileupdate The example format is shown in Table 4 below.

[0109]

[0110] Table 4

[0111] The application 112 may generate a timestamp and a digital signature. The application 112 may generate a digital signature using the private key of the application 112 corresponding to the public key in item 4. This enables the user profile update token M profileupdate The recipient of the signature can verify it using the public key that corresponds to the private key.

[0112] The compromised application 112 may initiate the user profile update operation itself instead of using the user profile update token M. profileupdate To enable the MPC cluster 130 to detect this situation, the application 112 may optionally update the token M in the user profile. profileupdate The update token M received from the content platform 150 is included update .

[0113] Application 112 transmits a request using the user profile of the user to update the user profile for the model at MPC cluster 130 (312). Each request may include a secret share of the user profile. For example, application 112 may transmit a request with user profile P to computing system MPC1. current The first secret sharing [P current,1 ]'s user profile update token M profileupdate , and transmits to the computing system MPC2 a file with the user profile P currentThe second secret sharing [P current,2 ]'s user profile update token M profileupdate The application 112 may perform this operation for each model identifier for which a user profile update token is created.

[0114] In this process, application 112 sends m requests to update user profiles for each of the two computing systems MPC1 and MPC2 in MPC cluster 130, one for each of the m user groups. For a compromised computing system in MPC cluster 130, it is possible to correlate these m requests. This attack could allow the compromised computing system to learn that application 112 (and its users) may belong to multiple user groups, as well as the identifiers of these groups.

[0115] To mitigate this risk, the MPC cluster 130 may be utilized. To upload the secret share to computing system MPC1, application 112 may send a single request to computing system MPC2, where all user profile update tokens have the first secret share for the user profile of computing system MPC1 individually encrypted using the public key of computing system MPC1. current,1 ] The single request may include a PubKeyEnc(M profileupdate_1 ,MPC1),PubKeyEnc(M profileupdate_2 ,MPC1),…PubKeyEnc(M profileupdate_m ,MPC1) where PubKeyEnc represents a probabilistic asymmetric encryption algorithm, and MPC1 represents the asymmetric public key of the computing system MPC1.

[0116] The probabilistic nature of PubKeyEnc provides semantic security. A semantically secure scheme is one in which only negligible information can be extracted from the encryption result. Without collusion with computing system MPC1, computing system MPC2 cannot infer any information from the list of encrypted tokens. Computing system MPC2 can decompose the list of tokens and send m requests to computing system MPC1, one for each user profile update token M. profileupdate A request. Computing system MPC2 may use a random or pseudo-random delay between consecutive requests. In another example, computing system MPC2 may batch upload multiple requests from multiple applications 112 running on multiple client devices 110 to computing system MPC1 to prevent requests from the same application 112 from being correlated.

[0117] The application 112 can use similar techniques to upload second secret shares for the computing system MPC2. That is, the application 112 can send a single request to the computing system MPC1 with all of the user profile update tokens having second secret shares for the user profile of the computing system MPC2 individually encrypted with the public key of the computing system MPC2 [P current,2 ]. The single request can include a set of encrypted results in the form of PubKeyEnc(M profileupdate_1 , MPC2), PubKeyEnc(M profileupdate_2 , MPC2),... PubKeyEnc(M profileupdate_m , MPC2), where MPC2 denotes the asymmetric public key of the computing system MPC2. The computing system MPC1 can decompose the list of tokens and send m requests to the computing system MPC2, one for each user profile update token M profileupdate One example uses delayed or batched uploads as described above. Given that the computing systems MPC1 and MPC2 can receive a large number of requests, it would be difficult, if not impossible, for the computing system MPC1 or MPC2 to use these techniques to associate the tokens with individual client devices 110.

[0118] The computing systems MPC1 and MPC2 can verify each received request to update a user profile. Upon receiving a request with the encrypted result PubKeyEnc(M profileupdate_i , MPC j ), where j is 1 or 2 (depending on the computing system), the computing system MPC j decrypts the encrypted result to recover the user profile update token M profileupdate_i in plaintext form. The computing system MPC j verifies the user profile update token M profileupdate_i . To do so, the computing system MPC j uses the public key obtained from the trust token issuer domain in item 1.4 of the SRR to verify the digital signature in item 1.5 of the SRR (see Table 3). The computing system MPC j may also use the public key of the application 112 that sent M profileupdate_i to the MPC cluster 130 to verify the digital signature in item 7 of the user profile update token M profileupdate_i (see Table 4).

[0119] The computing system MPC j may also verify that the signature timestamp in item 1.3 of the SRR is not outdated, e.g., by ensuring that the timestamp is within a threshold duration of the current time at which the verification is performed. The computing system MPC j may also verify that the publisher origin in item 1.2 of the SRR matches the current computing system MPCj The identity of the computing system MPC j It is also possible to verify that the binding value in item 1.1 of the SRR is updated with the token M according to the user profile. profileupdate_i The HMAC (model_id, share, L i , application_public_key) matches. The computing system MPC can also verify the user profile update token M profileupdate_i The token creation timestamp in item 5 of is not out of date, for example, by ensuring that the token creation timestamp is within a threshold duration of the current time at which the validation is performed. Computing System MPC j The token creation timestamp can also be used to detect potential replay attacks, for example, updating a token based on multiple user profiles with the same token creation timestamp. If any of these verifications fail, the system MPC is calculated. j The request can be ignored.

[0120] Each computing system MPC1 and MPC2 may maintain a table (or other suitable data structure) including data for each centroid model. For example, the table may be in the form of Table 5 below.

[0121] Model ID User group ID Total sum of all shares Number of applications Model_id [[ L i ]]> Sum_of_shares Number_of_applications … … … …

[0122] Table 5

[0123] The row of a centroid model includes the model identifier (model_id), the user group identifier (L i ), the sum of all shares received for the user profile for the centroid model, and the number of unique applications 112 (e.g., the number of unique client devices) that submitted secret shares for the user profile for the centroid model and whose secret shares are included in the sum of all shares for the centroid model. The sum of all shares is an n-dimensional vector corresponding to the n-dimensional vector of the user profile.

[0124] When receiving the computing system MPC j Model / user group pairs {model_id,L i}, the calculation system MPC j The sum of all shares for a centroid model may be initialized to a zero vector and the number of applications to zero. To process a valid request to update a user profile for a centroid model containing a particular model / user group pair, the computing system MPC j The row for the centroid model / user group pair can be found in the table and the sum of all shares and the number of applications for that centroid model / user group pair can be updated. jThe received secret share of the user profile may be added to the sum of all shares for the centroid model / user group pair, and the number of applications increased by one.

[0125] Example processes for generating and using centroid models

[0126] Figure 4 is a flow chart illustrating an example process 400 for generating a centroid model. The operations of process 400 may be performed, for example, by Figure 1 The operations of process 400 may also be implemented as instructions stored on one or more non-transitory computer-readable media, and execution of the instructions by one or more data processing devices may cause the one or more data processing devices to perform the operations of process 400. Although process 400 is described in terms of generating multiple centroid models, process 400 may also be used to generate a single centroid model for a single user group.

[0127] Each computing system MPC1 and MPC2 obtains a table of user profile data (402). For example, the table may be in the form of Table 5 described above. Using the model identifier and the user group ID, the computing system MPC1 may obtain a table including, for each model identifier and user group pair, the first secret shared [P] for the user group included in the centroid model identifier received from the application 112 using the model identifier and the user group ID. current,1 Similarly, the computing system MPC2 may obtain a table including, for each model identifier and user group pair, the second secret share [P current,2 ]’s sum.

[0128] Each computing system MPC1 and MPC2 implements a user group size threshold for each model identifier (404). For example, each computing system MPC1 and MPC2 can implement a size threshold for each row of its table. To implement the user group size threshold, each computing system MPC1 and MPC2 can determine whether the number of applications exceeds a predefined size threshold for the model identifier.

[0129] Computing systems MPC1 and MPC2 inform each other of rows of the table that satisfy the size threshold (e.g., the information for each model identifier / user group ID pair) (406). For example, computing system MPC1 can send to computing system MPC2 the model identifier, user group identifier, and number of applications for each row for which the number of applications exceeds the size threshold. In addition, computing system MPC1 can send to computing system MPC2 the second half of the sum of shares (sum_of_shares1) for each of these rows to computing system MPC2. Only the second half of sum_of_shares1 is transmitted based on the horizontal partitioning strategy discussed below.

[0130] Similarly, computing system MPC2 can send to computing system MPC1 the model identifier, user group identifier, and number of applications for each row for which the number of applications exceeds the size threshold. In addition, computing system MPC2 can send to computing system MPC1 the first half of the sum of shares (sum_of_shares2) for each of these rows to computing system MPC1.

[0131] Computing system MPC1 matches the rows in its table for which the number of applications exceeds the size threshold with the rows received from computing system MPC2. For example, computing system MPC1 can use the user group identifier and / or model identifier of the rows to match corresponding rows for the same model and user group. Similarly, computing system MPC2 matches the rows in its table for which the number of applications exceeds the size threshold with the rows received from computing system MPC1. For example, computing system MPC2 can use the user group identifier and / or model identifier of the rows to match corresponding rows for the same model and user group. An example result of this size threshold enforcement and cross-notification in tabular form at computing system MPC1 is shown in Table 6 below.

[0132]

[0133]

[0134] Table 6

[0135] Similarly, an example result of the size threshold enforcement and cross-notification in tabular form at computing system MPC2 is shown in Table 7 below.

[0136]

[0137] Table 7

[0138] For each row, ideally, if both the "number of applications from MPC1" and the "number of applications from MPC2" are present for a given pattern identifier, the values ​​for both should be the same. Due to delays in processing, the two values ​​may differ slightly. If both values ​​are present and the two values ​​vary significantly, or if one of the values ​​does not exceed the size threshold, then the computing system that provides a value that does not exceed the size threshold may be impaired. For those rows where the values ​​in "number of applications from MPC1" and "number of applications from MPC2" meet the proximity threshold (e.g., are within a threshold difference of each other) and both exceed the size threshold, the computing system can calculate their centroid.

[0139] Computing systems MPC1 and MPC2 calculate the centroid of the centroid model (408). Computing system MPC1 can calculate the first half of the centroid vector for the user group in the row that meets the proximity (e.g., within a threshold difference) and size thresholds. Computing system MPC1 can calculate the centroid of the model identifier and the user group (e.g., a row) using the following relationship 3.

[0140] Relationship 3:

[0141] Similarly, the computing system MPC2 may compute the model identifier and the centroid of a user group (eg, a row) using the following relation 4.

[0142] Equation 4:

[0143] The centroids of user groups are generally not privacy sensitive and cannot be easily manipulated to allow malicious application 112 , content platform 150 , or computing systems MPC1 and MPC2 of MPC cluster 130 to steal user profiles.

[0144] At the end of this process, computing system MPC1 has the first half of the centroids for all lists that exceed the list size threshold. An example of the results of this process is shown in tabular form in Table 8 below. Computing system MPC2 has the same data for the second half of the centroid vectors for each model identifier and user group identifier. The trained centroid models for the user groups may include a first centroid model that includes the first half of the centroid for each of the user groups and a second centroid model that includes the second half of the centroid for each user group.

[0145]

[0146] Table 8

[0147] Figure 5 is a swim lane diagram illustrating an example process 500 for adding a user to a user group using a centroid model. The operations of process 500 may be performed, for example, byFigure 1 The MPC cluster 130 and the client device 110 are implemented, for example, by the application 112 running on the client device 110. The operations of the process 500 can also be implemented as instructions stored on one or more computer readable media, which can be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process 500.

[0148] In response to a request from the content platform 150 or the digital component provider 160, the application 112 running on the client device 110 can query the MPC cluster 130 for user groups that the user is recommended for. For example, the request can be to use a centroid model generated for and owned by the requestor to determine whether the user should be added to a user group owned by the requestor. For example, the content platform 150 can manage many user groups, and the MPC cluster 130 can train and use one or more centroid models for the user groups to determine whether the user should be added to those user groups.

[0149] To request the application to query the centroid model, the requestor can transmit a download group token M download to the client device 110. download The token M download may have the items shown and described in Table 9 below.

[0150]

[0151]

[0152] Table 9

[0153] In some implementations, the content platform 150 can encrypt the download group token M download using the public key of the application 112. The content platform 150 can then call the application’s API to fetch the user group identifiers via its own or the SSP’s script. The application 112 can decrypt and verify the download group token M download in the same way it decrypts and verifies the user profile update token M profileupdate .

[0154] For a given tuple of model_id, user profile P, and threshold distance d, the application 112 should fetch all user group identifiers L i for which |P - Centroid(model_id, L i ) | < d. In this example, the function “Centroid(model_id, L i )” returns the value in the centroid column in the row in Table 8 that is tagged by model_id and L i .

[0155] To prevent computing system MPC1 or MPC2 from learning about user profile P as a whole, application 112 divides user profile P of the user into multiple parts (502). Application 112 may divide the user profile into corresponding parts for each computing system of MPC cluster 130. In this example, application 112 may split the user profile into two parts, a first part for computing system MPC1 and a second part for computing system MPC2. Assume that user profile P is an n-dimensional vector and user profile P = {p1, p2, ..., p n}, then the two halves P1 and P2 will be P1={p1,p2,…,p n / 2} and P2={p n / 2+1 ,…,p n The computing systems MPC1 and MPC2 can calculate the centroid of their user groups accordingly, i.e., Centroid(model_id,L i ) becomes Centroid1(model_id,L i ) and Centroid2(model_id,L i ).

[0156] In some embodiments, the application 112 may also add differential privacy noise to better protect user privacy. For example, the application 112 may add a one-time user noise ΔP to the user profile P before splitting the user profile P into multiple parts.

[0157] Let P' = P + ΔP. Application 112 applies horizontal partitioning to divide P' into two halves, P1' and P2'. Let d' = d + |ΔP|. Application 112 sends the first half P1' to computing system MPC1 (504). For example, application 112 may send a request with two parameters {P1', d'} to computing system MPC1. The request may obtain all user group identifiers L i , where |P1'-Centroid1(model_id,L i )| <d’。

[0158] Similarly, the application 112 sends the second half P2' to the computing system MPC2 (506). For example, the application 112 may send a request with two parameters {P2', d'} to the computing system MPC2. The request may obtain all user group identifiers L i , where |P2'-Centroid1(model_id,L i )| <d’。

[0159] The computing system MPC1 may determine the user groups having a centroid within a threshold distance d' of the first half P1' of the user profile P' (508). The computing system MPC1 may determine for each user group the distance between the first half P1' and the centroid of the user group, i.e., |P1'-Centroid1(model_id,L i )|. The application 112 may then determine which user groups have a distance less than the distance d'. The user group identifiers of these user groups may be denoted by U1.

[0160] Similarly, computing system MPC2 may determine user groups having centroids within a threshold distance d' of the second half P2' of user profile P' (510). Computing system MPC2 may determine, for each user group, the distance between the second half P2' and the centroid of the user group, i.e., |P2'-Centroid1(model_id,L i )|. The application 112 may then determine which user groups have a distance less than the distance d'. The user group identifiers of these user groups may be denoted by U2.

[0161] Computing system MPC1 transmits user group identifier set U1 to application 112 (512). Similarly, computing system MPC2 transmits user group identifier set U2 to application 112 (514).

[0162] The application 112 calculates a set of user groups for the user (516). The application 112 can use the sets U1 and U2 to calculate the set that satisfies |P-Centroid(model_id,L i )| <d的所有用户组标识符L i The set U. Since The application 112 can compute the set U from U1 and U2, since U = {L i}, where |P-Centroid(model_id,L i )| <d且L i ∈U1∪U2.

[0163] The previous approach assumes that the centroid of the user group is not privacy sensitive and that it is acceptable to leak the superset of user groups that the browser should join (i.e., U1 and U2) to MPC1 and MPC2. In cases where stronger privacy protection is required, the following approach can be adopted. Figure 6 is a swim lane diagram illustrating an example process 600 for generating a centroid model and using the centroid model to add a user to a user group corresponding to the centroid model with enhanced privacy protection. The operations of process 600 may be performed, for example, by Figure 1The operations of process 600 can be implemented as one or more instructions stored on one or more computer-readable media which can be non-transitory and executed by one or more data processing apparatuses. The one or more data processing apparatuses can be specifically programmed, configured, or constructed to perform the operations of process 600. For example, the operations of process 600 can be implemented as instructions stored on one or more computer-readable media, which can be non-transitory, and executed by the MPC cluster 130 and the client device 110, e.g., the application 112 running on the client device 110. The operations of process 600 can also be implemented as instructions stored on one or more computer-readable media, which can be non-transitory, and execution of the instructions by one or more data processing apparatuses can cause the one or more data processing apparatuses to perform the operations of process 600.

[0164] The MPC cluster 130 can train a centroid model for one or more user groups. In this example, the centroid model is queried using secret sharing of user profiles. Thus, each computing system MPC1 and MPC2 can determine a respective secret share of a centroid of a user group using secret shares of user profiles of a training set, e.g., secret shares of user profiles uploaded by the client device 110.

[0165] For each user group, the computing system MPC1 computes a first secret share of a centroid of the user group (602). The centroid of the user group identified by the model identifier model id and the user group identifier L i The centroid of the user group identified by the model identifier model id and the user group identifier L i may be represented as sum of profile(model id, L i ). The first secret share of all user profiles P i that are members of the user group L model_id,i,1 is [sum of profile j,1 ] =∑[P i ]. That is, the first secret share of the centroid of the user group L i represents a sum of the first secret shares of user profiles P i in the user group L

[0166] For each user group, the computing system MPC2 computes a second secret share of a centroid of the user group (604). The centroid of the user group identified by the model identifier model id and the user group identifier L i The centroid of the user group identified by the model identifier model id and the user group identifier L i may be represented as sum of profile(model id, L i ). The second secret share of all user profiles P i that are members of the user group L model_id,i,2 is [sum of profile j,2 ] =∑[P i ]. That is, the second secret share of the centroid of the user group L i represents a sum of the second secret shares of user profiles P i in the user group L

[0167] The centroid model may include a first share of the centroids for each user group and a second share of the centroids for each user group. The first share of each centroid may be maintained confidentially on computing system MPC1, and the second share of each centroid may be maintained confidentially on computing system MPC2.

[0168] Application 112 running on client device 110 divides the user profile of the user into secret shares (606). For example, application 112 may calculate a first secret share [P1] for user profile P of computing system MPC1 and a second secret share [P2] for user profile P of computing system MPC2. The exact split may depend on the secret sharing algorithm and cryptographic library used by application 112. In some embodiments, the application uses the Shamir secret sharing scheme.

[0169] Application 112 sends a request to computing system MPC1 to retrieve a user group identifier for the user (608). The request may include a first secret share [P1] of user profile P. In some embodiments, the request includes a query token M query1 The example format of the query token is shown in Table 9 below.

[0170] Application 112 sends a request to computing system MPC2 to retrieve a user group identifier for the user (610). The request may include a second secret share [P2] of user profile P. In some embodiments, the request includes a query token M query2 The example format of the query token is shown in Table 9 below.

[0171]

[0172]

[0173] Table 9

[0174] In some implementations, the application 112 may send two separate requests, such as Figure 6 To save bandwidth and battery consumption of the client device 110, the application 112 may combine two requests (eg, two query tokens M query1 and M query2 ) into a single request and send the single request to one of the computing systems MPC1 or MPC2. To this end, the application 112 may encrypt the query token intended to be sent to the other computing system MPC1 or MPC2. For example, the application 112 may encrypt the query token M using the encryption public key of the computing system MPC2. query2 For example, the application 112 may generate an encryption result PubKeyEnc(M using the public key of the computing system MPC2) using the public key of the computing system MPC2. query2, MPC2). The application 112 can then query the token M query1 And the encryption result PubKeyEnc(M query2 , MPC2) is sent to the computing system MPC1.

[0175] The computing system MPC1 can verify the update token M with the computing system MPC1 profileupdate Verify the query token M in a similar way query1 , as mentioned above Figure 3 The computing system MPC1 can also transmit the encryption result PubKeyEnc(M query2 , MPC2). The computing system MPC2 can use the same query2 The computing system MPC2 can then verify the update token M with the computing system MPC2. profileupdate Verify the query token M in a similar way query2 , as mentioned above Figure 3 described.

[0176] In some embodiments, each computing system MPC1 and MPC2 may determine a user group eligibility, eligible_group, for each of the plurality of user groups associated with the centroid model. i The corresponding secret sharing. User profile and user group eligibility eligible_group i Indicates whether the user profile of the user is within a threshold distance of the centroid of the user group based on the centroid model.

[0177] In this example, each computation MPC1 and MPC2 can look up all user groups L associated with the model identifier model_id i , where 1≤i≤N and N is the number of user groups associated with the model identifier model_id. For each user group L i , the computing system MPC1 can calculate the Euclidean distance [d i,1 ]Square's first secret sharing.

[0178] Relationship 5: [d i,1 ]=∑([P1]×num_apps_group i -[sum_of_profile_model_id i,1 ]) 2

[0179] In equation 5, the parameter num_apps_group irepresenting in the user group and the user profile is used to generate the user group L i the number of applications (e.g., the number of different users) of the centroid. The computing system MPC1 can then use the following relationship 6 to compute the user group eligibility eligible_group i for the user profile and the user group. i,1

[0180] Relationship 6: [eligible_group i,1 ] = [d o,1 ] < (num_apps_group i x d) 2

[0181] That is, the computing system MPC1 can compute whether the first secret share of the Euclidean distance is less than the threshold distance. The computing system MPC2 can compute the user group eligibility eligible_group i for the user profile and the user group in a similar manner using the following relationships 7 and 8. i,2

[0182] Relationship 7: [d i,2 ] = ∑([P2] x num_apps_group i - [sum_of_profile_model_id i,2 ]) 2

[0183] Relationship 8: [eligible_group i,2 ] = [d i,2 ] < (num_apps_group i x d) 2

[0184] Each computing system MPC1 and MPC2 can transmit their respective secret shares of the user group eligibility to the application 112. The application 112 can then combine the secret shares to determine whether to add the user to the user group. Since the response size is proportional to the number of user groups in the model, the response size can be large for content platforms that have a large number of user groups associated with the centroid model. However, this technique for determining whether to add a user to a user group can be used in situations where the number of user groups is small or bandwidth consumption is not an issue. The remaining operations of the process 600 provide an improvement to this technique: the technique can be used when the number of user groups can be large and greatly reduces the response size.

[0185] ​​Conceptually, for user profiles and user groups, the user group eligibility eligible_group i , the application 112 may randomly or pseudo-randomly generate two numbers g i and h i , each of which has a value of zero or one with equal probability. In this example, g i and h i There is a 25% chance that the sum of is zero, a 50% chance that it is one, and a 25% chance that it is two.

[0186] The application 112 can estimate the user group eligibility eligible_group i The value of (g i +h i ) == 1. Through Table 10 below, the MPC cluster 130 can inform the application 112 whether its estimation is correct.

[0187]

[0188] Table 10

[0189] For example, if g i +h i ==1 and eligible_group i ==1, then the application correctly estimates eligible_group i The value of g makes the corresponding cell value 1. On the other hand, if g i +h i ==2 and eligible_group i ==1, then the application 112 incorrectly estimates eligible_group i , so that the value of the corresponding cell is 0. In this case, the application 112 can flip its estimate so that the application 112 can correctly estimate eligible_group i It can be verified that the above table is equivalent to: (1-eligible_group i )×(1-(g i +h i -1) 2 )+eligible_group i ×(g i +h i -1) 2

[0190] To implement this concept using secure MPC, application 112 may generate two random (or pseudo-random) seeds (e.g., 16 bytes or another appropriate data size), seed1 and seed2 (612). Application 112 may send the first seed, seed1, to computing system MPC1 (614). Application 112 may send the second seed, seed2, to computing system MPC2 (616).

[0191] The MPC cluster 130 may use a pseudorandom function (PRF) and a seed to generate a number g that may be random or pseudorandom. i and h i The PRF may be a function that generates a value of 0 or 1 with a probability of 50%. For example, the PRF may be PRF(seed,i)→{0,1}. The computing system MPC1 may generate g using the PRF and seed1. i (For example, PRF(seed 1,i )), and the computing system MPC2 can use PRF and seed2 to generate h i (For example, PRF(seed 2,i )). Number g i and h i It is g i +h i The two additive secret shares (which are the application's decision on whether to add the user to the user group L i , which can be expressed as [g i ] and [h i ] to indicate that they are secret shares.

[0192] Instead of calculating in plain text (1-eligible_group i )×(1-(g i +h i -1) 2 )+eligible_group i ×(g i +h i -1) 2 , the MPC cluster 130 uses secret sharing to calculate (1-[eligible_group i ])×(1-([g i +h i ]-1) 2 )+[eligible_group i ]×([g i +

[0193] h i ]-1) 2Note that in this equation, it includes the square of the secret share and the product between two secret shares. Computing the square and the product using secure MPC procedures between the computing systems MPC1 and MPC2 can require one round of remote procedure call (RPC) between the computing systems MPC1 and MPC2. All other operations can be performed locally within each computing system MPC1 and MPC2.

[0194] In particular, each of the computing systems MPC1 and MPC2 can compute a secret share of an estimated flag flag i for each user group L i . The estimated flag flag i for a user group indicates whether the application 112 correctly estimated whether a user should be correctly added to the user group.

[0195] The computing system MPC1 computes a first secret share [flag i,1 ] of the estimated flag flag i for each user group L i (618). The computing system MPC1 can compute the first secret share [flag i,1 ] of the estimated flag flag i for each user group L i using the following relationship 9.

[0196] Relationship 9: [flag i,1 ] = (1 - [eligible_group i,1 ]) x (1 - ([g i ] - 1) 2 ) + [eligible_group i,1 ] x ([g i ] - 1) 2

[0197] The computing system MPC2 computes a second secret share [flag i,2 ] of the estimated flag flag i for each user group L i (620). The computing system MPC2 can compute the second secret share [flag i,2 ] of the estimated flag flag i for each user group L i using the following relationship 10.

[0198] Relationship 10: [flag i,2 ] = (1 - [eligible_group i,2 ]) x (1 - ([h i ] - 1) 2)+[eligible_group i,2 ]x([h i ]-1) 2

[0199] The computing systems MPC1 and MPC2 reconstruct the estimated flags flag i for each user group L i (622). The computing systems MPC1 and MPC2 can use one RPC between the two computing systems MPC1 and MPC2 to reconstruct the estimated flags flag i,1 for each user group L i based on the two secret shares [flag i ]. If the value of the estimated flag flag i for a user group L i is 1, then the application accurately estimated whether the user should be added to the user group L i . Because neither computing system MPC1 nor MPC2 knows what the application 112 actually estimated, knowing the value of the estimated flag flag i for a user group L i does not leak any information to either computing system MPC1 or MPC2.

[0200] The computing system MPC1 communicates the estimated flags flag i for each user group L i to the application 112 (624). For example, the computing system MPC1 can communicate {flag1, flag2,...} for the user groups to the application 112. The plaintext flags flag i have values of either zero or one, i.e., indicating whether the estimation was correct or incorrect. That is, a value of one means that the application 112 correctly estimated whether the user should be added to the i-th group, and a value of zero if it did not estimate correctly. Thus, each plaintext flag flag i can be represented with 1 bit.

[0201] For each user group associated with the centroid model, the computing system MPC1 can return a single bit (flag i ). For a centroid model with one million user groups, the response size would be 128 kilobytes (KB), which is feasible based on the required latency of the request and the frequency at which requests are submitted to the MPC cluster 130.

[0202] The application 112 determines whether to add the user to the user group based on the estimated flags (626). For each user group, the application can compute flag i == (g i + h i= = 1). The operation "= = " represents an equality operation, which returns true if two values ​​are equal. If the result of the calculation is true, the application 112 should join the i-th user group associated with the centroid model.

[0203] Application 112 may then request from MPC cluster 130 the user group identifiers for the user groups that application 112 should join. To this end, application 112 may initiate an intensive privacy information retrieval (PIR) on computing systems MPC1 and MPC2 using any suitable intensive privacy information retrieval (PIR) algorithm and implementation. Some implementations rely on a distribution point function (DPF). In such implementations, application 112 may generate a DPF (628). For the i-th user group that application 112 should join, application 112 may generate two DPFs, g i and h i , so that if j = i, g i (j)+h i (j) = 1, otherwise g i (j)+h i (j)=0.

[0204] Application 112 may send a first request to computing system MPC1 (630). The first request may include a point function g for each user group that application 112 should join. i .

[0205] Application 112 may send a second request to computing system MPC2 (632). The second request may include a point function h for each user group that application 112 should join. i .

[0206] For each point function g i , the computing system MPC1 calculates the first secret share of the user group identifier result and returns it to the application 112 (634). The application 112 can calculate the first secret share of the user group identifier result using the following relation 11.

[0207] Equation 11: result i,1 =∑ j g i (j)×group_id j

[0208] For each point function g i , the computing system MPC2 calculates the second secret share of the user group identifier result and returns it to the application 112 (636). The application 112 can calculate the second secret share of the user group identifier result using the following relation 12.

[0209] Equation 12: result i,2 =∑j h i (j)×group_id j

[0210] The application 112 may add the user to one or more user groups (638). The application 112 may use the first shared result for the user group i,1 and the second shared result i,2 To reconstruct the user group identifier of each user group that the user should join. For example, if the two secret shares are additive secret shares, the application 112 can calculate the sum of the two secret shares to obtain the user group identifier of the user group. The application 112 can then add the user group identifier to the user group list.

[0211] exist Figure 6 In this process 600 , the computing system in the MPC cluster 130 neither knows the centroid of the user group in plain text nor the application query parameters (ie, user profile), nor the user group that the user is about to join, thereby protecting user privacy.

[0212] In the case of relaxed privacy requirements, for example, computing systems MPC1 and MPC2 can know the query results in plain text, and computing systems MPC1 and MPC2 can reconstruct the user group eligibility generated by the two secret shares. i , and only in the corresponding eligible_group i If true, the user group identifier L is included in the query response. i Return to application 112.

[0213] In some embodiments, the training of the centroid model and the querying of the centroid model can be performed by an aggregation service. The aggregation service can include an MPC cluster 130 and communicate with the content platform 150 (e.g., instead of the client device 110). In this case, when querying which user groups the application 112 should join, for privacy reasons, the application 112 cannot send the user profile of the user to the content platform 150 for forwarding to the MPC cluster 130. One option can be to configure the content platform 150 to transmit the centroid of the user group to the application 112. However, this may consume a lot of bandwidth.

[0214] Another option is for the content platform 150 to infer the user group for use based on the user's secure mobile ID (e.g., FLOCID), first-party cookie data received from the first-party cookie, and the URL of the digital component. However, this may not be as accurate as the above-mentioned technique.

[0215] Figure 7is a flow chart illustrating an example process 700 for determining user group results (i.e., whether the application 112 should join one or more user groups) based on the user profile data of the user and the centroid model. The operations of process 700 may be implemented, for example, by the MPC cluster 130. The operations of process 700 may also be implemented as instructions stored on one or more computer-readable media that may be non-transitory, and execution of the instructions by one or more data processing devices may cause the one or more data processing devices to perform the operations of process 700.

[0216] A first request for a user group identifier is received (702). A first computing system of MPC cluster 130 (e.g., MPC1) may receive the first request from application 112 running on client device 110. Application 112 may send a corresponding second request to each other computing system of MPC cluster 130 (e.g., MPC2). The request may be for the user group identifiers of the user groups to which the user is to be added, e.g., each user group for which the user profile of the user is within a threshold distance of the centroid of the user group.

[0217] Typically, each request may include user profile data for a user profile of a user. A first request may include first user profile data, and each second request sent to each second computing system may include corresponding second user profile data. The user profile data may vary based on the encryption technology used.

[0218] For example, if the MPC process and horizontal partitioning are used to determine the centroid, as in Figure 4 As described, each requested user profile data may include a corresponding portion of the user's user profile. If each computing system of the MPC cluster 130 has a secret share of the centroid, each requested user profile data may include the corresponding secret share of the user's user profile. In either case, the user profile data may also include a model identifier and a threshold distance of the centroid model.

[0219] Identify a set of user groups corresponding to the model identifier (704). For example, content platform 150 or digital component provider 160 can have MPC cluster 130 generate a centroid model for the set of user groups. Each computing system in MPC cluster 130 can store data for identifying user group identifiers of user groups corresponding to the centroid model, for example, by linking a model identifier to each user group identifier. The first computing system can identify the set of user groups based on the stored data. Each user group identifier and model identifier can be referred to as a centroid model and user group identifier pair.

[0220] For each user group in the set of user groups, the centroid of the user group is identified (706). When the MPC cluster 130 generates a centroid model, the MPC cluster 130 may determine the centroid of each user group corresponding to the centroid model. The form of the centroid may vary based on the encryption technique used. For example, if the centroid is determined using an MPC process and horizontal partitioning, as described with reference to Figure 4 As described, each computing system of the MPC cluster 130 can have a centroid of the user group determined based on portions (e.g., halves) of the secret shared sum of the user profiles used to generate the centroid. If secret sharing is used, each computing system of the MPC cluster 130 can have a secret shared centroid of the user group.

[0221] Determine user group results (708). The user group results indicate one or more user groups to which the user is to be added. For example, the user group results may indicate user groups having a centroid within a threshold distance of the user's user profile.

[0222] Sending User Group Results ( 710 ) For example, the first computing system may transmit its user group results to the application 112 running on the client device 110 .

[0223] The first computing system may determine the user group results in different ways depending on the encryption technique used, and the user group results may vary based on the encryption technique used. For example, if horizontal partitioning is used, the first computing system may determine, for each user group in the set of user groups, whether the first portion of the user profile included in the first user profile data is within a threshold distance of the centroid of the user group previously determined by the first computing system, as described with reference to Figure 5 As described. In this example, the user group results may include user group identifiers for user groups whose centroids are within a threshold distance of the user profile of the user. Each other computing system may perform a similar process using its centroid and the portion of the received user profile. Each computing system may provide user group results that include user group identifiers for user groups whose centroids are within a threshold distance of the user profile of the user. The application of the client device may then determine a list of user groups to which to add the user based on the user group results received from each computing system, as described with reference to Figure 5 described.

[0224] If secret sharing is used, the user group result may include an estimated flag for each user group in the set of user groups, as referenced Figure 6The estimated flag of the user group indicates whether the application correctly estimated whether the user should be added to the user group. The application 112 can use the estimated flag to determine whether to add the user to the user group, for example, based on whether the application 112 estimated that the user should be added to the user group and whether the estimation was correct. If so, the application 112 can query the MPC cluster 130 for the user group identifier corresponding to the estimated flag.

[0225] Figure 8 8 is a block diagram of an example computer system 800 that can be used to perform the operations described above. System 800 includes a processor 810, a memory 820, a storage device 830, and an input / output device 840. Each of components 810, 820, 830, and 840 can be interconnected, for example, using a system bus 850. Processor 810 is capable of processing instructions for execution within system 800. In some embodiments, processor 810 is a single-threaded processor. In another embodiment, processor 810 is a multi-threaded processor. Processor 810 is capable of processing instructions stored in memory 820 or on storage device 830.

[0226] Memory 820 stores information within system 800. In one embodiment, memory 820 is a computer-readable medium. In some embodiments, memory 820 is a volatile memory unit. In another embodiment, memory 820 is a non-volatile memory unit.

[0227] The storage device 830 can provide a large amount of storage for the system 800. In some embodiments, the storage device 830 is a computer-readable medium. In various embodiments, the storage device 830 can include, for example, a hard disk device, an optical disk device, a storage device shared by multiple computing devices over a network (e.g., a cloud storage device), or some other large-capacity storage device.

[0228] The input / output device 840 provides input / output operations for the system 800. In some embodiments, the input / output device 840 may include one or more of the following: a network interface device (e.g., an Ethernet card), a serial communication device (e.g., an RS-232 port), and / or a wireless interface device (e.g., an 802.11 card). In another embodiment, the input / output device may include a driver device configured to receive input data and send output data to an external device 860, such as a keyboard, a printer, and a display device. However, other embodiments may also be used, such as a mobile computing device, a mobile communication device, a set-top television client device, etc.

[0229] Although already Figure 8An example processing system is described in the specification, but the subject matter and implementation of the functional operations described in this specification may be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them.

[0230] Embodiments of the subject matter and operations described in this specification may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or a combination of one or more thereof. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium (or media) for execution by a data processing device or for controlling its operation. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information transmitted to a suitable receiver device for execution by the data processing device. A computer storage medium may be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more thereof. Furthermore, while a computer storage medium is not a propagated signal, a computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium may also be or be included in one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0231] 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.

[0232] The term "data processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip, or multiple or combinations of the foregoing. The apparatus may include dedicated logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more thereof. The apparatus and execution environment may implement a variety of different computing model infrastructures, such as network services, distributed computing, and grid computing infrastructures.

[0233] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored in a portion of a file containing 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 coordinated files (e.g., files storing portions of one or more modules, subroutines, or code). A computer program may be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0234] The processes and logic flows described in this specification are performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be performed by, and the apparatus may also be implemented as, a special purpose logic circuit, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

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

[0236] To provide for interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) 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. Other types of devices may also be used to provide for interaction with the user; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. In addition, a computer may interact with a user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

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

[0238] A computing system may include a client and a server. The client and server are typically remote from each other and typically interact via a communication network. The relationship between the client and the server is generated by computer programs running on their respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., an HTML page) to a client device (e.g., to display data to a user interacting with the client device and to receive user input from the user). Data generated at the client device (e.g., the result of a user interaction) can be received at the server from the client device.

[0239] Although this specification contains many specific implementation details, these should not be interpreted as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features described in this specification in the context of separate embodiments 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 or in any suitable subcombination in multiple embodiments. Furthermore, although features may be described as working in certain combinations and even initially claimed as such, in some cases one or more features from the claimed combination may be deleted from the combination, and the claimed combination may be self-directed to a subcombination or a variation of the subcombination.

[0240] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that the operations be performed in the particular order shown, or in a sequential order, or that all of the illustrated operations be performed, in order to achieve the desired results. In some cases, multitasking and parallel processing can be advantageous. Furthermore, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments, but rather that the described program components and systems can generally be integrated into a single software product or packaged into multiple software products.

[0241] Thus, certain embodiments of the present subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain embodiments, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method comprising: receiving, from a client device and by a first computing system in a plurality of multi-party computation (MPC) systems, a first request for a user group identifier identifying a user group to which a user is to be added, the first request including a model identifier of a centroid model, first user profile data of a user profile of the user, and a threshold distance; identifying a set of user groups corresponding to the model identifier; identifying, for each user group in the set of user groups, a centroid of the user group determined using a centroid model corresponding to the model identifier; determining, by the first computing system, a user group result based at least on the first user profile data, a centroid of each user group in the set of user groups, and the threshold distance, wherein the user group result indicates one or more user groups to which the user is to be added; and transmitting the user group result to the client device, Wherein the first user profile data comprises a first portion of the user profile, and wherein a centroid of each user group is determined using a secure MPC process between the first computing system and one or more second computing systems of the plurality of MPC systems.

2. The computer-implemented method of claim 1 , wherein: The user group results include one or more user group identifiers of the one or more user groups, and wherein each second computing system transmits a second user group result to the client device, the second user group result including one or more second user group identifiers of one of the one or more second user groups to which the user is to be added based on the corresponding second portion of the user profile, the corresponding second centroid of each user group in the set of user groups, and the threshold distance.

3. The computer-implemented method of any preceding claim, further comprising generating a centroid for each user group in the set of user groups, the generating comprising: obtaining a data structure comprising, for each centroid model and user group identifier pair, a first sum of a share vector representing a sum of a first share of a set of user profiles and a number of client devices from which the first share of the set of user profiles was received; For each centroid model and user group identifier pair, determining whether the number of applications meets a threshold; for each centroid model and user group identifier pair whose number of applications satisfies the threshold, transmitting a first portion of the first sum of shared vectors for the centroid model and user group identifier pair to each of one or more second computing systems in the plurality of MPC systems; receiving, from each of the one or more second computing systems, a portion of a respective second sum of shared vectors for one or more centroid model and user group identifier pairs; For each of the one or more centroid model and user group identifier pairs: determining a sum of each portion of the respective second sum of shared vectors for the centroid model and user group identifier pair and a portion of the first sum of shared vectors for the centroid model and user group identifier pair; as well as A centroid of the user group identified by the user group identifier is determined based on the sum.

4. The computer-implemented method of claim 3, wherein: Determining the centroid of the user group identified by the user group identifier based on the sum includes: dividing the sum by the sum of: (i) the number of client devices for the centroid model and user group identifier pair and (ii) the corresponding number of client devices for the centroid model and user group identifier pair received from each second computing system.

5. The computer-implemented method of claim 1 or 2, wherein: The first user profile data of the user profile includes a first secret share of the user profile, the method further comprising, for each centroid model and user group identifier pair: determining a first number having a value of zero or one based on a random or pseudo-random seed received from the client device, and wherein the first number represents a first secret share of an estimate by an application of the client device of whether to add the user to the user group identified by the user group identifier; as well as A first secret share is derived by performing a first round of a secure MPC process with one or more second computing systems of the plurality of MPC systems using at least the first secret share of the user profile, the first number, a corresponding second secret share of the user profile received by each second computing system, and the corresponding second number received by each second computing system. An estimation flag indicating whether the application correctly estimated whether to add the user to the user group is derived.

6. The computer-implemented method of claim 5 , further comprising: A second round of the secure MPC process is performed with the one or more second computing systems to reconstruct the estimated signature based on the first secret share of the estimated signature and a corresponding second secret share of the estimated signature derived by each of the one or more second computing systems.

7. The computer-implemented method of claim 6, wherein: The user group results include the estimated flag for each centroid model and user group identifier pair.

8. The computer-implemented method of claim 7, further comprising: A first request is received for one or more user group identifiers corresponding to one or more of the estimated indicia, wherein the request includes a distribution point function for each estimated indicia.

9. The computer-implemented method of claim 8, further comprising: For each estimation flag, derive a first user group identifier result using the user group identifier corresponding to the estimation flag and the distribution point function of the estimation flag, wherein the client device determines the user group identifier corresponding to the estimation flag using the first user group identifier result and a corresponding second user group identifier result received from each second computing system in the plurality of MPC systems.

10. A system for privacy-preserving machine learning, comprising: one or more processors; as well as One or more storage devices storing instructions which, when executed by the one or more processors, cause the one or more processors to perform the method of any preceding claim.

11. A computer-readable storage medium carrying instructions that, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 9.

12. A computer comprising a computer-readable storage medium having stored thereon instructions which, when executed by the computer, cause the computer to perform the steps of the method of any one of claims 1 to 9.

Images