Privacy-Centered Data Security in the Cloud Environment

Abstract

Techniques for privacy-centric data security are disclosed. A request for allowing a first data processor to access private data associated with a user is received at a cloud data privacy service. The request includes a request for a first data access block for the private data and a data filter describing one or more access parameters. The cloud data privacy service generates the first data access block based on the private data and the data filter. The first data access block is transmitted from the cloud data privacy service to a user device, and the user device is configured to transmit the first data access block to the first data processor. The cloud data privacy service receives the request for the private data including the first data access block. The cloud data privacy service determines that the first data access block is valid and permits the first data processor to access the private data.

Description

Technical Field

[0001] The present invention relates to computer security, and more particularly to privacy - centric data security in a cloud environment.

Summary of the Invention

[0002] An embodiment includes a method. The method includes, at a cloud data privacy service, a first data processor receiving, from a user device, a request for permission to access private data associated with a user. The request includes a request for a first data access block for the private data and a data filter that describes one or more access parameters for the first data processor and the private data. The method further includes, at the cloud data privacy service, generating a first data access block based on the private data and the data filter. The method further includes transmitting the first data access block from the cloud data privacy service to the user device. The user device is configured to transmit the first data access block to the first data processor. The method further includes, at the cloud data privacy service, receiving a request for the private data from the first data processor, the request including the first data access block. The method includes, at the cloud data privacy service, determining that the first data access block received from the first data processor is valid and, in response, permitting the first data processor to have at least partial access to the private data.

[0003] The embodiment further includes a system. The system includes a processor and a memory storing a program, which, when executed on the processor, performs operations. The operations include receiving, at a cloud data privacy service, a request from a user device to allow a first data processor to access private data associated with the user. The request includes a request for a first data access block for the private data and a data filter describing the first data processor and one or more access parameters for the private data. The operations include generating, at the cloud data privacy service, the first data access block based on the private data and the data filter. The operations include transmitting the first data access block from the cloud data privacy service to the user device. The user device is configured to transmit the first data access block to the first data processor. The operations include receiving, at the cloud data privacy service, a request for private data from the first data processor, the request including the first data access block. The operations include determining, at the cloud data privacy service, that the first data access block received from the first data processor is valid and, in response, allowing the first data processor at least partial access to the private data.

[0004] The embodiment further includes a non - transitory computer program product, the computer program product includes a computer - readable storage medium having computer - readable program code embodied therein, the computer - readable program code is executed by one or more computer processors to perform operations. The operations include, in a cloud data privacy service, receiving, from a user device, a request for the first data processor to be permitted to access private data associated with the user. The request includes a request for a first data access block for the private data and a data filter that describes one or more access parameters for the first data processor and the private data. The operations include, in a cloud data privacy service, generating a first data access block based on the private data and the data filter. The operations include transmitting the first data access block from the cloud data privacy service to the user device. The user device is configured to transmit the first data access block to the first data processor. The operations include, in a cloud data privacy service, receiving a request for private data from the first data processor, the request including the first data access block. The operations include, in a cloud data privacy service, determining that the first data access block received from the first data processor is valid and, in response, permitting the first data processor to have at least partial access to the private data.

Brief Description of the Drawings

[0005]

Figure 1

Figure 2A

Figure 2B

Figure 2C

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 4C

Figure 5A

Figure 5B

Figure 5C

Figure 6A

Figure 6B

Figure 7

Figure 8A

Figure 8B

Figure 9

Figure 10

[0006] In a modern connected world, data privacy is becoming increasingly important. In embodiments, data privacy can be enhanced through a privacy-centric system where personal data is stored where the owner decides and access to the data is under the real-time control of the owner at any given time. To facilitate this, users can own a virtual data safe to manage their personal data and the scope of permitted access to that data. In embodiments, this can be a secure service within the cloud, operated by a trusted service provider and installed in a region selected by the user. Information exchange is mediated through this virtual data safe. Further, unlike a physical safe (which can be opened by a key or code and is either open or locked), a virtual data safe can unlock partial access to its contents.

[0007] In embodiments, access to read a user's private data is implemented by a secure access token. Each data requester (e.g., the user's healthcare provider, financial institution, social media service, etc.) is given a token that enables the requester to read user data. The user can further precisely manage which data each requester is permitted to access, for example, provide access to relevant portions of the user's medical data to the healthcare provider and provide access to relevant portions of the user's financial data to the financial provider. The user can revoke the token to cancel access to the requester. In embodiments, the requester can access the data (stored in the virtual data safe) via a web service or an appropriate API (e.g., a RESTful API). Further, the user may choose to be notified every time their data is accessed. The notification may be configured item-by-item based on the requester's token.

[0008] In an embodiment, a service provider seeking to store data about a user is required to store it in the user's virtual data safe. Trusted authorities can request access to data under the user's control. The user can be notified of access requests in real time (e.g., via push notification to her mobile or SMS) and can agree or deny. Furthermore, to avoid overwhelming the user with notifications, the user can decide how often, or upon what time or event, they will receive the next notification for a particular requestor or data element. Furthermore, if the user fails to respond in a timely manner to agree or deny access, temporary access rules may be applied to data elements for which the user provided prior consent for temporary access.

[0009] In embodiments, a user may further choose to grant broader access to anonymized data. This allows the user to participate in public surveys, but limit the disclosure of details within their private data. For example, specific information about individuals may be anonymized so that requesters receive only limited or aggregated results. In embodiments, the provider of the virtual data safe acts as a trusted party with whom the user has entered into a trust relationship based on a service agreement entered into by both parties.

[0010] For example, the user may choose to tag a particular data element with a type of use such as "temporary read only" where the requester of the data element can process the data temporarily but does not store it permanently, as opposed to "own / copy". The user's decision can be implemented by a privacy token obtained in real time from a trusted service provider. The user (holder of the privacy token) may transfer this token to a third party, who can then request and present the privacy token to the trusted service provider. The trusted service provider can release the requested data associated with the privacy token.

[0011] Furthermore, one privacy token may be used (with permission from the user) to generate a secondary privacy token, thereby allowing other entities to access the same or a subset of the user's private information. In embodiments, all parties involved support a policy associated with the data under the management of the data owner. All access, transactions, and interactions are logged on a virtual data safe.

[0012] FIG. 1 illustrates a system for privacy-centric data security in a cloud environment according to at least one embodiment. One or more user devices 100 are communicatively coupled to a cloud system 150. In embodiments, user devices 100 may include any suitable user device, including a laptop computer, a desktop computer, a smartphone, a tablet, etc. Cloud system 150 may be any suitable cloud system (e.g., a public cloud, a private cloud, a hybrid cloud, etc.). Cloud system 150 is described in more detail in connection with FIGS. 9 and 10. One or more disclosed embodiments describe a cloud-based system as an example, although any suitable system, including a non-cloud-based system, may be used.

[0013] User devices 100 may communicate with cloud system 150 using any suitable communication technology, including a Wi-Fi connection, a cellular connection, a wired connection, etc. In an embodiment, one or more of user devices 100 may communicate with cloud system 150 using a cellular connection via mobile gateway 120. Additionally, user devices 100 may communicate with cloud system 150 using any suitable communication network, including a local area network, a wide area network, the Internet, etc.

[0014] One or more data processors 180A-180N are further communicatively coupled to cloud system 150, and in one embodiment, to each other. As described further below, data processors 180A-180N may be systems that use private data associated with a user of user device 100. For example, data processors 180A-180N may include social networks, financial institutions, medical institutions, businesses, educational institutions, electronic games, etc. Data processors 180A-180N may communicate with cloud system 150 using any suitable communication technology, including Wi-Fi® connections, cellular connections, wired connections, etc. Furthermore, data processors 180A-180N may communicate with cloud system 150 using any suitable communication network, including a local area network, a wide area network, the Internet, etc.

[0015] In an embodiment, cloud system 150 includes cloud privacy service 162. As described further below in connection with subsequent figures, cloud privacy service 162 can facilitate privacy-centric data security by managing interactions between user device 100 and data processors 180A-180N. For example, in an embodiment, private data about a user of user device 100 may be maintained in a secure repository in cloud system 150, and cloud privacy service 162 can manage access to this data by data processors 180A-180N. As another example, private data about a user of a user device may be maintained on user device 100 or in another storage location maintained by the user (such as a storage location in the user's home or office), and cloud privacy service 162 can manage access to this data. This will be discussed in further detail in connection with Figures 2A-2C.

[0016] As further discussed below, according to one or more of the disclosed embodiments, a user can use the cloud privacy service 162 to permit one or more of the data processors 180A-180N to access his or her private data. This access may be temporary and may be limited (e.g., requiring notification to the user or consent by the user). The data processors 180A-180N do not maintain the user's private data beyond the permitted temporary use. Instead, the data remains at a repository managed by the user (e.g., the cloud 150 or the user device 100).

[0017] In embodiments, one or more of the data processors 180A-180N may communicate with each other. For example, data processor 180A may be a financial service provider that outsources some functions to data processor 180N. As another example, data processor 180A may be a healthcare provider and data processor 180N may be an insurer. These are merely examples and any suitable data processors may be used.

[0018] As further explained below, the user may enable data processor 180A to permit data processor 180N to access the user's private data (e.g., by generating a data access block as discussed below in connection with FIGS. 3A and 3B and FIGS. 6A and 6B). Data processor 180A may provide data processor 180N with access or limited access that includes any notification and consent requirements that are the same as those permitted to data processor 180A (e.g., the user may enable a healthcare provider to permit an insurer to access the user's resume information and credit card information, but not the user's medical records). This is explained in more detail below.

[0019] In one embodiment, the user device 100 and the data processors 180A - 180N may communicate with the cloud privacy service 162 using an appropriate application programming interface (API). For example, a RESTful API or any other suitable API may be used. Alternatively, the user device 100 or the data processors 180A - 180N or both may communicate with the cloud privacy service 162 using any other suitable means including, for example, web pages, network messages, email, SMS messaging, social network messages, etc. For example, a user who wishes to grant a healthcare provider access to his or her private data can send an email or SMS message to the cloud privacy service 162 authorizing it to send an email or SMS message to the healthcare provider granting access and providing a link to the data to enable authorized access to the data. In this way, a data processor (e.g., a healthcare provider) can access the data without specifically performing direct communication with the cloud privacy service 162.

[0020] Figures 2A - 2C show a user device, a cloud server, and a data processor in a system for privacy - centric data security in a cloud environment according to at least one embodiment. Figure 2A is a block diagram showing a user device 200 (e.g., one of the user devices 100 shown in FIG. 1). The user device 200 includes a processor 202, a memory 210, and a network component 220. The processor 202 generally reads and executes programming instructions stored in the memory 210. The processor 202 includes, by way of representation, a single central processing unit CPU, multiple CPUs, a single CPU having multiple processing cores, a graphics processing unit (GPU) having multiple execution paths, etc.

[0021] Network component 220 includes the components necessary for user device 200 to interface with cloud system 150, as discussed above in connection with Figure 1. For example, network component 220 may include wired, WiFi, or cellular network interface components and associated software for facilitating communications between user device 200 and cloud system 150.

[0022] Although memory 210 is shown as a single entity, memory 210 may include one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read-only memory (ROM), flash memory, or other types of volatile and / or non-volatile memory. Memory 210 generally includes program code for performing various functions associated with use of user device client 200. The program code is generally described as various functional "applications" or "modules" within memory 210, although alternative implementations may have different functions and / or combinations of functions.

[0023] Within memory 210, data owner services 212 facilitate privacy-centric data security, as discussed in subsequent figures. For example, in an embodiment, user device 200 includes data repository 214. Data repository 214 may store private data about the user of user device 200. Data owner services 212 may be used to interact with privacy services in a cloud system (e.g., cloud privacy service 162 shown in FIG. 1 and privacy service 262 shown in FIG. 2B) to ensure privacy-centric data security, as discussed in further detail in subsequent figures.

[0024] Figure 2B is a block diagram showing a server (e.g., a virtual machine or a physical server discussed below in connection with FIG. 9) within a cloud system 250 (e.g., the cloud system 150 shown in FIG. 1). The cloud system 250 includes a processor 252, a memory 260, and a network component 270. The processor 252 generally reads and executes programming instructions stored in the memory 260. The processor 252 is representative of and includes, for example, a single central processing unit (CPU), multiple CPUs, a single CPU having multiple processing cores, a graphics processing unit (GPU) having multiple execution paths, and the like.

[0025] As discussed above in connection with FIG. 1, the network component 270 includes the components necessary for the cloud system 250 to interface with a wireless communication network. For example, the network component 270 may include wired, WiFi (registered trademark), or cellular network interface components and associated software to facilitate communication between the user device 200, the cloud system 250, and the data processor 280 shown in FIG. 2C.

[0026] Although the memory 260 is shown as a single entity, the memory 260 may include one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read only memory (ROM), flash memory, or other types of volatile and / or non-volatile memory. The memory 260 generally includes program code for performing various functions related to the use of the cloud system 250. The program code is generally described as various functionality “applications” or “modules” within the memory 260, but in alternative implementations may have different functions or combinations of functions or both.

[0027] Within the memory 260, a cloud privacy service 262 (e.g., the cloud privacy service 162 shown in FIG. 1) facilitates privacy-centric data security as will be discussed in subsequent figures. For example, in an embodiment, the memory 260 includes a data repository 264. The data repository 264 may store private data about a user of the user device 200 (e.g., in place of or in addition to the data repository 214 as shown in FIG. 2A). The cloud privacy service 262 may be used to interact with the data owner service 212 shown in FIG. 2A and the data processor service 292 shown in FIG. 2C to ensure privacy-centric data security.

[0028] Further, in an embodiment, the cloud privacy service 262 may include a filter generation service 263. In an embodiment, the filter generation service 263 is used to generate user-defined filters for private data that may specify access parameters to the data (e.g., whether notification or consent is required and which data is accessible). This will be discussed in more detail below with respect to FIG. 5A. Further, the memory 260 may store one or more privacy filters 266 that are used to filter private data before providing the data to a data processor (e.g., the data processor 280 shown in FIG. 2C). The cloud privacy service 262, the data repository 264, and the privacy filters 266 will all be discussed in further detail in subsequent figures.

[0029] FIG. 2C is a block diagram showing a data processor 280 (e.g., one of the data processors 180A - 180N shown in FIG. 1). The data processor 280 includes a processor 282, a memory 290, and a network component 296. The processor 282 generally reads and executes programming instructions stored in the memory 290. The processor 282 is representative of and includes, for example, a single central processing unit (CPU), multiple CPUs, a single CPU having multiple processing cores, a graphics processing unit (GPU) having multiple execution paths, etc.

[0030] As discussed above with respect to FIG. 1, the network component 296 includes components necessary for the data processor 280 to interface with a wireless communication network. For example, the network component 296 may include wired, WiFi (registered trademark) or cellular network interface components and associated software to facilitate communication between the cloud system 250 and the data processor 280, and between the data processor 280 and other data processors.

[0031] Although the memory 290 is shown as a single entity, the memory 290 may include one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read only memory (ROM), flash memory, or other types of volatile and / or non - volatile memory. The memory 290 generally includes program code for performing various functions related to the use of the data processor 280. The program code is generally described as various "applications" or "modules" of functionality within the memory 290, but in alternative implementations may have different functions or combinations of functions or both.

[0032] Within memory 290, data processor service 292 facilitates privacy - centric data security, as will be discussed in subsequent figures. For example, in an embodiment, data processor service 292 can be used to interact with cloud privacy service 262 shown in FIG. 2B to ensure privacy - centric data security. This will be discussed in detail in subsequent figures.

[0033] FIGS. 3A - 3B are flow diagrams 300 showing data flows for privacy - centric data security in a cloud environment according to at least one embodiment. In block 302, a user uploads a filter to cloud privacy service 262 (e.g., using data owner service 212 shown in FIG. 2A). In an embodiment, the filter is used to manage the data processor's access to the user's private data. The filter may be generated by the user (e.g., a customer filter) or may be a standard filter (e.g., providing read - only access, read - and - write access, and requiring verification before access, etc.). Further, in an embodiment, the filter may be code (e.g., source code or compiled code) for execution by the cloud privacy service. The filter will be discussed in further detail in relation to FIGS. 5A - 5C below.

[0034] In block 304, the cloud privacy service 262 compiles the received filter (if necessary), and stores the filter (e.g., in the privacy filter repository 266 shown in FIG. 2B). For example, the user device 200 may upload source code for a filter that provides read access to the user's private data (or a specific subset of the user's private data) to the cloud privacy service. The cloud privacy service 262 compiles the received filter and may store the compiled filter in the privacy filter repository 266 for later execution. This will be discussed in more detail again with respect to FIGS. 5A-5C below.

[0035] In block 306, the user device 200 uploads private data to the cloud privacy service 262 (e.g., using the data owner service 212 shown in FIG. 2A). As described above in connection with FIGS. 2A and 2B, in one embodiment, the cloud system (e.g., the cloud system 250 shown in FIG. 2B) stores the user's private data (e.g., in the data repository 264 shown in FIG. 2B). In this embodiment, the user device 200 uploads private data to the cloud privacy service. In another embodiment, the user's private data is maintained elsewhere (e.g., on the user device 200) instead of or in addition to on the cloud system 250.

[0036] In block 308, the cloud privacy service 262 stores private data in a data repository (e.g., the data repository 264 shown in FIG. 2B). In block 310, the user device 200 initiates a session with a first data processor (e.g., the data processor 280A). For example, as described above, the data processor 280A may be a medical provider, a financial institution, or any other entity seeking access to the user's private data.

[0037] In block 312, the data processor 280A requests access to specific private data elements related to the user. In an embodiment, the data processor 280A is communicatively coupled to the user device 200 directly via a cloud service (e.g., the cloud service 150 shown in FIG. 1) or via another communication path. The data processor 280A sends a data access request to the user device (e.g., via the cloud system 250 using the cloud privacy service 262).

[0038] In block 314, the user device 200 requests from the cloud privacy service 262 the requested data and a first data access block related to the requester entity. The data access block will be described in more detail with respect to FIGS. 6A and 6B. In an embodiment, the data access block describes what data the requester can access and how the requester can access that data (e.g., always permit access, request permission from the user for each access, request permission daily, weekly, or monthly, etc.). The data access block may further describe how an alternative requester related to the initial requester can access the data. For example, the requester may be a healthcare provider, and the data access block may describe both who at the healthcare provider can access the information and which entities can receive information from the healthcare provider (e.g., what information may be provided to an insurer or to another healthcare provider). In an embodiment, the data access block provides fine-grained control of private data to the user. The data access block will be discussed in further detail in relation to FIGS. 6A and 6B.

[0039] Further, in block 314, in an embodiment, the user device 200 may specify an additional level of detail filtering for the data access block. In an embodiment, a privacy filter (e.g., a privacy filter uploaded to the cloud privacy service at block 302) specifies filtering based on data type. In block 314, the user device may specify additional filtering (e.g., in addition to existing filters) for the specific data requested by the data processor 280A. FIGS. 8A and 8B discuss a user interface for facilitating block 314.

[0040] In block 316, the cloud privacy service generates a data access block and stores the data access block in a data access block registry (e.g., as part of the data repository 264 shown in FIG. 2B). The data access block is described in further detail in connection with FIGS. 6A and 6B.

[0041] In block 318, the cloud privacy service 262 sends a data access block for the requested private data to the user device 200. This is discussed further in connection with FIGS. 6A and 6B below. Alternatively, or in addition, the cloud privacy service 262 may notify the user device 200 of the location of the appropriate data access block (e.g., if the data access block was previously generated and maintained at the user device or elsewhere). For example, the cloud privacy service 262 may notify the user device 200 of an identifier associated with a data access block stored locally on the user device, or a location accessible to the user device.

[0042] In block 320, the user device 200 sends an address for the cloud privacy service 262, along with the data access block, to the data processor 280A (e.g., the first data requester). For example, the user device 200 may send a uniform resource locator (URL) that identifies the cloud privacy service 262 to the data processor 280. The data processor 280A can then access the cloud privacy service 262 using the URL. The URL is merely an example, and any appropriate address or identifier may be used. Further, the user device 200 sends a data access block that describes the permitted access to the data processor 280A to the data processor 280A. The data access block is discussed in further detail in connection with FIGS. 6A and 6B.

[0043] In block 322, data processor 280A transmits a data access block (e.g., received from user device 200) to cloud privacy service 262 to read out desired data. In an embodiment, data processor 280A is permitted to access the data (e.g., as described in the data access block), and in block 330, cloud privacy service 262 transmits the data to data processor 280A.

[0044] Alternatively, or in addition, the user can specify that she must receive a notification, or provide consent, or both, before the data processor 280 is permitted to access the requested data. This may be defined by the user, for example, using appropriate filters, and the requirements may be specified in the data access block. As discussed below, the user can define different controls (e.g., notification required, consent required, or neither) for different data processors (e.g., consent is required for one merchant to access the user's credit card information but not for another), and different controls for different data (e.g., consent is required to access medical information but not the user's email address). In block 324, in this scenario, the cloud privacy service 262 notifies the user device 200 of the data access and requests consent as needed. In block 326, the cloud privacy service generates (e.g., indicates the request) a subsequent requester access block and stores the access block in a registry (e.g., the data repository 264 shown in FIG. 2B). In block 328, the user approves, consents to, or rejects the data access request as needed, depending on the data access requirements and the user's preferences. FIGS. 8A and 8B illustrate a user interface for enabling the user to approve, consent to, or reject a data access block. Assuming the user does not reject the request, the flow proceeds to block 330 and the cloud privacy service sends the data and the subsequent access block to the data processor 280A.

[0045] In an embodiment, multiple data processors (e.g., general and specialist practitioners, medical facilities and insurers, financial and credit institutions, or any other suitable data processor) may seek access to the private data. In block 332, data processor 280A sends the URL of cloud privacy service 262 and the subsequent access block to a second data processor 280B.

[0046] In block 334, the second data processor 280B sends a request for the desired data along with the subsequent access block to the cloud privacy service 262. In an embodiment, the user has granted access to the second data processor 280B as well as the first data processor 280A. In this embodiment, flow proceeds to block 342, where the cloud privacy service 262 sends the data to the second data processor 280B.

[0047] Alternatively, or in addition, the user may specify that he or she should receive notice and / or provide consent before the second data processor 280B is permitted to access the requested data. This can be defined by the user, for example, using appropriate filters, and the requirements may be specified in the data access block. In block 336, in this scenario, the cloud privacy service 262 notifies the user device 200 about the data access and requests consent as necessary. In block 338, the cloud privacy service generates the next subsequent requester access block (e.g., indicating the request) and stores the access block in a registry (e.g., the data repository 264 shown in FIG. 2B). In block 340, the user approves, consents to, or rejects the data access request as necessary, depending on the data access requirements and the user's preferences. FIGS. 8A and 8B illustrate a user interface that enables the user to approve, consent to, or reject the data access block. Assuming the user does not reject the request, the flow proceeds to block 342, and the cloud data privacy service sends the data and the subsequent access block to the data processor 280B.

[0048] In embodiments, the cloud privacy service 262 may further request that the data processor 280A, 280B delete the user's private data after a user-specified duration. As noted above, the private data may be automatically deleted by the data processor 280A, 280B (e.g., the data processor must agree to delete the data as needed before access to the private data is permitted), or this may be enforced by providing the data processor with a version of the data that expires (e.g., self-enforcing) after a specified period of time, and by the cloud privacy service 262 sending the data processor a request to delete the data.

[0049] 4A-4C illustrate data structures for privacy-centric data security in a cloud environment according to at least one embodiment. FIG. 4A illustrates a hierarchical view of private user data 402-438, along with the cumulative keys associated with the data, according to at least one embodiment. In an embodiment, the private user data is stored in a hierarchical relationship (e.g., in data repository 264 in cloud system 250 shown in FIG. 2B or in data repository 214 in user device 200 shown in FIG. 2A). For example, a user's name is stored in field 402. The user's social security number is stored in field 404, which is a child of name field 402. The user's email address 406 is stored in field 406, which is a sibling of social security number field 404 and is also a child of name field 402. The user's home address is stored in field 414, which is a child of email address field 406.

[0050] Additionally, in embodiments, certain private information fields may be accessed using keys. These keys may be provided to a data processor (e.g., data processor 280 shown in FIG. 2C), which may present the keys to a service providing data access (e.g., cloud privacy service 262 shown in FIGS. 2B and 3). If the key is valid, the service provides the data. In embodiments, each key is signed (e.g., using public / private key encryption or other suitable digital signature) or otherwise secured to verify that it is valid.

[0051] Additionally, different data processors may be provided with different signatures, which may be used to track who is attempting to access the data. For example, as shown in FIG. 3, data processor 280A may be provided with a key with a different signature than the signature provided to data processor 280B, and cloud privacy service 262 may use these different signatures to track which data processor is attempting to access a given data field. For example, cloud privacy service 262 may log access to the data using a given signature.

[0052] Furthermore, in one embodiment, the keys may be hierarchical and may be constructed with each other. For example, shorter keys may enable access to higher-level data, while longer keys may enable access to more specific information. As shown in FIG. 4A, the key "A1" provides access to the name field 402. The key "B2A1" (e.g., the key of the name field with the addition of "B2") provides access to the email address field 406. The key "C1B2A1" provides access to the home address field 414. Similarly, the key "B3A1" provides access to the user's birthday. However, longer keys are necessary for access to more specific (e.g., more private) information. The key "C2B3A1" is required to access the health report field 416, the key "D2C2B3A1" is required to access the general health data field 424, and the key "E2D2C2B3A1" is required to access the allergy data.

[0053] Furthermore, as discussed above and shown in FIG. 4A, longer keys have shorter keys that permit access to more general data inside them. Thus, one data processor permitted access to a particular data field (e.g., a healthcare provider having access to the general health data field 424 using the key "D2C2B3A1") may provide the shorter key to other entities, enabling access to more general data rather than specific data (e.g., providing the key "B3A1" to permit access to the birthday field 408 to an insurer, but not providing it to the general health data field 424). Hierarchical data and hierarchical keys are merely exemplary embodiments as discussed above. Private data may be stored in any other suitable (e.g., non-hierarchical) manner.

[0054] Figures 4B and 4C show the storage of private data in table 450 according to at least one embodiment. For example, table 450 shown in FIGS. 4B and 4C may be a database table (e.g., within a relational database or any other suitable database) that stores the private data shown in FIG. 4A (e.g., in data repository 264 as shown in FIG. 2B, or data repository 214 as shown in FIG. 2A). The item index column 462 provides an index to the data (e.g., to enable the database to identify the data). The item label column 464 describes the data.

[0055] The item key column 466 provides a key that the data processor uses to access the data. In an embodiment, the key may be hierarchical as described above in connection with FIG. 4A. The value column 468 provides the data itself. The default filter column 470 provides a default filter level for access to the data. For example, the default filter for name data may allow "read always" (which by default permits access without special consent to the data processor), while the default filter for general health data requires "approve by me" and requires the user to consent (e.g., by default) to any access to this data. In an embodiment, the default filter level may be encoded (e.g., using a fixed integer representing the level of filtering) instead of using a human-readable language. In an embodiment, as discussed below with respect to FIGS. 5A-5C, specific filters may be provided by the user.

[0056] Figures 5A - 5C illustrate a privacy filter (e.g., a data shaping filter) for privacy - centric data security in a cloud environment according to at least one embodiment. Figure 5A shows generating, storing, and using a privacy filter for privacy - centric data security in a cloud environment according to at least one embodiment. At block 502, a user (e.g., data owner 500) selects a desired filter level. In an embodiment, the user compiles filter conditions using instructions and requirements for accessing his private data. For example, the user may say, "Approved by me and read once by <dentist> <dentist>)" and be valid until August 2019. A user interface for providing this is described in connection with Figures 8A and 8B below.

[0057] In block 504, a filter generation service (e.g., filter generation service 263 shown in FIG. 2B) generates a filter. In an embodiment, the filter generation receives and parses the filter conditions (e.g., from block 502). The filter generation service then tokenizes the filter using a privacy filter language dictionary 506.

[0058] For example, a privacy filter language dictionary may specify the following: Filterterm := Action [Denominator [ <parameter>]] [ | Condition Filterterm]

[0059] The Action may be any suitable action, including "approve," "create," "read," "update," "delete," "forward," "validate," or "default." The Denominator may be any suitable common property, including "by," "to," "once," "twice," "never," "always," "until," or "only." The Condition may be any suitable condition, including "and," "or," or "and not."

[0060] The filter generation service may then parse the token, generate appropriate program code, (if necessary) compile the code into machine-executable code, and store the filter (e.g., the compiled filter) in filter repository 566. Figure 5B shows an example of a suitable filter that includes human-readable program code.

[0061] In block 512, a data processor (e.g., data processor 280 shown in FIG. 2C) requests private data. In an embodiment, the data processor sends a request to a cloud privacy service and provides a valid data access block. This is described in more detail above in connection with FIG. 3.

[0062] At block 514, a privacy service (e.g., the cloud privacy service 262 shown in FIG. 2B) processes the request. For example, the privacy service may receive a data access block from the data processor (e.g., sent at block 512). The privacy service can access the data access block registry 564B (e.g., the data access block registry included as part of the data repository 264 shown in FIG. 2B) and use the registry to verify the data access block. For example, the privacy service can determine whether a matching data access block is included in the data access block registry 564B. In embodiments, the data access block is appropriately protected (e.g., signed, encrypted, etc.) to ensure that it is valid.

[0063] Assuming the data access block is valid, the privacy service may access the requested data from the private data repository 564A (e.g., part of the data repository 264 shown in FIG. 2B). Additionally, the privacy service may search for default filters for data from the private data repository 564A (e.g., the detailed filter column 470 shown in FIG. 4B).

[0064] The privacy service may then retrieve from filter repository 566 any filter program modules that correspond to the requested data and execute the filter program modules, which causes the privacy service to contact data owner 500 (e.g., the user of user device 200 shown in FIG. 2A), provide notification of the request from the data processor, and receive approval, consent, or denial of the request (as appropriate, depending on the filter) from data owner 500. In an embodiment, as discussed in connection with FIG. 3, the privacy service may then generate the next data access block, update data access block registry 564B, and transmit the data to the requesting data processor.

[0065] 5B and 5C illustrate example privacy filters for privacy-centric data security in a cloud environment according to at least one embodiment. For example, table 550 shown in FIGS. 5B and 5C may be a database table (e.g., in a relational database or any other suitable database) that stores filters (e.g., in filter repository 566, as shown in FIG. 5A). Filter identifier column 552 provides an index of the data (e.g., to allow the database to identify the data). Filter condition column 554 identifies a short term for the filter (e.g., a user-friendly term for use in a user interface, as described below with respect to FIGS. 8A and 8B). Program module column 556 indicates the human-readable program code that implements the filter for a given row. This is merely an example, and other suitable program code may be used.

[0066] Figures 6A and 6B illustrate a data access block structure for privacy - centric data security in a cloud environment according to at least one embodiment. FIG. 6A shows an exemplary structure 600 for a data access block according to at least one embodiment (e.g., as described above). In an embodiment, a data access block is used to track and enforce which data is permitted access to a particular data processor and for what period of time. For example, the data access block may restrict access by data type (e.g., item - by - item) or by duration (e.g., enabling access for a specified time). The type column 602 indicates the type of the fields within the data access block, and the content column 604 indicates the content of the corresponding fields in that row.

[0067] For example, a data access block may be composed of a signature and a subsequent series of blocks. Each block may be composed of a date, one or more series of items, and one or more series of filters. The date may be a timestamp indicating the generation of the block. An item may be an identifier for a secret data item within a data repository. For example, the item may be a value within the item index column 462 shown in FIG. 4B corresponding to a data field. A filter may be a filter condition (e.g., as shown in column 554 in FIG. 5B) or an identifier for a filter within a filter repository (e.g., as shown in column 552 in FIG. 5B). The signature may be a signature over the list of blocks. In an embodiment, as described above, the signature is generated by a privacy service (e.g., the cloud privacy service 262 shown in FIG. 2B) using the owner - specific secret key (e.g., using public - key cryptography).

[0068] FIG. 6B illustrates an exemplary data access block registry 650 (e.g., data access block registry 564B shown in FIG. 5A) according to at least one embodiment. Unique identifier column 652 provides a unique identifier for each data access block. Requestor column 654 provides an identifier for the data processor that requested the data that led to the creation of the data access block. Data access block column 656 provides the data access block (e.g., as shown in FIG. 6A). Block usage column 658 provides a log of data access block usage. For example, block usage column 658 can track each usage of data access block column 656 by requestor column 654.

[0069] In embodiments, the logs may be used to provide reports to users to identify errors or unauthorized data access, or for other suitable purposes. For example, in one embodiment, a privacy service (e.g., cloud privacy service 262 shown in FIG. 2) may provide users with reports about which data processors have accessed their private data. This may be provided to users periodically (e.g., via email or physical mail) or may be accessible upon request on a web page, within a mobile application, or in other suitable locations.

[0070] 7 illustrates a technique for navigating a data access block structure in privacy-centric data security in a cloud environment, according to at least one embodiment. As shown, at block 702, a privacy service (e.g., cloud privacy service 262 shown in FIG. 2B) receives input parameters. At block 704, the privacy service uses these parameters to generate a subsequent data access block (e.g., as shown in blocks 326 and 338 of FIG. 3).

[0071] For example, the currentBlock input parameter (using, for example, the data access block structure shown in FIG. 6A), <signature> | <timestamp>It can be set as [[<item_index>|<filter_index>]]. This represents the previous data access block. The signKey input parameter can be the user's unique private key. The currentDate input parameter can be a timestamp representing the current date and time. The filter parameter may be a new filter for use (e.g., an index for a filter in a filter repository or a short name of the filter). The output may be a subsequent block generated based on these inputs using the human-readable code shown in block 704. This is just an example, and other appropriate techniques may be used.

[0072] Figures 8A and 8B show a user interface for privacy-centered data security in a cloud environment according to at least one embodiment. Figure 8A shows a user interface that enables a user to set privacy filter control specific to a data processor for privacy-centered data security in a cloud environment according to at least one embodiment. The user device 800 includes an interface 802 that enables a user to graphically set desired security parameters for various data processors. Using graphical icons, text, or any other appropriate visual or audio representation, the user can define how entities can access the user's private data.

[0073] For example, the user can specify that a dentist is allowed to read the user's dental records without notice but must receive consent before accessing the user's medical information, while allowing the dentist to access the user's resume information (e.g., name, address, phone number) without notice. As another example, the user can specify that an insurance company can access resume information and automotive information without notice but cannot access the user's medical information.

[0074] The user device 800 further includes an interface 804 that provides a notification of the access request to the user and enables the user to consent to or reject the request. For example, the illustrated embodiment shows that the entity "Hypermarket24 / 7" (e.g., a grocery store) requests access to the user's credit card information. The user may consent to or reject the request.

[0075] FIG. 8B shows a user interface that enables a user to set data-specific privacy filter controls for privacy-centered data security in a cloud environment according to at least one embodiment. For example, the user device 800 includes an interface 852 that shows the user's private data. The user may use graphical icons, text displays, voice indications, etc. to control the default access to this data. For example, the user may determine that, by default, the user's name and address can be accessed without notification or consent. The user may further determine that, by default, an entity must receive consent before accessing the user's credit card information. The user may further determine that, by default, no one can access the user's health records.

[0076] As described above, each of these defaults may be overridden by a specific privacy filter applied to a specific entity. For example, the user may create a filter (e.g., using the interface shown in FIG. 8A) that allows a healthcare provider to access medical data without consent, but requires the healthcare provider to seek consent before accessing credit card data.

[0077] 9 illustrates a cloud computing environment according to at least one embodiment. While this disclosure may include references to cloud computing, it should be understood that implementation of the teachings detailed herein is not limited to cloud computing environments. Rather, embodiments may be implemented in conjunction with any other type of computing environment now known or hereafter developed.

[0078] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0079] The characteristics are as follows:

[0080] On-Demand Self-Service: Cloud consumers can unilaterally provision computing power, such as server time and network storage, as needed automatically without the need for human interaction with the service provider.

[0081] Broadband Network Access: Capabilities are available over the network and accessed via standard mechanisms that facilitate use by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, PDAs).

[0082] Resource Pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where various physical and virtual resources are dynamically assigned and re-assigned according to demand. Consumers generally have a sense of location independence in that they do not manage or have knowledge of the exact location of the resources provided, but can specify location at a higher level of abstraction (e.g., country, state, or data center).

[0083] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, and in some cases automatically, to scale out rapidly and released quickly to scale in rapidly. To the consumer, the capabilities available for provisioning often appear to be unlimited externally and can be purchased in any quantity at any time.

[0084] Measured Service: The cloud system automatically controls and optimizes resource use by leveraging metering capabilities at an appropriate level of abstraction for the type of service (e.g., storage, processing, bandwidth, number of active users). Resource usage is monitored, controlled, and reported to provide transparency for both the provider and consumer of the utilized service.

[0085] The service model is as follows.

[0086] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the potential exception of limited user-specific application configuration settings.

[0087] Platform as a Service (PaaS): The ability offered to consumers is to deploy consumer-created or acquired applications, written using programming languages and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment.

[0088] Infrastructure as a Service (IaaS): The capability offered to the consumer is to provide processing, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating system, storage, deployed applications, and, in some cases, limited control over selected networking components (e.g., host firewalls).

[0089] The deployment model is as follows:

[0090] Private Cloud: Cloud infrastructure is used exclusively for one organization. It may be managed by the organization or a third party and may exist on-premise or off-premise.

[0091] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with common concerns (e.g., mission, security requirements, policy and compliance considerations). It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0092] Public Cloud: Cloud infrastructure is available to the general public or large industry organizations and is owned by organizations that sell cloud services.

[0093] Hybrid Cloud: A cloud infrastructure is a blend of two or more clouds (private, community, or public) that remain distinct entities but are joined by standardized or proprietary technologies that allow data and application portability (e.g., cloud bursting for load balancing between clouds).

[0094] Cloud computing environments are service-oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0095] Referring now to FIG. 9, an exemplary cloud computing environment 950 is shown. As shown, the cloud computing environment 950 includes one or more cloud computing nodes 910, with which local computing devices used by cloud consumers, such as, for example, a PDA or mobile phone 954A, a desktop computer 954B, a laptop computer 954C, or an automobile computer system 954N, or any combination thereof, may communicate. The nodes 910 may also communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, such as private, community, public, or hybrid clouds, as described above, or any combination thereof. This enables the cloud computing environment 950 to provide infrastructure, platform, or software, or any combination thereof, as a service, for which the cloud consumer does not need to maintain resources on their local computing device. The types of computing devices 954A-954N shown in FIG. 9 are for illustrative purposes only, and it will be understood that computing node 910 and cloud computing environment 950 can communicate with any type of computerized device via any type of network, a network-addressable connection (e.g., using a web browser), or both.

[0096] Referring now to Figure 10, a set of functional abstraction layers provided by cloud computing environment 950 (Figure 9) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 10 are for illustrative purposes only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0097] The hardware and software layer 1060 includes hardware and software components. Examples of hardware components include mainframes, servers based on RISC (Reduced Instruction Set Computer) architecture, servers, blade servers, storage devices, and networks and networking components. In some embodiments, examples of software components may include application server software and database software.

[0098] The virtualization layer 1062 provides an abstraction layer from which examples of virtualized entities such as virtualized servers, virtualized storage, virtualized networks including virtual private networks, virtualized applications and operating systems, and virtualized clients are provided.

[0099] In one example, the management layer 1064 may provide the following functions: Resource provisioning provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing provides tracking of costs for resources utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. A user portal provides consumers and system administrators with access to the cloud computing environment. Service level management provides allocation and management of cloud computing resources to meet required service levels. Service level agreement (SLA) planning and fulfillment provides pre-allocation and procurement of cloud computing resources in anticipation of future demands in accordance with SLAs.

[0100] The workload layer 1066 provides examples of the functionality utilized by a cloud computing environment. Examples of workloads and the functionality provided by this layer include mapping and navigation, software development and lifecycle management, virtual classroom education delivery, data analytics processing, transaction processing, and cloud privacy services. In one embodiment, some or all of the modules of the cloud system 250 may be implemented in the workload layer 1066. For example, the cloud privacy service 262, the filter generation service 263, the data repository 264, and the privacy filter repository 266 may be implemented within the workload layer 1066. In an embodiment, the cloud privacy service 262 may be executed on a computing system within the cloud (e.g., the workload layer 1066), and the data repository 264 and the privacy filter repository 266 may be stored on the cloud. By doing so, access to this information is made possible from any computing system connected to a network (e.g., the Internet) connected to the cloud.

[0101] The description of the various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or to limit the invention to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments of the present invention. The terms used herein have been chosen to explain the principles of the embodiments, the practical application to technologies found in the marketplace, or the technological improvement, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0102] The following refers to embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the specifically described embodiments. Instead, any combination of the following features and elements, whether or not related to various embodiments, is contemplated to implement and carry out the contemplated embodiments. Further, the embodiments disclosed herein can achieve other potential solutions or advantages over the prior art, but whether a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Thus, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims, except as explicitly recited in the claims. Similarly, references to "the invention" should not be construed as a generalization of the subject matter of the invention disclosed herein and should not be considered an element or limitation of the appended claims, except as explicitly recited in the claims.

[0103] Aspects of the invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may all generally be referred to herein as a "circuit," "module," or "system."

[0104] The invention may be a system, method, or computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium having thereon computer-readable program instructions for causing a processor to execute aspects of the invention.

[0105] A computer-readable storage medium may be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, punch cards, or mechanically encoded devices such as ridge structures in grooves with recorded instructions, and any suitable combination of the above. Computer-readable storage media, as used herein, is not to be construed as a transitory signal per se, such as an electric wave, a freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0106] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0107] Computer-readable program instructions for carrying out the operations of the present invention may be written in assembly instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, where the one or more programming languages include object-oriented languages such as Smalltalk®, C++, or the like, and conventional procedural languages such as the C programming language or similar programming languages. The computer-readable program instructions may be executed as a stand-alone software package, entirely on the user's computer, partly on the user's computer, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, an electrical circuit may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to customize the electrical circuit in order to carry out aspects of the present invention, and the electrical circuit may include, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA).

[0108] Aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0109] These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart illustration and / or block, or blocks, thereof. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart illustration and / or block, or blocks, thereof.

[0110] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart illustration and / or block, or blocks, thereof.

[0111] Flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram can represent a module, segment, or portion of instructions that include one or more executable instructions for implementing a particular logical function. In some alternative implementations, the functions recited in the blocks may occur out of the order shown in the drawings. For example, two blocks shown in succession may, in fact, be executed substantially simultaneously, or the blocks may be executed in the reverse order depending on the functionality involved. It should be noted that each block of a block diagram or flowchart diagram, or combinations of multiple blocks of a block diagram or flowchart diagram, or both, may be implemented by a special purpose hardware-based system that performs a particular function or action, or that implements a combination of special purpose hardware and computer instructions.

[0112] The foregoing is presented as an implementation of the present invention, and other embodiments and further embodiments of the present invention may be devised without departing from the basic scope thereof, which is defined by the following claims.< / timestamp> < / signature> < / parameter> < / dentist>

Claims

1. In a cloud data privacy service, receiving, from a user device, a request to permit a first data processor to access private data associated with a user, the request comprising: a request for a first data access block for the private data; and a data filter describing one or more access parameters for the first data processor and the private data generating, by the cloud data privacy service, the first data access block based on the private data and the data filter; transmitting, by the cloud data privacy service, the first data access block from the cloud data privacy service to the user device, the user device being configured to transmit the first data access block to the first data processor; receiving, by the cloud data privacy service, from the first data processor, a request for the private data, the request including the first data access block; generating, by the cloud data privacy service, a second data access block for a second data processor based on the received first data access block; permitting, by the cloud data privacy service, in response to determining that the received first data access block from the first data processor is valid, the first data processor to have at least partial access to the private data; transmitting, by the cloud data privacy service, the second data access block to the first data processor, the first data processor providing access to at least a portion of the private data to the second data processor by providing the second data access block to the second data processor A method comprising:

2. ​ The scope of the at least partial access to the private data permitted to the first data processor is based on the first data access block, the method according to claim 1.

3. In the cloud data privacy service, determining that the first data access block received from the first data processor is valid includes determining that the digital signature for the first data access block is valid , the method according to claim 1 or 2.

4. The user device is configured to send an address for the cloud data privacy service together with the first data access block to the first data processor, and the first data processor is configured to send the request for the private data to the cloud data privacy service based on the address, the method according to any one of claims 1 to 3.

5. The method includes in the cloud data privacy service, receiving a request from the second data processor to access at least a portion of the private data, the request including the second data access block; in the cloud data privacy service, in response to determining that the second data access block received from the second data processor is valid, permitting the second data processor to perform at least partial access to at least a portion of the private data , the method according to claim 1.

6. The second data access block reflects access to only a portion of the private data for the second data processor, the method according to claim 5.

7. The method further includes storing the first data access block in a data access block registry , the method according to any one of claims 1 to 6.

8. The method according to any one of claims 1 to 7, wherein the first data processor is permitted to access the private data for a limited period, and the first data processor is configured to remove the private data after the expiration of the limited period.

9. The method according to any one of claims 1 to 8, wherein the cloud data privacy service operates in a public cloud environment independent of the first data processor, and the private data is maintained in the public cloud environment.

10. A processor, a memory storing a program wherein the program, when executed on the processor, performs operations, and the operations are in a cloud data privacy service, receiving, from a user device, a request for the first data processor to be permitted to access private data associated with a user, the request including a request for a first data access block for the private data, and a data filter describing one or more access parameters for the first data processor and the private data receiving; in the cloud data privacy service, generating the first data access block based on the private data and the data filter; transmitting the first data access block from the cloud data privacy service to the user device, the user device being configured to transmit the first data access block to the first data processor; in the cloud data privacy service, receiving a request for the private data from the first data processor, the request including the first data access block; in the cloud data privacy service, generating a second data access block related to a second data processor based on the received first data access block. In response to determining that the first data access block received from the first data processor is valid in the cloud data privacy service, permitting the first data processor to access the private data at least in part; In the cloud data privacy service, transmitting the second data access block to the first data processor, wherein the first data processor provides the second data access block to the second data processor to provide the second data processor with access to at least a portion of the private data; A system comprising. **Claim 11** The system according to claim 10, wherein the scope of the at least partial access to the private data permitted to the first data processor is based on the first data access block. **Claim 12** The operation is In the cloud data privacy service, receiving from the second data processor a request to access at least a portion of the private data, the request including the second data access block; In response to determining that the second data access block received from the second data processor is valid in the cloud data privacy service, permitting the second data processor to access at least a portion of the private data at least in part; The system according to claim 10, comprising. **Claim 13** A computer program, comprising instructions for causing one or more computer processors to In a cloud data privacy service, receive from a user device a request for the first data processor to be permitted to access private data associated with a user, the request including A request for a first data access block for the private data, and A data filter describing one or more access parameters for the first data processor and the private data Receiving, including. In the cloud data privacy service, generating the first data access block based on the private data and the data filter; Transmitting the first data access block from the cloud data privacy service to the user device, wherein the user device is configured to transmit the first data access block to the first data processor; In the cloud data privacy service, receiving a request for the private data from the first data processor, the request including the first data access block; In the cloud data privacy service, generating a second data access block related to a second data processor based on the received first data access block; In the cloud data privacy service, in response to determining that the first data access block received from the first data processor is valid, permitting the first data processor to have at least partial access to the private data; In the cloud data privacy service, transmitting the second data access block to the first data processor, wherein the first data processor provides the second data access block to the second data processor to provide the second data processor with at least partial access to the private data; A computer program for causing the above to be executed.

14. The computer program according to claim 13, wherein the scope of the at least partial access to the private data permitted to the first data processor is based on the first data access block.

15. On the one or more computer processors In the cloud data privacy service, receiving a request from the second data processor to access at least a portion of the private data, the request including the second data access block; In the cloud data privacy service, in response to determining that the second data access block received from the second data processor is valid, permitting the second data processor to perform at least partial access to at least a portion of the private data; The computer program according to claim 13, further causing the above to be executed.

Images