Handling requests to control information stored at multiple servers

Abstract

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for sending / processing requests to control information stored at a plurality of content platforms / servers. In one aspect, a client device may send a request to verify trustworthiness of the device to a device trustworthiness server. A client device may receive data from a device trustworthiness server indicating that the client device is trustworthiness, and in response to receiving the data indicating that the client device is trustworthiness, the client device may send a request to a relay server to control user data stored at a plurality of servers. The client device may receive a response from each of the plurality of servers via the relay server. Based on the response, the client device may determine that at least a subset of the plurality of servers including the user data has performed an action specified in the request to control the user data.

Description

[0001] This application is a divisional application of an invention patent application with an application date of September 22, 2020, application number 202080075420.X, and invention name “Processing requests for controlling information stored on multiple servers”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is an international application and claims the benefit of Israel Application No. 276868, filed on August 23, 2020. The disclosure of the above application is incorporated herein by reference in its entirety. Technical Field

[0004] The inventive concept of the present application relates to data processing. In particular, the inventive concept of the present application relates to securely and efficiently transmitting and processing requests for controlling user information (also referred to as user data) stored at multiple content platforms / servers. Background Art

[0005] The present specification generally relates to data processing and the secure and efficient transmission and processing of requests to control information stored at multiple content platforms / servers.

[0006] A user of a client device may request control of user information stored at a particular content platform / server. Such a request to control user data may include, for example, a request to delete all or part of the user information, a request to modify the user data, a request to access the user data, or a request to prevent the user data from being transmitted to any other entity. Because the user information may be stored at multiple different servers, the client device must generate and send a separate request to each such content platform / server. Summary of the invention

[0007] In general, a novel aspect of the subject matter described in this specification can be embodied in a method, the method comprising the following operations: a client device sends a request to verify the trustworthiness of the client device to a device trustworthiness server; the client device receives data indicating that the client device is trustworthy from the device trustworthiness server; in response to receiving the data indicating that the client device is trustworthy, the client device sends a request to control user data stored at multiple servers to a relay server, wherein: the relay server is a server that verifies the request to control the user data before sending the request to control the user data to each of the multiple servers; and the request to control the user data specifies an action to be performed by the server with respect to the user data; the client device receives a response from each of the multiple servers via the relay server; and the client device determines, based on the response, that at least a subset of the multiple servers including the user data have performed the action specified in the request to control the user data. Other embodiments of this aspect include corresponding methods, apparatuses, and computer programs encoded on computer storage devices, the corresponding methods, apparatuses, and computer programs configured to perform the actions of the method. These and other embodiments can each optionally include one or more of the following features.

[0008] In some embodiments, the method may further include: generating, by a client device, a digital token comprising (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying a time when the digital token was created, (3) instructions specifying an action type regarding user data stored at a plurality of servers, and (4) data identifying the plurality of servers; and encrypting, by the client device, the digital token using a symmetric encryption algorithm to obtain an encrypted digital token.

[0009] In some embodiments, encrypting a digital token by a client device using a symmetric encryption algorithm to obtain an encrypted digital token may include: generating an encryption key using a cryptographic pseudo-random function and based on data parameters including a current date, a first data string, and a device identifier; and encrypting the digital token by the client device using the encryption key to obtain an encrypted digital token.

[0010] In some embodiments, generating an encryption key using a cryptographic pseudo-random function and based on data parameters including a current date, a first data string, and a device identifier may include generating the encryption key by: (1) calculating a first message authentication code (MAC) using the current date and the first data string and (2) generating a second MAC using the device identifier and the first MAC.

[0011] In some embodiments, a request to verify the trustworthiness of a client device may include a first data set that may include (1) device trustworthiness data based on which the trustworthiness of the client device is determined and (2) a third MAC generated using the encrypted digital token and the first data parameters.

[0012] In some embodiments, the request for control user data may include a second data set that includes (1) data indicating that the client device is trustworthy, (2) an encrypted digital token, (3) a first data parameter, (4) data identifying multiple servers, and (5) a fourth MAC generated using a device identifier, the second data parameter, and the third data parameter.

[0013] In some implementations, the second data parameter may include the current date and the third data parameter includes the second data string.

[0014] In some implementations, receiving, by the client device, data from the device trustworthiness server indicating that the client device is trustworthy may include receiving, by the client device from the device trustworthiness server, a digital signature by the device trustworthiness server on a third MAC.

[0015] In some embodiments, the action to be performed by the server regarding the user data may include one of the following: deleting the user data stored at the server; requesting that the user data stored at the server not be sent or provided to any other entity; enabling one or more entities to access the user data stored at the server; requesting disclosure of the collected user data; or requesting export of the collected user data.

[0016] According to an embodiment of the present disclosure, a computer-implemented method is provided, comprising: generating a digital token by a client device, the digital token comprising (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying the time when the digital token is created, (3) an instruction specifying an action type regarding user data stored at multiple servers, and (4) data identifying multiple servers; encrypting the digital token by the client device to obtain an encrypted digital token; sending a request by the client device to a device trustworthiness server to verify the trustworthiness of the client device, wherein the request comprises the encrypted digital token; receiving data indicating that the client device is trustworthy from the device trustworthiness server by the client device; and controlling the user data stored at multiple servers by the client device to a relay server.

[0017] According to an embodiment of the present disclosure, a system is provided, comprising: one or more memory devices storing instructions; and one or more data processing devices configured to interact with the one or more memory devices and, when executing the instructions, perform operations including the following: generating a digital token by a client device, the digital token comprising (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying the time when the digital token was created, (3) an instruction specifying an action type regarding user data stored at multiple servers, and (4) data identifying multiple servers; encrypting the digital token by the client device to obtain an encrypted digital token; sending a request by the client device to a device trustworthiness server to verify the trustworthiness of the client device, wherein the request includes the encrypted digital token; receiving data by the client device from the device trustworthiness server indicating that the client device is trustworthy; and controlling the user data stored at multiple servers by the client device to a relay server.

[0018] According to an embodiment of the present disclosure, a non-transitory computer-readable medium is provided, which stores instructions. When the instructions are executed by one or more data processing devices, the one or more data processing devices perform operations, the operations including: generating a digital token by a client device, the digital token including (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying the time when the digital token is created, (3) an instruction specifying an action type regarding user data stored at multiple servers, and (4) data identifying multiple servers; encrypting the digital token by the client device to obtain an encrypted digital token; sending a request by the client device to a device trustworthiness server to verify the trustworthiness of the client device, wherein the request includes the encrypted digital token; receiving data indicating that the client device is trustworthy from the device trustworthiness server by the client device; and controlling the user data stored at multiple servers by the client device to a relay server.

[0019] Particular embodiments of the subject matter described in this specification can be implemented to realize one or more of the following advantages.

[0020] The techniques described in this specification provide resource-efficient techniques to handle large numbers of requests to content platforms / servers that store information for users of client devices. Typically, generating and sending large numbers of requests to various content platforms / servers can consume a large amount of the computing resources (e.g., battery, processor cycles, bandwidth, etc.) of the client device. The techniques described in this specification can significantly reduce the impact on the computing resources of the client device when generating and sending such requests by utilizing a relay server that receives a single request (rather than multiple requests) from the client device and generates and routes the multiple requests to multiple content platforms / servers that store user data.

[0021] Moreover, the technology described in this specification provides a security mechanism that prevents attacks on relay servers from spreading across networks to various content platforms / servers that the relay server communicates with, or at least reduces the possibility of such attacks. For example, a denial of service (DoS) attack can be launched on the relay server, which can in turn spread to various content platforms / servers that the relay server communicates with. Therefore, a DoS attack on the relay server can destroy the operation of the relay server and the operation of various content platforms / servers that the relay server communicates with. In order to prevent or reduce the spread / propagation of such attacks, the technology described in this application implements a device trustworthiness server that verifies the trustworthiness of the requesting client device and provides such trustworthiness indication to the relay server, which in turn verifies the trustworthiness of the device before sending any request / message to various content platforms / servers. Therefore, when a device is considered untrustworthy or when the trustworthiness of the device cannot be verified, the relay server will not submit a request from such a device, which may potentially be a malicious or hacked device.

[0022] Further, the technology described in this specification shields any user / device information provided to the relay server (e.g., identification information that can be used to complete requests for controlling user data stored at various servers), thereby preventing the relay server from intentionally or unintentionally releasing / distributing such information. In some embodiments, the technology described herein encrypts the device identifier (and / or other device / user identification information) within an encrypted token, and applies other security measures to the token before sending the token to the relay server. The technology used to generate the token (described below) prevents the relay server from being able to decipher / decrypt the token, which in turn prevents the relay server from being able to access the device and / or user identification information stored in the token. These protection technologies do not interfere with the operation of the relay server. For example, although the data in the token is inaccessible, the relay server is still able to send requests for controlling user data to various content platforms / servers. Therefore, the technology described in this specification maintains user / device privacy during the process of requesting control of user data, while enabling execution / completion of device requests for controlling user data at various servers.

[0023] The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a block diagram of an example environment in which digital content is distributed and provided for display on client devices.

[0025] Figure 2 is a block diagram of an example environment in which a request from a client device to exercise control over user information stored on a content platform is received and processed.

[0026] Figure 3 is a flow chart of an example process for generating and distributing variants of an audio digital component based on a template generated for the audio digital component.

[0027] Figure 4 is a block diagram of an example computer system that may be used to perform the described operations. DETAILED DESCRIPTION

[0028] The present specification generally relates to securely and efficiently transmitting and processing requests for control of user information (also referred to as user data) stored at multiple content platforms / servers.

[0029] As outlined below and described in greater detail throughout this document, a client device operates in conjunction with a relay server and a device trustworthiness server to generate and send requests for control of user information stored at various servers.

[0030] In some implementations, the client device sends a request to verify the trustworthiness of the client device to a device trustworthiness server. The request may include device trustworthiness data, the device trustworthiness data including a set of signals obtained from the device environment, and the trustworthiness of the client device may be determined based on the device trustworthiness data.

[0031] The device trustworthiness server uses the device trustworthiness data included in the request to verify the trustworthiness of the device. Based on the verification, the device trustworthiness server sends data indicating whether the client device is trustworthy to the client device.

[0032] After receiving data indicating whether the client device is trustworthy from the device trustworthiness server, the client device sends a request to the relay server to control user information stored at various servers. The request to control user information specifies an action to be performed by the server with respect to the user information (e.g., deleting the user information, modifying access rights to the user information, preventing the dissemination of the user information) and specifies the server that will perform the requested action. The request also includes data indicating whether the client device is trustworthy.

[0033] Upon receiving a request from a client device, the relay server verifies the request when it determines that the device is trustworthy based on data received from the device trustworthiness server. Once verified, the relay server sends requests to control user information to the various servers specified in the request from the client device. The server, upon receiving a request from the relay server, verifies the request and performs the appropriate action(s) specified in the request to achieve control of the user information.

[0034] The server then sends responses to the relay server specifying whether the server completed the request. The relay server in turn sends these responses to the client device, providing confirmation as to whether the request to control user information was completed.

[0035] Reference below Figures 1 to 4 These and additional features are described in greater detail.

[0036] With respect to the description throughout this document, controls may be provided for the user to allow the user to select whether and when the systems, programs, or features described herein may collect user information (e.g., information about the user's social network, social actions or activities, occupation, preferences of the user, or the user's current location) or whether to send content or communications from a server to the user. In addition, prior to storing or using specific data, the specific data may be processed in one or more ways so that personally identifiable information may be removed. For example, the user's identity may be processed so that the user's personally identifiable information cannot be determined, or the user's geographic location from which location information (such as a city, zip code, or state and county level) may be generalized so that the user's specific location cannot be determined. Thus, the user may control what information is collected about the user, how the information is used, and what information is provided to the user.

[0037] Figure 1 is a block diagram of an example environment 100 in which digital content is distributed and provided for display on client devices.

[0038] The example environment 100 includes a network 104. The network 104 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof. The network 104 may also include any type of wired and / or wireless network, a satellite network, a cable network, a Wi-Fi network, a mobile communication network (e.g., 3G, 4G, etc.), or any combination thereof. The network 104 may utilize communication protocols, including packet-based and / or datagram-based protocols, such as Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or other types of protocols. The network 104 may further include multiple devices that facilitate network communications and / or form the hardware foundation of the network, such as switches, routers, gateways, access points, firewalls, base stations, repeaters, or a combination thereof.

[0039] The network 104 connects the client device 102, the content platform 106, the device trustworthiness server 110, and the relay server 108. The example environment 100 may include many different content platforms 106, relay servers 108, client devices 102, and device trustworthiness servers 110.

[0040] Content platform 106 is a computing platform that enables distribution of content (such as, for example, reference Figure 4 1. The example content platform 106 may be a web server or another data processing device as described herein. The example content platform 106 includes a search engine, a social media platform, a news platform, a data aggregation platform, or other content sharing platform. The example content platform 106 may be operated by a content platform service provider.

[0041] The content platform 106 may publish its own content and make its own content available. For example, the content platform 106 may be a news platform that publishes its own news articles. The content platform 106 may also present content provided by one or more content providers 108 that are not part of the content platform 106. In the above example, the news platform may also present third-party content provided by one or more content providers 108. As another example, the content platform 106 may be a data aggregation platform that does not publish its own content, but aggregates and presents third-party content provided by different content providers 108.

[0042] In some embodiments, the content platform 106 may store certain information about the client device (e.g., device preference information, content consumption information, etc.). This user information may be used by the content platform, for example, to customize the content provided to the client device 102 or to enable rapid access to specific content frequently accessed by the client device 102. In some embodiments, the content platform 106 may not store such device information on the platform; however, the content platform 106 may still provide such information for storage on a specific server (separate from the content platform). Therefore, the content platform 106 (also referred to herein as the content platform / server 106 or simply the server) refers to the content platform that stores such device information or the server (separate from the content platform) that stores such device information.

[0043] The device trustworthiness server 110 is a server that determines whether the client device 102 is trustworthy (or as referred to in Figure 4 In some embodiments, the client device 102 provides a set of signals referred to in this specification as device trustworthiness data (e.g., the type of device used, the operating system of the device, etc.) to the device trustworthiness server 110. Based on the received device trustworthiness data, the device trustworthiness server 110 determines whether the client device is trustworthy. In some embodiments (and as described below with reference to Figure 2 and Figure 3 As further described), the device trustworthiness server 110 provides an indication to the client device 102 as to whether the client device 102 is trustworthy.

[0044] The relay server 108 is a server (or another suitable data processing device, such as reference 104) that acts as a relay between the client device and the various content platforms / servers 106. Figure 4 ), various content platforms / servers store user information for users associated with the client device 102. The relay server 108 verifies requests for control user information received from the client device 102 before sending such requests to each of the plurality of servers (as described in reference Figure 2 and Figure 3 In some embodiments (and as described below with reference to Figure 2 and Figure 3 As further described), the relay server receives a single request from the client device 102 to utilize user information stored at multiple content platforms / servers 106, verifies the request, and if verified, sends the request to the multiple content platforms / servers 106.

[0045] refer to Figure 2 Additional structural and operational aspects of these components of example environment 100 are described.

[0046] Figure 2 is a block diagram of an example environment 200 associated with transmitting and processing requests from a client device 102 to a plurality of content platforms 106 for control user information.

[0047] like Figure 2 As shown in FIG. 1 , the client device 102 includes an operating system 204, a device trustworthiness client 210, and an application A 202. The operating system 204 is generally responsible for managing the hardware and software resources of the client device 102, such as, for example, the application A 202. In some implementations, the operating system 204 includes a token generator 206 and a MAC generator 208, each of which is described below.

[0048] The token generator 206 generates a digital token using data and instructions for controlling user information stored at the plurality of content platforms / servers 106. In some implementations, the token generator 206 digitally signs the generated digital token using, for example, a private key of the client device 102.

[0049] In some embodiments, the digitally signed token generated by the token generator 206 is a proof token. As used in this specification, a proof is a digital token that includes a data set that may include one or more of the following data items: (1) a unique identifier of the client device 102, (2) a timestamp indicating the creation time of the token (also referred to as a request timestamp), (3) a payload including data indicating a request to exercise control over the user information, and (4) optionally, a device trustworthiness token previously generated by the device trustworthiness server 110 (i.e., the device trustworthiness token may, but need not, be included in the proof token). The proof token also includes a digital signature generated by the token generator 206 by signing the data set included in the proof token using the private key of the client device 102.

[0050] The following paragraphs describe each data item in the dataset and the digital signature of the dataset, as included in the attestation token.

[0051] The unique identifier of the client device 102 included in the certification token can be or include a public key of the client device 102. For example, the client device 102 can generate and / or maintain one or more pairs of cryptographic keys, including a device private key and a device public key. The device public key corresponds to the device private key and is mathematically linked to the device private key. Data digitally signed using the private key can only be verified using the corresponding public key. Similarly, data encrypted using the public key can only be decrypted using the corresponding private key. Alternatively, instead of the public key of the device, another appropriate device identifier can be used, such as (for example) the MAC address of the device.

[0052] The timestamp included in the proof token specifies / indicates the time when the proof token was created. In some embodiments, the timestamp specifies the time (and in some cases the date) when the proof token was created. In some embodiments, the timestamp may be at a high resolution (e.g., such that it may record the creation time in microseconds or even nanoseconds) or at a low resolution (e.g., such that the recorded creation time is in hours or minutes).

[0053] The payload included in the attestation token may include data indicating a request to control user information stored at one or more servers. The data may (1) specify the type of action requested by the user with respect to the data (e.g., delete the data, modify access to the data, prevent further transmission of the data) and (2) specify the scope of the request—that is, whether the requested action is to be performed at a specific content platform(s) / server(s) 106 or at the content platform(s) / server(s) with which the relay server(s) 108 (receiving the request) communicates. If the scope of the request specifies the requested action at specific content platform(s) / server(s) 106, then the payload may also include domain address(es) or other types of identifiers for those platform(s) / server(s) 106.

[0054] A device trustworthiness token, which may optionally be included in the attestation token, enables an entity to determine whether the attestation token was sent by a trusted client device 102. The device trustworthiness token may be issued by a third-party device integrity system (such as a device trustworthiness server 110) that evaluates a set of signals corresponding to a particular client device and assigns a trustworthiness level (e.g., a numerical score within a range of scores, a binary determination of trustworthiness) to the client device 102 based on the evaluation.

[0055] In some implementations, the device trustworthiness token of the client device 102 may include (1) a determination indicating the trustworthiness (or integrity) level of the client device 102 at the time the device trustworthiness token was generated, (2) a device trustworthiness token creation time indicating the time when the device trustworthiness token was generated, and (3) a unique identifier of the client device 102 (which may be, for example, a device public key of the client device or a derivative thereof). The device trustworthiness token may also include a digital signature of the data in the device trustworthiness token. The digital signature may be generated using a private key of the device trustworthiness server 110.

[0056] For example, the device trustworthiness server 110 may sign data using a private key that is maintained in secret by the server 110. An entity that receives a device trustworthiness token may verify the signature of the device trustworthiness token using the public key of the device trustworthiness server 110. Furthermore, including the device public key of the client device 102 (or a derivative thereof, e.g., a digital digest) in both the device trustworthiness token and the proof token binds the two tokens together. In other words, by including the device public key of the client device 102 (or another appropriate device identifier) ​​in the device trustworthiness token, the recipient of the proof token can determine that the device trustworthiness token was generated for the client device 102. This prevents, for example, other parties from including a device trustworthiness token of a trusted device in a tampered request from an emulator or a compromised client device.

[0057] The digital signature included in the attestation token may be a digital signature of the above-described data set (or some variation thereof). The digital signature is generated using a device private key of the client device 102, which may be securely and privately maintained by the operating system 204 of the client device 102. In some embodiments, the digital signature may be a digital signature of a payload, a device identifier (e.g., a device public key), a timestamp, and a device trustworthiness token. In some embodiments, the operating system 118 generates the digital signature using an elliptic curve digital signature algorithm (ECDSA), although other signature techniques, such as RSA, may also be used.

[0058] In some cases, another type of digitally signed token may be generated by the token generator 116, which may also be used to protect the communication of the request for control user information and any corresponding data. For example, in such embodiments, the data may be digitally signed using a private key of a third-party integrity system, such as the device trustworthiness server 110. An entity that subsequently receives the digitally signed token may request the corresponding public key from the third-party integrity system and then use that key to verify the signature and included data.

[0059] MAC generator 208 generates message authentication codes (MACs) for different data sets (as further described below). Figure 3 Detailed description). In some embodiments, the MAC generator 208 uses a MAC algorithm (which is a type of cryptographic pseudo-random function) to generate a hash-based message authentication code (HMAC), also known as a keyed hash message authentication code. In such embodiments, the MAC generator 208 generates HMACs for different sets of data / parameters (e.g., using the HMAC SHA256 algorithm). In some embodiments, instead of using HMAC or another MAC algorithm, the MAC generator 208 uses another appropriate cryptographic pseudo-random function (PRF) that uses parameters that are otherwise used by the MAC generator 208 in generating various digital digests, as described throughout this specification. For ease of reference, in the remainder of this specification, the MAC generator 208 is described as generating a MAC or HMAC; however, it should be understood that the same functions / calculations described throughout this specification may alternatively be performed using another appropriate cryptographic PRF.

[0060] The MAC generator 208 generates an HMAC for a particular data set using the operating system 118's secret cryptographic key (which is stored in a secure location within the client device). Figure 2 The system-generated MAC / HMAC.

[0061] The client device 102 also includes a device trustworthiness client 210. In some embodiments, the device trustworthiness client 210 is invoked by the operating system 204 and collects signals from the environment of the client device 102 alone or in cooperation with the operating system 204. Examples of signals collected by the device trustworthiness client 110 include, but are not limited to, the type of device, the model of the device, evidence of whether the device has been granted the highest privileges and / or cracked, the operating system running on the device, the time when the device was last updated, etc. Alternatively, instead of the device trustworthiness client 210, the operating system 204 may obtain device trustworthiness data separately. These signals, collectively referred to as device trustworthiness data, may be used by the device trustworthiness server 110 to determine the trustworthiness of the client device 102 (as described below with reference to Figure 3 further described).

[0062] In some implementations, the client device 102 (e.g., via application A 202) generates a request 212 to verify the trustworthiness of the client device 102. The request may include (1) device trustworthiness data—obtained by the device trustworthiness client 210, the operating system 204, or both—from which the trustworthiness of the client device is determined and (2) a digital digest of the encrypted attestation token and the request timestamp, also referred to herein as the "third MAC."

[0063] In some implementations, this digital digest of the encrypted proof token and request timestamp is generated using a MAC generator 208 operating alone or in conjunction with an operating system 204, as described in the following operations.

[0064] First, the MAC generator 208 generates a secret key by generating an HMAC using the current date and a data string (e.g., a phrase such as "encrypted"), and then generating another HMAC using the HMAC of the current date and data string and a unique identifier of the client device 102 (e.g., the public key of the device). This operation can be represented using the following formula:

[0065] HMAC(DeviceID, HMAC(current_date, "encrypted")

[0066] Alternatively, the above calculation can be modified to exchange any of the parameters of the calculation (DeviceID, current_date, "encrypted") to generate a secret key. For example, the MAC generator 208 can generate a secret key by generating an HMAC using the DeviceID and a data string (e.g., a phrase such as "encrypted"), and then generating another HMAC using the HMAC of the DeviceID and data string and the current_date. As another example, the MAC generator 208 can generate a secret key by generating an HMAC using the DeviceID and current_date, and then generating another HMAC using the HMAC of the DeviceID and current_date and the data string ("encrypted").

[0067] Alternatively, instead of the above calculation, MAC generator 208 may generate the secret key by calculating MAC as follows: MAC(device||current_date||"encrypted"). In this example calculation, || may be any reversible method for composing a complex message from a simple message, such as protocol buffers, Concise Binary Object Representation (CBOR).

[0068] As another alternative, any other cryptographic pseudo-random function (other than MAC / HMAC) using three parameters may be used to generate data item (5) in the data set included in request 216.

[0069] By using the current date in generating the HMAC (and therefore the resulting secret key), the secret key is made temporary. In other words, the secret key can only be used to decrypt the attestation token on the current date (as described further below).

[0070] Second, MAC generator 208 (or, in general, operating system 204) uses a symmetric probabilistic encryption algorithm to encrypt the attestation token using the generated secret key.

[0071] Third, MAC generator 208 generates an HMAC using the encrypted proof token and the timestamp of creating the proof token to obtain, for example, a digital digest of the encrypted proof token and the request timestamp specifying when the proof token was created (also referred to as a third MAC). This operation can be represented using the following formula:

[0072] HMAC(encrypted_attestation_token, request_timestamp)

[0073] As described above, the digital digest of the encrypted proof token and the request timestamp is an HMAC of the following two parameters: the encrypted proof token and the request_timestamp. In some embodiments, instead of generating this digital digest / third MAC, the encrypted proof token can be included in the request 212 separately. For the rest of this description, it will be assumed that the digital digest of the encrypted proof token and the request timestamp is included in the request 212. However, it should be understood that if the encrypted proof token is included in the request 212, then the following disclosure also applies.

[0074] Because of the use of the HMAC algorithm or another PRF algorithm (on the encrypted proof token and request timestamp), the device trustworthy server 110 does not receive the encrypted proof token, nor can the device trustworthy server 110 infer the proof token from the HMAC (or other PRF) on the encrypted proof token and request timestamp. Therefore, the device trustworthy server 110 cannot know the nature of the client device 102's request to control user information (e.g., whether the device is requesting to delete / modify all user information) or the scope of the request (e.g., whether the request is to be performed by a specific content platform(s) / server(s) 106 or by a large number of such servers / platforms 106).

[0075] return Figure 2, the client device 102 sends a request 212 to the device trustworthiness server 110. After receiving the request 212, the device trustworthiness server 110 uses the device trustworthiness data included in the request 212 to determine whether the device is trustworthy. If the device trustworthiness server 110 determines that the client device 102 is trustworthy, the device trustworthiness server 110 digitally signs the digital digest of the encrypted proof token and the request timestamp with its private key. On the other hand, if the device trustworthiness server 110 determines that the client device 102 is not trustworthy, the device trustworthiness server does not digitally sign the digital digest of the encrypted proof token and the request timestamp.

[0076] In some cases, instead of indicating trustworthiness by digitally signing the digital digest of the encrypted proof token and the request timestamp (or in addition to indicating trustworthiness by digitally signing the digital digest of the encrypted proof token and the request timestamp), the device trustworthiness server 110 may use a flag (e.g., a one-bit flag where 0 indicates untrustworthy and 1 indicates trustworthy) or other data (e.g., a data message where "TRUST" indicates that the device is trustworthy and "DON'TTRUST" indicates that the device is untrustworthy) to indicate the trustworthiness of the device. For the remainder of this description, it will be assumed that the device trustworthiness server 110 indicates the trustworthiness of the device by digitally signing the digital digest of the encrypted proof token and the request timestamp.

[0077] The device trustworthiness server 110 sends a response 214 to the client device 102. The response includes a digital signature on the digital digest of the encrypted proof token and the request timestamp (if the device trustworthiness server 110 determines that the client device 102 is trustworthy) or an errored / empty response (if the device trustworthiness server 110 determines that the client device 102 is not trustworthy or the device trustworthiness server 110 determines that the trustworthiness of the client device 102 cannot be verified).

[0078] After receiving the response 214 from the device trustworthiness server 210, the client device 102 sends a request 216 to the relay server 108 requesting control over the user information stored at the plurality of content platforms / servers 106. In some implementations, when the client device 102 (e.g., the operating system 204) sends the request 216 to the relay server 108, the request 216 includes a data set. The data set may include one or more of the following data items: (1) a third MAC / digital digest of the digital signature of the encrypted proof token (or other digital token) and the request timestamp; (2) the encrypted proof token (or other digital token); (3) a timestamp indicating when the proof token (or other digital token) was created; (4) the requested scope, as specified in the payload of the proof token (and as described above); or (5) an HMAC (or another appropriate PRF) of a unique identifier of the device (e.g., the public key of the device) and another HMAC, where the other HMAC is for the current date and a data string (e.g., a phrase such as "challenge"). The HMAC in data item (5) may be represented using the following formula:

[0079] HMAC(DeviceId, HMAC(current_date, "challenge")

[0080] Alternatively, the above calculation can be modified to exchange any of the parameters of the calculation (DeviceID, current_date, "challenge") to generate the HMAC in data item 5. For example, MAC generator 208 can generate the HMAC by generating an HMAC using the DeviceID and the data string ("challenge"), and then generating another HMAC using the HMAC of the DeviceID and data string and the current_date. As another example, MAC generator 208 can generate the HMAC by generating an HMAC using the DeviceID and current_date, and then generating another HMAC using the HMAC of the DeviceID and current_date and the data string ("challenge").

[0081] Alternatively, instead of the above calculation, MAC generator 208 may generate the secret key by calculating MAC as follows: MAC(device||current_date||"challenge"). In this example calculation, || may be any reversible method for composing a complex message from a simple message, such as protocol buffers, Concise Binary Object Representation (CBOR).

[0082] As another alternative, any cryptographic pseudo-random function using three parameters may be used to generate data item (5) in the data set included in request 216.

[0083] After receiving the request 216 and the data set included therein, the relay server 108 determines whether the client device 102 is determined to be trustworthy by the device trustworthiness server 110. In some embodiments, the relay server 108 uses the public key of the device trustworthiness server 110 to verify the digital signature created by the device trustworthiness server 110. If the digital signature is verified, then the relay server 108 determines that the client device is trustworthy. On the other hand, if the digital signature is not verified, then the relay server 108 determines that the client device 102 is not trustworthy. In some embodiments, the relay server 108 further verifies the freshness of the request as indicated by the request timestamp (e.g., requests received within a certain threshold time after the time indicated by the request timestamp are considered to be recent requests). In addition, the relay server verifies the request by recalculating the digital digest of the encrypted proof token and the request timestamp and matching the digital digest with the digital digest received in the request. A mismatch indicates that the request is invalid (which in turn can indicate that the client device is not trustworthy).

[0084] If the relay server 108 determines that the client device 102 is not trustworthy, or the request is invalid, then the relay server 108 does not send the request further to any of the content platforms / servers 106 with which it is communicating. Thus, to the extent that the client device 102 is a malicious or compromised device attempting to conduct an attack (e.g., a DoS attack) against the content platform(s) / server(s) with which the relay server 108 is communicating, the trustworthiness determination of the relay server 108 (and the device trustworthiness server 110) prevents such an attack. In some implementations, in addition to determining that no request is to be sent to the content platform(s) / server(s) 106, the relay server 108 may also send a message to the client device 102 indicating that the request 216 was not completed.

[0085] On the other hand, if the relay server 108 determines that the client device 102 is trustworthy, then the relay server 108 sends the request 218 to the content platform / server 106 specified in the scope of the request included in the request 216. For example, if the scope of the request included in the request 216 specifies only a selected number of domains corresponding to certain content platform(s) / server(s) 106, then the relay server 108 sends the request 218 to each of those content platform(s) / server(s) 106. On the other hand, if the scope of the request included in the request 218 does not specify a selected number of domains corresponding to certain content platform(s) / server(s) 106, then the relay server 108 infers that the request is global, and therefore sends the request 218 to the various content platform(s) / server(s) 106 with which the relay server 108 communicates.

[0086] In some implementations, request 218 may include a data set. The data set may include one or more of the following data items extracted from request 216 (i.e., the request from client device 102 to relay server 108): (1) a digitally signed digital digest of an encrypted proof token (or other digitally signed token) and a request timestamp; (2) an encrypted proof token (or other digital token); (3) a timestamp indicating when the proof token (or other digital token) was created; and (4) an HMAC of a unique identifier of the device (e.g., a public key of the device) and another HMAC, where the other HMAC is for the current date and a phrase (e.g., "challenge"). The HMAC operation of data item (4) may be represented using the following formula:

[0087] HMAC(DeviceID, HMAC(current_date, "challenge")

[0088] As described with reference to data item (5) in request 216, the above calculation may be calculated in an alternative manner or may be calculated using another cryptographic pseudo-random function other than HMAC.

[0089] Upon receiving the request 218, the content platform / server 106 may verify the digital signature of the device trustworthiness server 110 against the digital digest of the encrypted proof token and the request timestamp (in the same manner as described above with reference to the relay server 108 verifying the signature).

[0090] If the digital signature is not verified, the content platform / server 106 does not further process the request 218 and determines that the relay server 108 and / or the client device 102 has failed or is untrustworthy or compromised. In some embodiments, the content platform / server 106 further verifies the freshness of the request as indicated by the request timestamp. In addition, the content platform / server verifies the request in the same manner as described above with reference to the relay server 108 verifying the signature by recalculating the digital digest of the cryptographic proof token and the request timestamp and matching the digital digest with the digital digest received in the request. A mismatch indicates that the request is invalid.

[0091] On the other hand, if the digital signature and request are verified (e.g., based on the same verification and digital digest comparison described above), then the content platform / server 106 determines that the client device 102 is trustworthy. In this case, the content platform / server 106 determines whether the content platform / server 106 includes user information corresponding to a unique device identifier of the client device 102 (e.g., a public key of the device).

[0092] Note that in embodiments where the relay server 108 provides only the encrypted proof token and the digital digest of the request timestamp to the content platform / server 106, the content platform / server 106 does not have access to the device's unique identifier (e.g., the device's public key) that is included in the proof token (or another digital token). In such embodiments, the content platform / server 106 includes a storage device that stores a lookup table (or another appropriate data structure) that maintains a correlation between the device's unique identifier (DeviceID) and an HMAC value (or other digital digest value generated using another PRF) that is calculated for the device's unique identifier and another HMAC that is calculated for the current date and a data string phrase (such as a "challenge") (i.e., using the same parameters and based on the same calculations as described above with reference to request 218). In other words, the resulting HMAC calculation is similar to the HMAC calculation performed to obtain data item (4) in request 218 above:

[0093] HMAC(DeviceID, HMAC(current_date, "challenge")

[0094] As described above, the above calculation may be calculated in an alternative manner or may be calculated using another cryptographic pseudo-random function other than HMAC.

[0095] Because "current_date" is used as a parameter when calculating the HMAC value, the content platform / server 106 uses the current date of the day to update the calculated HMAC value in the lookup table 224 every day. Therefore, if the relay server 108 sends a calculated HMAC value calculated using a date other than the current date, the HMAC will not be found in the lookup table, and the content platform / server 106 will not perform any further processing on the received request 218.

[0096] In operation, the content platform / server 106 compares the HMAC value received in the data set included in the request 218 to the HMAC values ​​stored in the lookup table. If an exact match is not found, the content platform / server 106 determines that it cannot perform the request for control user information 218. For example, this scenario may occur if the content platform / server 106 does not include user information for a particular device identifier, if the relay server 108 sends an incorrect HMAC or sends an outdated HMAC using a date other than the current date (indicating, for example, that the relay server 108 has malfunctioned or has been compromised by a malicious entity), or if the client device 102 sends an outdated or incorrect HMAC (indicating, for example, that the client device 102 has malfunctioned or has been compromised by a malicious entity).

[0097] On the other hand, if an exact match is found based on a comparison between the HMAC value received in the data set included in the request 218 and the HMAC value stored in the lookup table 224, then the content platform / server 106 retrieves the corresponding device identifier from the DeviceID field of the lookup table 224. Using the retrieved device identifier, the content platform / server 106 generates a secret key in the same manner as the client device generated the secret key (as described above) prior to issuing the request 212. Specifically, the content platform / server 106 generates the secret key using the device identifier and an HMAC of the current date and the same data string (e.g., the phrase "encrypted") used to generate the secret key at the client device. The generation of the secret key by the content platform / server 106 can be represented using the following operation:

[0098] HMAC(DeviceID, HMAC(current_date, "encrypted")

[0099] As described above, the above calculation may be calculated in an alternative manner or may be calculated using another cryptographic pseudo-random function other than HMAC.

[0100] In this manner, the client device 102 and the content platform / server 106 do not need to exchange secret keys to be used in the encryption / decryption of the proof token. That is, as long as the client device 102 and the content platform / server 106 each use the same parameters (e.g., the current date, the same data string, and the DeviceID) and the same calculation / formula / function, the client device 102 and the content platform / server 106 can each calculate the same secret key. In addition, the secret key is temporary in that the secret key is only valid for the current date. The temporary secret key is also used for a single purpose. The single-purpose temporary secret key is unlikely to be used as an identifier corresponding to the client device and / or any data corresponding to the device. In other words, if the secret key is not generated on the current date, then the content platform / server 106 will not be able to decrypt the encrypted proof token on the current date. In this manner, the content platform / server 106 can ensure that the request 218 (and the encrypted proof token included therein) is new (current) and is not the subject of a replay attack whereby an outdated (but valid) encrypted proof token is provided to the content platform / server 106.

[0101] Using the generated secret key, the content platform / server 106 decrypts the encrypted proof token it received in the request 218 from the relay server 108. This results in a decrypted plaintext proof token.

[0102] The content platform / server 106 may further verify the proof token by verifying a digital signature included in the proof token. To verify the digital signature included in the proof token, the content platform / server 106 uses the device's public key to verify the digital signature that protects the content of the proof token (e.g., the device identifier, request timestamp, request scope, and device trustworthiness token (when available)) with the corresponding data items included in the proof token.

[0103] If the digital signature is invalid, then the content platform / provider 106 determines that the attestation token is invalid (which may further indicate that the relay server 108 and / or the client device 102 is malfunctioning or has been compromised). In this scenario, the content platform / server 106 ignores the request 218 and does not process it further. In some implementations, the content platform / server 106 sends a response to the relay server 108 stating that the request 218 was not fulfilled.

[0104] On the other hand, if the digital signature is valid, the content platform / provider 106 determines that the proof token is valid. In this scenario, the content platform / server 106 can perform further verification to verify that the content platform / server 106 is going to complete the request for control information. In order to perform this verification, the content platform / server 106 obtains the value of the requested scope included in the proof token (or other digital token). If the requested scope identifies a specific content platform / server 106, then the content platform / server 106 determines that it must perform the request for control information as specified in the proof token (or other digital token). Similarly, if the requested scope states that the request is global (i.e., it must be performed by the content platform / server 106 with which the relay server 108 communicates), then the specific content platform / server 106 determines that it must perform the request for control information as specified in the proof token (or other digital token). On the other hand, if the request does not identify a specific content platform / server 106 and is not global, then the content platform 106 determines that it does not need to not perform the requested action to control the user information corresponding to the client device 102.

[0105] If the content platform / server 106 determines that it must perform the request for control information, the content platform / server 106 obtains the type of action to be performed as specified in the payload of the proof token and performs the appropriate action on the user information corresponding to the client device 102 stored at the content platform 106.

[0106] For example, if the request specifies deleting all or part of the user information, then the content platform / server 106 deletes all or part of the user information. As another example, if the request specifies modifying the access of the client device 102 to the user information, then the content platform / server 106 adjusts the access settings of the user information and limits the access to only those entities specified in the request to the client device 102. As another example, if the request specifies blocking the user information from being sent to any entity other than the user of the client device 102, then the content platform / server 106 adjusts the access settings of the user information and includes specific control instructions and user information that blocks the content platform / server 106 from sending the user information to any entity other than the user.

[0107] After the content platform / server 106 performs the specified action (or after the content platform / server 106 determines that it does not need to fulfill the request), it provides a response 220 to the relay server 108 stating whether the request was fulfilled.

[0108] Upon receiving the response 220, the relay server 108 forwards the response 220 to the client device 102 as part of a response 222. In some implementations, the relay server 108 consolidates the responses 220 from the various content platforms / servers 106 and provides the consolidated response 222 to the client device 102. In some implementations, the relay server 108 sends each of the responses 220 from the various content platforms / servers 106 to the client device 102 as a separate response 222 on an ad hoc basis (i.e., as they are received).

[0109] Thus, in view of the above description, the client device 102 does not need to send separate requests for control user information to multiple content platforms / servers 106. Instead, the client device 102 can send a single request 216 to the relay server 108, which sends the request to various content platforms / servers 106. In this way, computing resources (e.g., battery, network bandwidth) that would otherwise be consumed by the client device 102 when generating and sending multiple such requests (which may be hundreds of thousands or millions) are saved. In addition, by verifying the trustworthiness of the device and verifying the request received at the relay server 108, the above-mentioned technology prevents attacks on the relay server (e.g., DoS attacks) from being propagated to the various content platforms / servers 106, or at least reduces the possibility thereof. And, as further described above, all communications to the relay server 108, the device trustworthiness server 110, and the content platform / server 106 shield the data included in these communications, thereby protecting the privacy of the device information included in these communications.

[0110] Figure 3 is a flow chart of an example process 300 for sending and processing requests for control user information from a client device 102 to multiple servers. The operation of the process 300 is described below as being performed by Figure 1 and Figure 2 The operations of process 300 are performed by components of the system described and depicted in the description. The operations of process 300 are described below for illustration purposes only. The operations of process 300 may be performed by any suitable device or system (e.g., any suitable data processing device). The operations of process 300 may also be implemented as instructions stored on a computer-readable medium that may be non-transitory. Execution of the instructions causes one or more data processing devices to perform the operations of process 300.

[0111] The client device 102 sends a request to verify the trustworthiness of the client device 102 to the device trustworthiness server 110 (at 305). In some embodiments (and as described in reference Figure 2), a request to verify the trustworthiness of a client device includes a first data set that includes: (1) device trustworthiness data from which the trustworthiness of the client device is determined; and (2) a third MAC generated using the encrypted digital token and a first data parameter, which first data parameter can be a timestamp indicating the time when the digital token was created (as described in the next paragraph): HMAC(encrypted_digital_token, request_timestamp).

[0112] In some implementations, the client device 102 generates an encrypted digital token (as described above in reference to Figure 2 First, the client device 102 generates a digital token. Figure 2 As described, the digital token may be a proof token that includes: (1) a device identifier of the client device; (2) a first data parameter, which may be a timestamp that specifies the time when the digital token was created; (3) instructions that specify the type of action to be taken with respect to user information stored at multiple servers (e.g., deleting the user information, blocking the transmission of the information, modifying who can access the information, requesting disclosure of collected user information, requesting export of collected user information, or other requests regarding user information); and (4) data that identifies multiple servers (e.g., domain-specific identifiers of multiple servers or global instructions to send requests to servers with which the relay server 108 communicates). In some embodiments (and as described above with reference to Figure 2 As described above), the proof token may also include a device trustworthiness token previously generated by a device trustworthiness server and provided to the client device 102.

[0113] Secondly, the client device 102 uses a symmetric encryption algorithm to encrypt the digital token using the encryption key to obtain an encrypted digital token. In some embodiments, the symmetric encryption algorithm is probabilistic. In some embodiments (and as described above with reference to Figure 2 As described above, the client device 102 generates an encryption key by: (1) calculating a first MAC using a current date and a first data string (e.g., the phrase "encrypted") and (2) generating a second MAC using a device identifier and the first MAC. The operation of generating a symmetric encryption key can be represented by the following formula:

[0114] HMAC(DeviceID, HMAC(current_date, "encrypted")

[0115] As above reference Figure 2As described, the above calculation may be calculated in an alternative manner or may be calculated using another cryptographic pseudo-random function other than HMAC.

[0116] Thus, in some implementations, the client device 102 sends a request to the device trustworthiness server 110 to verify the trustworthiness of the client device 102 , and the request includes the first data set as described above.

[0117] As above reference Figure 2 As described, the MAC generator 208 of the client device 102 generates message authentication codes (MACs) for different sets of data. In some embodiments, the MAC generator 208 uses a MAC algorithm (which is a cryptographic pseudo-random function) to generate a hash-based message authentication code (HMAC), which is also called a keyed hash message authentication code. In such embodiments, the MAC generator 208 generates HMACs for different sets of data / parameters (e.g., using the HMACSHA256 algorithm). In some embodiments, instead of using HMAC or another MAC algorithm, the MAC generator 208 uses another appropriate cryptographic pseudo-random function (PRF) that uses parameters that are additionally used by the MAC generator 208 in generating the various digital digests described below. For ease of reference, for Figure 3 The remainder of the description of the example process 300 will assume that the MAC generator 208 of the client device 102 generates a MAC or HMAC; however, it should be appreciated that the same functions / calculations described below may alternatively be performed using another suitable cryptographic PRF.

[0118] In determining whether the client device 102 is trustworthy, the device trustworthiness server 110 uses the device trustworthiness data included in the request to verify the trustworthiness of the device. The device trustworthiness server 110 sends data to the client device 102 indicating that the client device is trustworthy.

[0119] Data indicating that the client device is trustworthy is received by the client device 102 from the device trustworthiness server (at 310). In some embodiments (and as described above with reference to Figure 2As described above, the device trustworthiness server 110 indicates that the client device 102 is trustworthy by digitally signing a third MAC value generated by the device using the encrypted digital token and the first data parameter using the private key of the device trustworthiness server 110. Because the third MAC is digitally signed by the device trustworthiness server 110, the client device 102 cannot modify the response from the device trustworthiness server 110. In some cases, instead of indicating trustworthiness by digitally signing the third MAC, the device trustworthiness server 110 may use a flag (e.g., a one-bit flag where 0 indicates untrustworthy and 1 indicates trustworthy) or other data (e.g., a data message where “TRUST” indicates that the device is trustworthy and “DON'T TRUST” indicates that the device is untrustworthy) to indicate the trustworthiness of the device. For the remainder of process 300, it is assumed that the device trustworthiness server 110 indicates the trustworthiness of the device by digitally signing the third MAC.

[0120] In response to receiving the data indicating that the client device is trustworthy, the client device 102 sends a request to the relay server 108 to control the user information stored at the plurality of servers (at 315). The request to control the user information specifies an action to be performed by the server with respect to the user information. For example, the action to be performed by the server may include: (1) deleting the user information stored at the server; (2) requesting that the user information stored at the server not be sent or provided to any other entity; (3) enabling one or more entities to access the user information stored at the server; or (4) another appropriate action requested by the client device with respect to the user information stored at the server.

[0121] In some embodiments, the request for control of user information includes a second data set that includes: (1) data indicating that the client device is trustworthy (such as received from the device trustworthiness server 110 in operation 310); (2) an encrypted digital token previously generated by the client device 102; (3) a first data parameter included in the digital token; (4) data identifying multiple servers at which appropriate actions regarding the user information are to be performed; and (5) a fourth MAC generated using the device identifier, the second data parameter (e.g., the current date), and a third data parameter, which can be a data string (e.g., the phrase "challenge"). The fourth MAC can be represented using the following formula:

[0122] HMAC(DeviceID, HMAC(current_date, "challenge")

[0123] As above reference Figure 2As described, the above calculation may be calculated in an alternative manner or may be calculated using another cryptographic pseudo-random function other than HMAC.

[0124] As reference Figure 2 As described above, upon receiving the request from the client device 102, the relay server 108 verifies the request. In response to verifying the request from the client device 102, the relay server 108 sends a request for control user information to various servers (such as reference 104) specified in the request from the client device 102. Figure 2 described above).

[0125] As reference Figure 2 As described above, once a request is received from the relay server 108, the server verifies the request. If the server determines that the request is valid, the server performs the action specified in the request to control the user information stored at the server (such as reference Figure 2 On the other hand, if the server determines that the request is invalid, then the server does not perform the action specified in the request to control user information stored at the server (as described in reference to Figure 2 The server sends a response to the relay server 108, thereby specifying whether the server completed the request (as described in reference Figure 2 described above).

[0126] The client device 102 receives a response from each of the plurality of servers via the relay server (at 320). In some embodiments, and as described above with reference to Figure 2 As described above, once responses are received from the various servers, the relay server sends these responses to the client device 102. The client device 102 in turn receives these sent responses from the relay server 108 (as shown in FIG. Figure 2 described above).

[0127] Based on the responses received by the client device 102 at operation 320, the client device 102 determines that at least a subset of the plurality of servers including the user information has performed the action specified in the request to control the user information (at 325). In some implementations, the client device 102 processes the received responses to determine whether the corresponding server has completed the request. If the server responds that it has completed the request, the client device 102 determines that the server stores the user information and that the server has performed the action specified in the request to control the user information by the client device in operation 315.

[0128] Thus, in this manner, a request by client device 102 to control user information stored at multiple servers is generated and sent to, and processed and completed by, the multiple servers storing the information.

[0129] Figure 4 4 is a block diagram of an example computer system 400 that can be used to perform the above operations. System 400 includes a processor 410, a memory 420, a storage device 430, and an input / output device 440. Each of components 410, 420, 430, and 440 can be interconnected, for example, using a system bus 450. Processor 410 is capable of processing instructions for execution within system 400. In some embodiments, processor 410 is a single-threaded processor. In another embodiment, processor 410 is a multi-threaded processor. Processor 410 is capable of processing instructions stored in memory 420 or on storage device 430.

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

[0131] The storage device 430 can provide mass storage for the system 400. In some embodiments, the storage device 430 is a computer-readable medium. In various embodiments, the storage device 430 may include, for example, a hard disk device, an optical disk device, a storage device shared by multiple computing devices (e.g., a cloud storage device) over a network, or some other mass storage device.

[0132] The input / output device 440 provides input / output operations for the system 400. In some embodiments, the input / output device 440 may include one or more of a network interface device such as an Ethernet card, a serial communication device such as an RS-232 port, and / or a wireless interface device such as 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 a peripheral device 460 (e.g., 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 TV client device, etc.

[0133] Despite Figure 4 An 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 circuit systems 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.

[0134] The embodiments of the subject matter and operations described in this specification may be implemented in digital electronic circuit systems 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. The 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 (one or more) computer storage media for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or in addition, the program instructions may be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device for execution by a data processing device. The computer storage medium may be 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 of them or included therein. In addition, although a computer storage medium is not a propagation signal, a computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagation signal. The computer storage medium may also be one or more separate physical components or media (e.g., multiple CDs, disks or other storage devices) or included therein.

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

[0136] The term "data processing apparatus" covers all kinds of apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip, or a plurality of the foregoing or a combination thereof. The apparatus may include a dedicated logic circuit system, 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, such as code that constitutes 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 of them. The apparatus and the execution environment may implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0137] 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 need not, correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., files storing one or more modules, subroutines, or code portions). A computer program may be deployed to execute on a computer or multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0138] The processes and logic flows described in this specification can be 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 can also be performed by a special purpose logic circuit system, and the apparatus can also be implemented as a special purpose logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0139] For example, processors suitable for executing computer programs include both general-purpose and special-purpose microprocessors. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic 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, the computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or will also be operably coupled to receive data from one or more mass storage devices for storing data or to transfer data to one or more mass storage devices for storing data or both. However, the computer does not have to have such devices. In addition, the computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (such as a universal serial bus (USB) flash drive), to name just a few examples. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0140] To provide interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the 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, the computer may interact with the 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.

[0141] Embodiments of the subject matter described in this specification may 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 with 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 any combination of one or more such back-end components, middleware components, or front-end components. The components of the system may 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"), inter-networks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0142] A computing system may include a client and a server. The client and the server are typically remote from each other and typically interact through a communication network. The relationship of the client and the server is due to computer programs running on the respective computers and having a client-server relationship with each other. In some embodiments, the server sends 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 a user interacting with the client device). Data generated at the client device (e.g., a result of a user interaction) may be received at the server from the client device.

[0143] Although this specification contains many specific implementation details, these details should not be interpreted as limitations on any invention or the scope of what may be claimed, but rather as descriptions of features specific to a particular embodiment of a particular invention. Certain features described in the context of a separate embodiment in this specification may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. In addition, although features may be described above as working in certain combinations and even initially claimed as such, one or more features from the claimed combination may be deleted from the combination in some cases, and the claimed combination may involve a sub-combination or a change in the sub-combination.

[0144] 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 sequential order, or that all illustrated operations be performed, to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

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

Claims

1. A computer-implemented method comprising: generating, by a client device, a digital token, the digital token comprising (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying a time when the digital token was created, (3) instructions specifying a type of action with respect to user data stored at a plurality of servers, and (4) data identifying the plurality of servers; The client device encrypts the digital token to obtain an encrypted digital token; The client device sends a request to a device trustworthiness server to verify the trustworthiness of the client device, wherein the request includes the encrypted digital token; receiving, by the client device from a device trustworthiness server, data indicating that the client device is trustworthy; and The user data stored at the plurality of servers is controlled by the client device to the relay server.

2. The computer-implemented method of claim 1 , encrypting by the client device comprises using a symmetric encryption algorithm, and wherein encrypting the digital token to obtain the encrypted digital token comprises: generating an encryption key using a cryptographic pseudorandom function and based on data parameters including a current date, a first data string, and the device identifier; as well as The digital token is encrypted by the client device using the encryption key to obtain the encrypted digital token.

3. The computer-implemented method of claim 2, wherein generating the encryption key using the cryptographic pseudo-random function and based on data parameters including a current date, a first data string, and the device identifier comprises: The encryption key is generated by (1) calculating a first message authentication code (MAC) using the current date and the first data string and (2) generating a second MAC using the device identifier and the first MAC.

4. The computer-implemented method of claim 1 , wherein: The client device sending the request to the device trustworthiness server includes: sending a first request to verify the trustworthiness of the client device, wherein the request includes a first data set, the first data set including (1) device trustworthiness data based on which the trustworthiness of the client device is determined and (2) a third MAC generated using the encrypted digital token and the first data parameters; and Sending a second request for controlling user data, the second request includes a second data set, the second data set including (1) data indicating that the client device is trustworthy, (2) the encrypted digital token, (3) the first data parameter, (4) data identifying the multiple servers, and (5) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter. 5 . The computer-implemented method of claim 4 , wherein the second data parameter comprises a current date and the third data parameter comprises a second data string.

6. The computer-implemented method of claim 5, wherein: Receiving, by the client device from the device trustworthiness server, data indicating that the client device is trustworthy comprises: A digital signature of the device trustworthy server for the third MAC is received by the client device from the device trustworthy server.

7. The computer-implemented method of claim 1 , wherein the action to be performed by the relay server with respect to the user data comprises one of: Deleting the user data stored at the relay server; requesting that the user data stored at the relay server not be sent or provided to any other entity; enabling one or more entities to access the user data stored at the relay server; Request disclosure of collected user data; or Request export of collected user data.

8. The computer-implemented method of claim 1 , wherein: The relay server is a server that verifies a request to control the user data before sending the request to control the user data to each of the plurality of servers, and the request to control the user data specifies an action to be performed by the server on the user data.

9. A system comprising: one or more memory devices storing instructions; as well as One or more data processing apparatus configured to interact with the one or more memory devices and, when executing the instructions, perform operations including: generating, by a client device, a digital token, the digital token comprising (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying a time when the digital token was created, (3) instructions specifying a type of action with respect to user data stored at a plurality of servers, and (4) data identifying the plurality of servers; The client device encrypts the digital token to obtain an encrypted digital token; The client device sends a request to a device trustworthiness server to verify the trustworthiness of the client device, wherein the request includes the encrypted digital token; receiving, by the client device from a device trustworthiness server, data indicating that the client device is trustworthy; and The user data stored at the plurality of servers is controlled by the client device to the relay server.

10. The system according to claim 9, wherein: Encrypting by the client device includes using a symmetric encryption algorithm, and wherein encrypting the digital token to obtain the encrypted digital token includes: generating an encryption key using a cryptographic pseudo-random function and based on data parameters including a current date, a first data string, and the device identifier; and The digital token is encrypted by the client device using the encryption key to obtain the encrypted digital token.

11. The system of claim 10, wherein generating the encryption key using the cryptographic pseudo-random function and based on data parameters including a current date, a first data string, and the device identifier comprises: The encryption key is generated by (1) calculating a first message authentication code (MAC) using the current date and the first data string and (2) generating a second MAC using the device identifier and the first MAC.

12. The system according to claim 9, wherein: The client device sending the request to the device trustworthiness server includes: sending a first request to verify the trustworthiness of the client device, wherein the request includes a first data set, the first data set including (1) device trustworthiness data based on which the trustworthiness of the client device is determined and (2) a third MAC generated using the encrypted digital token and the first data parameters; and Sending a second request for controlling user data, the second request includes a second data set, the second data set including (1) data indicating that the client device is trustworthy, (2) the encrypted digital token, (3) the first data parameter, (4) data identifying the multiple servers, and (5) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter.

13. The system of claim 12, wherein the second data parameter comprises a current date and the third data parameter comprises a second data string.

14. The system according to claim 13, wherein: Receiving, by the client device from the device trustworthiness server, data indicating that the client device is trustworthy comprises: A digital signature of the device trustworthy server for the third MAC is received by the client device from the device trustworthy server.

15. The system of claim 9, wherein the action to be performed by the relay server with respect to the user data comprises one of the following: Deleting the user data stored at the relay server; requesting that the user data stored at the relay server not be sent or provided to any other entity; enabling one or more entities to access the user data stored at the relay server; Request disclosure of collected user data; or Request export of collected user data.

16. The system of claim 9, wherein: The relay server is a server that verifies a request to control the user data before sending the request to control the user data to each of the plurality of servers, and the request to control the user data specifies an action to be performed by the server on the user data.

17. A non-transitory computer-readable medium storing instructions that, when executed by one or more data processing devices, cause the one or more data processing devices to perform operations comprising: generating, by a client device, a digital token, the digital token comprising (1) a device identifier of the client device, (2) a first data parameter, wherein the first data parameter is a timestamp specifying a time when the digital token was created, (3) instructions specifying a type of action with respect to user data stored at a plurality of servers, and (4) data identifying the plurality of servers; The client device encrypts the digital token to obtain an encrypted digital token; The client device sends a request to a device trustworthiness server to verify the trustworthiness of the client device, wherein the request includes the encrypted digital token; receiving, by the client device from a device trustworthiness server, data indicating that the client device is trustworthy; and The user data stored at the plurality of servers is controlled by the client device to the relay server.

18. The non-transitory computer-readable medium of claim 17, wherein encrypting by the client device comprises using a symmetric encryption algorithm, and wherein encrypting the digital token to obtain the encrypted digital token comprises: generating an encryption key using a cryptographic pseudorandom function and based on data parameters including a current date, a first data string, and the device identifier; as well as The digital token is encrypted by the client device using the encryption key to obtain the encrypted digital token.

19. The non-transitory computer-readable medium of claim 18, wherein generating the encryption key using the cryptographic pseudo-random function and based on data parameters including a current date, a first data string, and the device identifier comprises: The encryption key is generated by (1) calculating a first message authentication code (MAC) using the current date and the first data string and (2) generating a second MAC using the device identifier and the first MAC.

20. The non-transitory computer readable medium of claim 19, wherein: The client device sending the request to the device trustworthiness server includes: sending a first request to verify the trustworthiness of the client device, wherein the request includes a first data set, the first data set including (1) device trustworthiness data based on which the trustworthiness of the client device is determined and (2) a third MAC generated using the encrypted digital token and the first data parameters; and Sending a second request for controlling user data, the second request includes a second data set, the second data set including (1) data indicating that the client device is trustworthy, (2) the encrypted digital token, (3) the first data parameter, (4) data identifying the multiple servers, and (5) a fourth MAC generated using the device identifier, the second data parameter, and the third data parameter.

Images