Patent Description:
Data sharing systems may enable sharing user-specific data of a user among diverse business entities (e.g. hospitals, schools, universities, researchers, insurances, financial advisors and/or companies) in Business-To-Business (B2B) and Business-To-Customer-To-Business (B2C2B) contexts with control by the user. For example, the user may be keen on sharing user-specific data like a transcript with a university or an employer in connection with an application process.

The private information included in the user-specific data can be sensitive and confidential. On this account, data sharing systems may need to comply with a General Data Protection Regulation (GDPR). A centralized environment with vulnerabilities may introduce a single point of failure for the user-specific data.

Means to exchange the user-specific data among different business entities is one of the most business critical components. Currently, data is stored in data structures locked in to "vendor-specific" systems. Those may not provide the user or a customer with a "business-agnostic" data sharing system for sharing the user-specific data among the diverse business entities.

Further, the user/customer may not have any control, clarity and/or ownership of the user-specific data.

Document <CIT> relates to an improved stock authorization certification mechanism DPOS, smart contract, cloud storage and interceptable signature technology, in particular to a model and method for storing and sharing electronic medical records based on blockchain which can be used for secure storage and sharing of data under blockchain technology.

Thus, there may be a demand of a business agnostic, GDPR compliant and/or auditable data sharing system for sharing user-specific data of a user with an improved control by the user.

This demand may be satisfied by the subject matter of the appended claims.

A basic idea of the present disclosure is to establish two separated, but interconnected entities. One of the entities is configured to store the user-specific data and to retrieve access rights from the other entity to check a permission of various external entities to access the user-specific data.

The user may have a permanent access to the access rights, for example, to modify or check the access rights which enables the user to control sharing the user-specific data among diverse external entities.

According to a first aspect, embodiments of the present disclosure relate to a data sharing system. The data sharing system comprises a first data processing circuitry configured to store the user-specific data of a user. The data sharing system further comprises at least one second data processing circuitry configured to store access rights of an external entity to access the user-specific data stored on the first data processing circuitry. Additionally, the data sharing system comprises an interface between the first data processing circuitry and the second data processing circuitry configured to communicate the access rights from the second data processing circuitry to the first data processing circuitry. The data sharing system also comprises a user interface configured to authenticate the user to the second data processing circuitry for modifying the access rights. Additionally, the data sharing system comprises an interface between the first data processing circuitry and the external entity configured to communicate a portion of the user-specific data to the external entity in accordance with the access rights.

The external entity may correspond to a party requesting access to the user-specific data. The external entity, for example, is an insurance, an employer and/or a physician. The external entity may interact with the interface between the external entity and the first data processing circuitry. Such an interface can be a programmable hardware (e.g. personal computer or a mobile device) connected to the first data processing circuitry via the internet.

The first data processing circuitry, for example, comprises a data storage. The data storage can be implemented as a cloud storage (e.g. InterPlanetary File System (IPFS), Sia or StorJ) accessible via the internet or alternatively as a "local" data storage, such as a hard disk drive, a Read Only Memory (ROM) or comparable electro-mechanical data storage devices.

The user-specific data may comprise personal information, such as an economical information (e.g. account balance, debts, loan or salary), educational information (e.g. grades or transcripts), health information (e.g. medical findings or X-ray images) or identity-related information (e.g. age or address).

The user-specific data may optionally comprise binary values, for example, indicative of whether the user is older than <NUM> years of age and/or if the user graduated at a university.

The second data processing circuitry may be separated from the first data processing circuitry.

The second data processing circuitry may, similar to the first data processing circuitry, comprise another data storage which can be implemented as another cloud storage comprising multiple interconnected data servers. Alternatively, the second data processing circuitry can comprise another "local" data storage.

Thus, for example, the access rights can be stored on the cloud storage of the second data processing circuitry.

The access rights may include data defining whether and which portion of the user-specific data may be shared with the external entity. In general, the access rights may relate to multiple various external entities. The external entities are, for example, schools, universities, employer, job application interviewers, hospitals, physicians, researchers, insurances, financial advisors and/or (government) agencies.

The access rights of different external entities can be different. Thus, the portion of the user-specific data which is accessible to the different entities may be different.

The interface between the first and the second data processing circuitry, for example, comprises a physical link to communicate the access rights to the first data processing circuitry. The physical link can comprise one or more radio communication links and/or wired links which each individually or in combination may form a network path between the first and the second data processing circuitry.

The first data processing circuitry can obtain the access rights from the second data processing circuitry via the interface between the first and the second data processing circuitry to determine the portion of the user-specific data to be provided to the external entity. For, example, the first data processing circuitry can retrieve the access rights prior to providing the portion of the user-specific data to the external entity.

The user interface may comprise an input device and optionally a user software, such as an application programming interface (API) implemented on the input device. The input device can be configured to establish a (data) connection to the second data processing circuitry to authenticate the user to whom the user-specific data belongs. For example, the input device can execute an authentication process using a user-specific input (e.g. fingerprint, credentials and/or facial recognition).

In case of a successful authentication, the user can modify the access rights, e.g. extend or restrict the access rights for the external entity.

Thus, the user may define the portion of the user-specific data which the external entity may access. In general, the portion of the user-specific data may comprise the user-specific data completely or partially.

The portion of the user-specific data can be communicated via the interface between the first processing circuitry and the external entity.

Thus, the user can control sharing the user-specific data among the external entities by modifying the access rights. Further, the user is able to restrict or revoke access rights of one of the external entities.

This may provide an enhanced control of the user-specific data shared by the data sharing system compared to known data sharing systems.

In some embodiments of the data sharing system, the user interface is configured to provide user-specific credentials to the second data processing circuitry to authenticate the user.

The credentials, for example, comprise a user-specific input (e.g. fingerprint, credentials and/or facial recognition).

The second data processing circuitry may verify the user-specific credentials through a comparison with reference data, for example, indicative of a password or image data related to a face of the user.

This, for example, enables the user to authenticate himself independently of the input device utilized as user interface. For example, the user owns multiple input devices (e.g. a mobile, a tablet and a personal computer). However, the user can authenticate himself regardless of which of the input device he is using with the user-specific credentials.

In some embodiments of the data sharing system, the second data processing circuitry is further configured to store ownership rights of the user to modify the access rights.

The ownership rights, for example, specify which of the access rights can be modified by the user.

Further, the ownership rights may specify the user who is allowed to modify the access rights. Thus, for example, a permission for modifying the access rights can be transferred to another user.

In some embodiments of the data sharing system, the second data processing circuitry is further configured to store the access rights and the ownership rights on a blockchain.

The blockchain can be understood as a (growing) list of records, called blocks, which are linked using cryptographic functions. For purposes of auditability, each block contains a cryptographic hash of the previous block and a timestamp.

In context of the present disclosure, at least one of the blocks may further contain the access rights. The blockchain can be shared within the multiple interconnected data servers (e.g. of a distributed ledger) of the second data processing circuitry.

For accessing or modifying the access rights may the user can submit a transaction to the blockchain. Consequently, another block including a hash of a preceding block, a timestamp of a modification of the access rights and, for example, modified access rights can be added to the blockchain. One block of the blockchain can be indicative of one or more modifications of the access rights.

The skilled person having benefit from the present disclosure will appreciate that storing the access rights on a blockchain may enable the user to audit preceding modifications and invocations of the access rights.

Further, the blockchain may prevent the access rights from being tampered with by non-authorized entities.

In some embodiments of the data sharing system, the first data processing circuitry is further configured to combine the blockchain with access information on communicating the portion of the user-specific data to the external entity.

For example, the first data processing circuitry logs in the form of the access information at which time which one of the different external entities had access to which portion of the user-specific data.

The access information can be combined with the blockchain by submitting another transaction to the blockchain.

This may enable the user to retrace a distribution of the user-specific data by reference to the blockchain.

In some embodiments of the data sharing system, the second data processing circuitry is further configured to store a first cryptographic accumulator defined for the ownership rights and a second cryptographic accumulator defined for the access rights. The first cryptographic accumulator may accumulate one or more first members indicative of the ownership rights and the second cryptographic accumulator may accumulate one or more second members indicative of the access rights.

A cryptographic accumulator can be understood as a membership function which allows to verify if an input of the membership function is a member (e.g. a prime number or a hash) of the cryptographic accumulator without revealing every member included.

This may enable the first data processing circuitry to determine and/or reveal the access rights or the ownership rights of the external entity and the user, respectively, without revealing further access rights or ownership rights stored on the first data processing circuitry, as stated in the following in more detail.

The access rights and/or the ownership rights can be reflected by so-called "commitments" according to a cryptographic primitive called "commitment scheme". The skilled person having benefit from the present disclosure will appreciate that alternatively the commitments of the access rights and/or the ownership rights can be stored in cryptographic accumulators, such as Merkle trees/hash trees.

The first and the second cryptographic accumulator can be stored on the blockchain.

In some embodiments of the data sharing system, the user interface is further configured to provide to the second data processing circuitry a first zero knowledge proof. The first cryptographic accumulator can be configured to authenticate the user by verifying that a user-specific input of the first zero knowledge proof corresponds to at least one of the first members accumulated by the first cryptographic accumulator.

In cryptography, a zero knowledge proof or zero knowledge protocol is a method by which a prover can prove to a verifier that they know an information, without revealing the information to the verifier. The zero knowledge proof can be generated using a predefined proving logic and the information as input. Subsequently, the zero knowledge proof can be verified using a predefined verifying logic associated with the proving logic.

In this case, the user or the user interface can be understood as the prover, whereas the second data processing circuitry may act as the verifier.

Optionally, an authentication of the user can be performed by a Smart Contract running on the blockchain by using the first zero knowledge proof.

For example, the user proves a knowledge on the user-specific input indicative of the ownership rights using the first zero knowledge proof. The user-specific input may comprise one or more commitments associated with the ownership rights of the user.

The first cryptographic accumulator may be a one way membership function and may calculate an accumulated value from the first members.

For an authentication of the user, the first cryptographic accumulator may verify if the user-specific input of the first zero knowledge proof is one of the first members accumulated by the first accumulator.

For this, the first cryptographic accumulator, for example, verifies whether the user specific input corresponds to a (prime) factor of the accumulated value.

In this way, the second data processing circuitry can determine the ownership rights of the user from the corresponding first members without the user being required to reveal his identity publicly.

In some embodiments of the data sharing system, the first data processing circuitry is further configured to obtain from the external entity a second zero knowledge proof. The second cryptographic accumulator can be configured to proof an ownership of the access rights by verifying that an entity-specific input of the second zero knowledge proof corresponds to at least one of the second members accumulated by the cryptographic accumulator for a verification of the second zero knowledge proof. The interface between the first and the second data processing circuitry may be further configured to communicate the access rights from the second data processing circuitry depending on the verification of the second zero knowledge proof.

In this way, the second accumulator can verify if the entity-specific input of the second zero knowledge proof is one of the members accumulated by the second accumulator to obtain the access rights of the external entity.

In some embodiments of the data sharing system, the second data processing circuitry is further configured to obtain from the external entity a third zero knowledge proof for a verification of the third zero knowledge proof by comparing an entity-specific input with the second members of the cryptographic accumulator. The second data processing circuitry may be further configured to reveal the access rights to the external entity depending on the verification of the third zero knowledge proof.

Similar to a concept described in connection with the first zero knowledge proof, the entity-specific input may comprise one or more commitments reflecting the access rights.

Analogously to the concept described in connection with the first knowledge proof, the external entity can verify the access rights without revealing an identity using the second and the third zero knowledge proof, respectively.

In other words, using a zero knowledge proof, the access rights can be stored in a privacy preserving way such that neither the external entity nor the user needs to reveal an identity to prove, access or modify the access rights.

In some embodiments of the data sharing system, the user-specific data is encrypted with a symmetric key which is suitable for decrypting the user-specific data encrypted with the symmetric key. The first data processing circuitry may be further configured to obtain the symmetric key from the user interface and provide the symmetric key to the external entity for decrypting the user-specific data.

Encrypting and decrypting the user-specific data using the symmetric key (or "session key") allows a symmetric encryption which may be faster than an asymmetric encryption using pairs of a public and a private key.

In some embodiments of the data sharing system, the user interface is configured to generate a re-encryption key depending on a public key of the external entity. The user interface may be further configured to provide the re-encryption key to the first data processing circuitry. The first data processing circuitry may be further configured to generate re-encrypted user-specific data by re-encrypting the portion of the user-specific data. The re-encrypted user-specific data may be decipherable using a private key (of the external entity) related to the public key. The first data processing circuitry may be further configured to provide the re-encrypted user-specific data to the external entity.

The user-specific data stored on the first data processing circuitry, for example, are encrypted to prevent the first data processing circuitry from revealing personal information included by the user-specific data.

In order to enable certain entities, such as the external entity, to decrypt the user-specific data, the user interface may enable the first processing circuitry to re-encrypt the user-specific data such that the external entity can decrypt the re-encrypted user specific data with its private key.

In general, the re-encryption key may depend on a public key and the private key of the external entity as well as on another public and private key of the user. This may further enable the user to decrypt the re-encrypted user-specific data.

Thus, the users-specific data can be stored and distributed in an encrypted form for privacy protection.

In some embodiments of the data sharing system, the user interface is further configured to obtain an access request for the external entity to access a requested portion of the user-specific data and modify the access rights according to the access request.

This may enable the user to share the portion of the user-specific data with external entities requesting for the user-specific data.

In some embodiments of the data sharing system, the first data processing circuitry is configured to obtain the user-specific data from a data providing entity commissioned by the user.

The data providing entity, for example, is a hospital, a physician, a school, a university or a government agency.

Thus, the user does not need to provide the user-specific data to the first data processing circuitry by himself.

This, for example, can preserve an anonymity of the user when obtaining the user-specific data. Further, this may prevent the user-specific data from being accessed through data leaks of the user interface which alternatively can be supposed to provide the user-specific data to the first data processing circuitry.

In some embodiments of the data sharing system, the second data processing circuitry is further configured to store information of the user-specific data and, wherein the access rights further comprise information access rights for the external entity to access the information. The second data processing circuitry may further be configured to communicate a portion of the information to the external entity in accordance with the information access rights for generating the access request based on the portion of the information.

The information of the user-specific data can be indicative of a type of personal information comprised by the user-specific data. Types of personal information, for example indicate whether the user-specific data relate to findings of a physician, a transcript and/or a financial matter of the user.

This allows the external entity to make selective access requests based on the portion of the information.

In some embodiments of the data sharing system, the data sharing system further comprises at least a third data processing circuitry storing a public blockchain. The public blockchain may be configured to determine an identity of the user by reference to user-related verifiable credentials provided by the user interface. Further, the public blockchain may be configured to authenticate the user to the second data processing circuitry depending on the identity of the user.

In some embodiments of the data sharing system, the public blockchain is further configured to determine an identity of the external entity by reference to verifiable credentials provided by the external entity for retrieving the access rights of the external entity at the second data processing circuitry.

The public blockchain, for example, can identify the external entity and the user by the verifiable credentials, for example, for an authentication to the second data processing circuitry, respectively. To this end, the verifiable credentials can comprise a set of tamper-evident metadata that cryptographically proves the identity and/or properties of the external entity and/or the user for the authentication. For instance, the metadata may comprise a string indicative of the identity of the external server or the user/user interface, respectively. Further, the verifiable credentials, for example, may state a banking account information or whether the user is older than <NUM> or <NUM> years of age.

This may avoid siloed or federated identities of the user or the external entity in connection with the data sharing system.

According to a second aspect, the present disclosure relates to a method for sharing user-specific data. The method comprises storing user-specific data of a user on a first data processing circuitry and storing, on a second data processing circuitry, access rights of an external entity to access the user-specific data stored on the first data processing circuitry. Further, the method comprises communicating the access rights from the second data processing circuitry to the first data processing circuitry and communicating portions of the user-specific data from the first data processing circuitry to the external entity in accordance with the access rights.

The method can be executed, for example, using the data sharing system described above.

In some embodiments of the method, the method further comprises authenticating a user to the second data processing circuitry for modifying the access rights using a user interface. According to a third aspect, the present disclosure relates to a computer program which comprises instructions which, when executed by at least one processor, causes the processor to perform the method described previously.

According to a fourth aspect, the present disclosure relates to a first user data processing circuitry. The user data processing circuitry comprises a user data storage configured to store user-specific data of a user and an interface. The interface is configured to obtain access rights of an external entity to access the user-specific data from a second data processing circuitry and communicate portions of the user-specific data to the external entity in accordance with the access rights.

According to a fifth aspect, the present disclosure relates to a second data processing circuitry which comprises an access data storage. The access data storage is configured to store access rights of an external entity to access user-specific data of a user stored on a first data processing circuitry. The access data processing circuitry further comprises an interface which is configured to communicate the access rights to the first data processing circuitry storing the user-specific data for communicating portions of the user-specific data from the first data processing circuitry to the external entity in accordance with the access rights. The interface is further configured to enable a user to modify the access rights in response to a user interface authenticating the user.

Accordingly, while further examples are capable of various modifications and alternative forms, some particular examples thereof are shown in the figures and will subsequently be described in detail. However, this detailed description does not limit further examples to the particular forms described. Same or like numbers refer to like or similar elements throughout the description of the figures, which may be implemented identically or in modified form when compared to one another while providing for the same or a similar functionality.

It will be understood that when an element is referred to as being "connected" or "coupled" to another element, the elements may be directly connected or coupled via one or more intervening elements. If two elements A and B are combined using an "or", this is to be understood to disclose all possible combinations, i.e. only A, only B as well as A and B, if not explicitly or implicitly defined otherwise. An alternative wording for the same combinations is "at least one of A and B" or "A and/or B". The same applies, mutatis mutandis, for combinations of more than two Elements.

Known data sharing systems have limited privacy features which, for example, enables an administrator of the data sharing system to have full access on sensitive user-specific data and information associated with the user-specific data.

Further, known concepts of data sharing systems may not enable a user to have permanent control of an access of external entities to the user-specific data. For example, once the user gave an approval to an external entity to access the user-specific data, the user may not be able to revoke the approval subsequently in known concepts for data sharing systems.

<FIG> illustrates a first example of a data sharing system <NUM>.

The data sharing system <NUM> comprises a first data processing circuitry <NUM> configured to store user-specific data of a user <NUM> and at least one second data processing circuitry <NUM> which is configured to store access rights of an external entity <NUM> to access the user-specific data stored on the first data processing circuitry <NUM>.

The data sharing system <NUM> further comprises an interface <NUM>' between the first data processing circuitry <NUM> and the second data processing circuitry <NUM> configured to communicate the access rights from the second data processing circuitry <NUM> to the first data processing circuitry <NUM>.

Further, the data sharing system <NUM> comprises a user interface <NUM> which is configured to authenticate the user <NUM> to the second data processing circuitry <NUM> for modifying the access rights.

The data sharing system <NUM> further comprises an interface <NUM>'' between the first data processing circuitry <NUM> and the external entity <NUM> configured to communicate a portion of the user-specific data to the external entity <NUM> in accordance with the access rights.

The interfaces <NUM>' and <NUM>'' can be understood as physical links between the first and the second data processing circuitry <NUM> and <NUM> or the first data processing circuitry <NUM> and the external entities <NUM>, respectively.

As shown, the data sharing system <NUM> may further comprise one or more data providing entities <NUM> which can generate the user-specific data and handover the user-specific data to the first data processing circuitry <NUM>. For example, a hospital, a university or a pharma company may act as a data providing entity <NUM>. The hospital <NUM>, for example, provides user-specific data comprising medical findings of the user <NUM> to the first data processing circuitry <NUM>.

At the same time, the data providing entities <NUM> may also represent external entities <NUM> which can access the user-specific data in accordance with the access rights. For example, the hospital <NUM>, <NUM> can access the user-specific data to obtain the medical findings of preceding medical examinations.

The concept described in connection with the <FIG>, may enable occasional auditing such that a consortium, comprising the second data processing circuitry <NUM>, the data providing entities <NUM> and/or the external entities <NUM>, can affirm that the first data processing circuitry <NUM> works as intended.

<FIG> schematically illustrates an example of the first data processing circuitry <NUM> which may also be referred to a user data processing circuitry. As shown in <FIG>, the user data processing circuitry/ first data processing circuitry <NUM> can comprise a user data storage <NUM> configured to store the user-specific data of the user <NUM> and an interface <NUM>. The interface <NUM> is configured to obtain access rights of the external entity <NUM> to access the user-specific data from an access data storage, such as the second data processing circuitry <NUM>. Further, the interface <NUM> is configured to communicate the portion of the user-specific data to the external entity <NUM> in accordance with the access rights. In some embodiments of the data sharing system <NUM>, the interface <NUM>' and/or the interface <NUM>" comprise the interface <NUM> of the user data processing circuitry <NUM>.

In some further embodiments, the first data processing circuitry <NUM>, for example, is designed as a cloud storage integrated in a network. The network, for example comprises the interfaces <NUM>' and <NUM>'' to connect the cloud storage <NUM> with the external entities <NUM> and one or more nodes of a distributed ledger/blockchain (system) forming the second data processing circuitry <NUM>.

In some embodiments, the data sharing system <NUM> may comprise multiple cloud storages <NUM>.

Thus, without any limitation of the generality, the second data processing circuitry <NUM> may also be referred to as a blockchain node.

As shown in <FIG>, the second data processing circuitry <NUM>, which can also be referred to as access data processing circuitry, generally can comprise an access data storage <NUM>. The access data storage is configured to store access rights of the external entity <NUM> to access user-specific data of the user <NUM> stored on the user data processing circuitry <NUM>. Further, the second data processing circuitry can comprise an interface <NUM> configured to communicate the access rights to the user data processing circuitry <NUM> storing the user-specific data for communicating portions of the user-specific data from the user data processing circuitry to the external entity in accordance with the access rights. The interface <NUM> further may enable the user <NUM> to modify the access rights in response to the user interface <NUM> authenticating the user <NUM>.

Thus, the access rights can be stored on the blockchain node <NUM> for a distributed and immutable repository of the user-specific data.

An immutable audit trail (access information) is stored on the blockchain node <NUM>. The immutable audit trail, for example, indicates modifications of the access rights.

Since the user <NUM> can connect to any of various nodes of the blockchain node <NUM>, the user <NUM> can control sharing the user-specific data independently from a single of the various external entities <NUM> (e.g. companies or organizations).

Further, the blockchain node <NUM> may include ownership rights which enable the user <NUM> to modify the access rights in case of a successful authentication of the user to the blockchain node <NUM>.

The commitments of the access rights and the ownership rights, further, can be stored within cryptographic accumulators comprising multiple members each corresponding to one of the commitments (e.g. a hash value. Each of the commitments can state access rights of one of the external entities <NUM> or the ownership rights of the user <NUM>/user interface <NUM>.

A first cryptographic (data ownership) accumulator may comprise at least one data ownership commitment and a second cryptographic (data access permission) accumulator may comprise multiple data access commitments.

This can enable a verification of the access rights and the ownership rights, respectively, as stated in more detail later.

The access rights, for example, define which of the external entities may access which portion of the user-specific data. For example, the access rights may allow the hospital <NUM>, <NUM> to access a portion of the user-specific data comprising the medical findings of the preceding medical examinations but may also refrain the hospital from accessing another portion of the user-specific data regarding to financial matters of the user <NUM>.

In general, the portion of the user-specific data, which is accessible for the external entity <NUM> according to the access rights, can comprise, for example, all files comprised of the user-specific data or none of those.

The user interface, for example, provides user-specific credentials to the blockchain node <NUM> for an authentication by reference to the user-specific credentials in response to a successful login of the user to an Application Programming Interface (API). In some embodiments of the present disclosure, the external entities <NUM> and/or the data providing entities <NUM> provide the appropriate Application Programming Interface (API) to the user <NUM> or the user interface <NUM>.

Thus, the user <NUM> can modify the access rights at any time via the API, for example, in order to grant and/or revoke the access rights of the external entities <NUM> to access the user-specific data.

<FIG>, <FIG>, <FIG> and <FIG> schematically illustrate further examples of the data sharing system <NUM>.

<FIG> schematically shows a basic concept of the data sharing system <NUM>.

The external entities <NUM> and the data providing entities <NUM> are considered as separated for simplifying an explanation of the further examples of the data sharing system <NUM>. However, the external entities <NUM> and the data providing entities <NUM> may also correspond to each other in general, as stated above.

For a further simplification, following explanations of the data sharing system <NUM> may also refer to one or a portion of the external entities <NUM> without any limitation of the generality.

The data providing entities <NUM> can collect the user-specific data and transmit those to the cloud storage <NUM>.

Moreover, the data providing entities <NUM> can set the ownership rights which specify that the user <NUM> can modify the access rights. To this end, the data providing entities <NUM> can transmit the ownership rights and optionally predefined default access rights to the blockchain node <NUM>.

As illustrated in <FIG>, the ownership rights can be indicative of a data ownership record <NUM> which enables the user <NUM> to modify the access rights, as stated in more detail later.

The ownership record <NUM> can be set by one of the data providing entities <NUM> when they submit the user-specific data to the cloud storage <NUM>. Optionally, the user <NUM> can also set or modify ownership records.

The data ownership record <NUM>, for example, comprises a data ID <NUM> of a portion of the user-specific data and a data ownership commitment <NUM>. The data ID <NUM>, for example, is indicative of a unique identifier of the portion of the user-specific data. The data ownership commitment <NUM> is indicative of a cryptographic primitive enabling the user <NUM> to verify his ownership rights for modifying the access rights.

In order to prevent others like the external entities <NUM> from accessing the ownership record <NUM>, this can be encrypted with a public key <NUM> of the user interface and a first random value <NUM>. The ownership record <NUM> can be shared with the user interface <NUM> to transmit the first random value <NUM> and the data ID <NUM>.

As shown in <FIG>, <FIG>, <FIG> and <FIG>, the external entities <NUM> can request to access the user-specific data. For example, the external entities <NUM> can create an access request based on information of the user-specific data. With the access request, the external entity <NUM> can ask the user <NUM> for a modification of the access rights which enables the external entity <NUM> to access requested user-specific data.

The information can be stored and made publicly available on the cloud storage <NUM> by the user <NUM>. To this end, the user <NUM> can set appropriate information access rights which enable the external entities <NUM> to create the access request by reference to the information of the user-specific data.

The external entity <NUM> may transmit the access request to the user interface <NUM> via the API. Consequently, the user <NUM> may receive a notification from the user interface <NUM> with an option to whether reject the access request or to modify the access rights in accordance with the access request. In general, the user <NUM> can also modify the access rights such that the external entity <NUM> can (only) access a portion of the requested user-specific data.

Consequently, the external entity <NUM> can send a query to the cloud storage <NUM> to access the user-specific data. The cloud storage <NUM> may compare the query with the access rights stored on the blockchain node <NUM> to grant or reject an access of the external entity <NUM> to the user-specific data.

The access rights can be encrypted with a public key of the cloud storage <NUM> and optionally with the public key of the user interface <NUM> in order that (only) the cloud storage <NUM> and/or the user <NUM> can access the access rights using a private key of the user interface <NUM> and/or the cloud storage <NUM>, respectively.

Thus, "non-authorized" entities, such as the external entities <NUM> or the data providing entities <NUM> cannot consult the access rights.

As illustrated in <FIG>, <FIG> and <FIG>, the user interface <NUM> can authenticate the user <NUM> using a first zero knowledge proof <NUM> and the external entity <NUM> can prove its access rights using a second and/or a third zero knowledge proof <NUM>.

As shown in <FIG>, the user interface <NUM> is configured to generate the first zero knowledge proof <NUM> by applying a predefined logic <NUM> to a user-specific input.

The user-specific input, for example, comprises the public key <NUM>, the first random value <NUM>, a data access commitment <NUM> and a first cryptographic accumulator <NUM> indicative of the ownership rights.

For this, the user interface <NUM> may obtain the first cryptographic accumulator <NUM> from the blockchain node <NUM>.

The data access commitment <NUM> can be generated by the user interface <NUM> using a second random value <NUM>, the data ID <NUM> and a public key <NUM> of the external entity <NUM> as input.

The user interface <NUM> can obtain the data ID <NUM> and the first random value <NUM> by decrypting the ownership record <NUM> obtained from the blockchain node <NUM>.

The user interface <NUM> can authenticate the user <NUM> through a comparison of the first cryptographic accumulator <NUM> with the data ownership commitment <NUM> stored on the blockchain node <NUM> using the first zero knowledge proof <NUM>. For example, the blockchain node <NUM> applies a verification program <NUM> to the first zero knowledge proof <NUM> for the comparison of the first cryptographic accumulator <NUM> with the data ownership commitment <NUM>.

Depending on the comparison of the data ownership commitment <NUM> with the first cryptographic accumulator <NUM>, for example, a Smart Contract running on the blockchain node <NUM> may enable the user <NUM> to modify the access rights according to the data access commitment <NUM>.

Further, the blockchain node <NUM> can store the data access commitment <NUM> and calculate a second cryptographic accumulator <NUM> by reference to the data access commitment <NUM>.

In this way, the user <NUM> can grant access rights. Analogously, the user <NUM> can revoke some of the access rights.

As illustrated by <FIG>, the external entity <NUM> subsequently can verify its access rights using a second zero knowledge proof <NUM> to access the portion of the user-specific data identified with the above mentioned data ID <NUM>.

For this, the external entity <NUM> can invoke the second cryptographic accumulator <NUM> from the blockchain node <NUM> as entity-specific input of the second zero knowledge proof <NUM>. The external entity <NUM> further creates the data access commitment <NUM> as further entity-specific input of the second zero knowledge proof <NUM> using the data ID <NUM>, its public key <NUM> and the random value <NUM>. The external entity <NUM>, for example, creates the second zero knowledge proof <NUM> by applying another predefined logic to the entity-specific input.

Subsequently, the cloud storage <NUM> can verify the access rights of the external entity <NUM> using the second cryptographic accumulator <NUM> stored on the blockchain node <NUM> for a comparison with the data access commitment <NUM> included in the second zero knowledge proof <NUM>. For this, the cloud storage <NUM> can apply another verification program <NUM>' to the second zero knowledge proof <NUM>.

In case of a successful verification, the cloud storage <NUM> can provide the portion of the user-specific data with the appropriate data ID <NUM> to the external entity <NUM>.

<FIG> illustrates a third example of the data sharing system <NUM>. Compared to the example shown in <FIG>, in the third example, the user-specific data may be stored on the cloud storage <NUM> in an encrypted form.

<FIG> shows a re-encryption of the user-specific data in more detail.

For example, the user-specific data can be encrypted by the data providing entity <NUM> using the public key of the user interface <NUM>. Thus, the cloud storage <NUM> cannot decrypt the user-specific data.

Subsequently, the user interface <NUM> provides a re-encryption key <NUM> to the cloud storage <NUM> to generate re-encrypted user-specific data by "re-encrypting" the portion of the user-specific data to be provided to the external entity <NUM> in accordance with the access rights.

The re-encryption key <NUM> may depend on the public key of the external entity <NUM> such that the re-encrypted user-specific data can be decrypted using the private key of the external entity <NUM>.

For this, the user interface <NUM> can obtain the public key of the external entity <NUM> and generate the re-encryption key <NUM> with respect to this public key related to the private key of the external entity <NUM>.

This may ensure that the cloud storage <NUM> may not leak personal information included in the user-specific data to non-authorized entities.

Optionally, the re-encryption key <NUM> may also depend on the public key of the user interface <NUM> to enable the user <NUM> to access the user-specific data as well.

In some further examples, the user-specific data is encrypted with a symmetric key which is also suitable for decrypting the user-specific data encrypted with the symmetric key.

In this case, the cloud storage <NUM> may transfer the symmetric key from the user interface <NUM> to the external entity <NUM> for decrypting the user-specific data.

Using the symmetric key may cause a faster encryption and/or decryption compared to an asymmetric encryption/decryption using pairs of public and private keys.

<FIG> illustrates a fourth example of the data sharing system <NUM>. Here, the data sharing system <NUM> further comprises a third data processing circuitry storing a public blockchain <NUM>.

The public blockchain <NUM> is configured to determine an identity of the user <NUM> by reference to user-related verifiable credentials provided by the user interface <NUM>.

The user interface <NUM>, for example, is registered with the public blockchain <NUM>. The public blockchain <NUM> may assign the identity, a so-called Decentralized Identifier (DID), to the user interface <NUM> in response to a registration of the user interface <NUM> with the public blockchain <NUM>.

To authenticate the user <NUM> to the blockchain node <NUM>, the user interface <NUM> can provide the user-related verifiable credentials to the public blockchain <NUM>. The skilled person having benefit from the present disclosure will appreciate that the public blockchain <NUM> can execute a DID lookup to associate the identity of the user <NUM> with the user-related verifiable credentials. For this, the public blockchain <NUM> may run an appropriate computer program (e.g. a DID resolver).

The public blockchain <NUM>, thus, can authenticate the user <NUM> to the blockchain node <NUM>, for example, for a modification of the access rights.

Analogously, the public blockchain <NUM> can determine an identity of the external entity <NUM> by reference to verifiable credentials provided by the external entity <NUM>.

Thus, the blockchain node <NUM> can provide the external entity <NUM> and/or the cloud storage with a portion of access rights by reference to the identity of the external entity <NUM>.

This may allow anonymous data sharing between any entities registered with the public blockchain <NUM>. Further, the registered entities may not require a certificate from a single authority, as for example, in connection with concepts based on siloed or federated identities.

In the following, the concept of the present disclosure is described by reference to some use cases of the data sharing system <NUM>, which are shown in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, 3f.

In a first use case, shown in <FIG>, the user <NUM> is a graduate, the external entity <NUM> is an interviewer and the data providing entity <NUM> corresponds to a school of the graduate <NUM>.

The graduate <NUM> intends to share his user-specific data with the interviewer <NUM> in connection with a job application. In this case, the user-specific data, for example, is a transcript.

The interviewer <NUM> may send a data request to the user interface <NUM> of the graduate <NUM>. The graduate <NUM> may accept the data request and return a download link to the interviewer <NUM>.

In order to allow the interviewer <NUM> to access the transcript, the user interface <NUM> can obtain the data ownership record from the blockchain node <NUM> to generate the first zero knowledge proof for an authentication.

Due to a successful authentication by reference to the first cryptographic accumulator, the graduate <NUM> is enabled to modify the access rights using the user interface <NUM>. The graduate <NUM>, for example, modifies the access rights such that the interviewer <NUM> is allowed to access the transcript and provides a data access record to the blockchain node <NUM>.

The interviewer <NUM> can generate the second zero knowledge proof based on the data access record and provides the second zero knowledge proof to the cloud storage <NUM> to verify his access rights to the cloud storage <NUM>. The cloud storage <NUM> verifies the second zero knowledge proof by reference to the second cryptographic accumulator and provides the transcript to the interviewer <NUM>.

In the second use case, shown in <FIG>, the user <NUM> corresponds to a patient, the external entity <NUM> corresponds to a researcher and the data providing entity <NUM> corresponds to a hospital.

The researcher <NUM> can look up user-specific data stored on the cloud storage <NUM> with regard to an information associated with the user-specific data. For example, with respect to the information, the researcher <NUM> can recognize whether the user-specific data relate to a predefined medical issue or an economical issues.

The cloud storage, for example, stores user-specific data of multiple users/patients.

Thus, the researcher <NUM> can obtain a list of sets with user-specific data of the multiple patients and can create one or more access requests for the user-specific data related to the predefined medical issue in which the researcher <NUM> may be interested.

For example one of the access requests may be transmitted to the user interface <NUM> via the hospital <NUM> to preserve a privacy and/or anonymity of the patient <NUM> towards the researcher <NUM>.

Subsequently, the patient <NUM> can allow the researcher <NUM> to access the user-specific data analogously, as described in connection with the first use case, to share the user-specific data with the researcher <NUM>.

A third use case, shown in <FIG>, is similar to the second use case, except that in the third use case the patient <NUM> receives the access request from the researcher <NUM> via the blockchain node <NUM>.

However, the anonymity of the patient <NUM> and the researcher <NUM> may be preserved using the blockchain node <NUM> for transmitting the access request.

In a fourth use case, shown in <FIG>, the user <NUM> corresponds to a job seeker, the external entities <NUM> correspond to various companies and the data providing entity <NUM> corresponds to a school of the job seeker.

The school <NUM> uploads user-specific data, such as a diploma, to the cloud storage <NUM>. Further, the job seeker uploads further user-specific data, such as a curriculum vitae (CV), to the cloud storage.

The job seeker <NUM> can proof its ownership of the diploma using the first zero knowledge proof. This may ensure that the job seeker may not use a fake diploma for a job application.

The user interface <NUM> can transmit a download link to the various companies <NUM> such that the companies <NUM> can trigger a download of the CV and the diploma from the cloud storage. Furthermore, the job seeker <NUM> can modify the access rights in such a way that the various companies <NUM> can access the CV and the diploma.

Subsequently, the various companies <NUM> can provide the second zero knowledge proof to the cloud storage <NUM> and download the CV and the diploma from the cloud storage in response to a successful verification of the second zero knowledge proof.

In a fifth use case, shown in <FIG>, the data providing entity <NUM> corresponds to an insurance broker and the external entity <NUM> corresponds to a financial advisor.

The insurance broker <NUM> may upload a portfolio as user-specific data to the cloud storage <NUM>. Initially, the user <NUM> may allow the financial advisor <NUM> to access the portfolio.

Later, the user <NUM> can revoke the access rights of the financial advisor using the first zero knowledge proof for the authentication.

Subsequently, the financial advisor <NUM> can create the second zero knowledge proof to access the portfolio. However, due to a revocation of the access rights by the user <NUM>, the financial advisor <NUM> cannot access the portfolio.

Thus, the user <NUM> can prevent a distribution of the user-specific/portfolio data to the financial advisor <NUM> although the user <NUM> previously allowed the financial advisor <NUM> to access the portfolio.

<FIG> schematically illustrates a method <NUM> for sharing user-specific data.

The method <NUM> comprises storing <NUM> the user-specific data of a user on a first data processing circuitry and storing <NUM> access rights of an external entity to access the user-specific data stored on the first data processing circuitry.

Further, the method <NUM> comprises communicating <NUM> the access rights from the second data processing circuitry to the first data processing circuitry and communicating <NUM> portions of the user-specific data from the first data processing circuitry to the external entity in accordance with the access rights.

Functions of various elements shown in the figures, including any functional blocks labeled as "means", "means for providing a signal", "means for generating a signal. ", etc., may be implemented in the form of dedicated hardware, such as "a signal provider", "a signal processing unit", "a processor", "a controller", etc. as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which or all of which may be shared. However, the term "processor" or "controller" is by far not limited to hardware exclusively capable of executing software, but may include digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage.

Claim 1:
A data sharing system, comprising:
a first data processing circuitry (<NUM>) configured to store user-specific data of a user (<NUM>);
at least one second data processing circuitry (<NUM>) configured to store access rights of an external entity to access the user-specific data stored on the first data processing circuitry (<NUM>);
an interface (<NUM>') between the first data processing circuitry (<NUM>) and the second data processing circuitry (<NUM>) configured to communicate the access rights from the second data processing circuitry (<NUM>) to the first data processing circuitry (<NUM>);
a user interface (<NUM>) configured to authenticate the user to the second data processing circuitry (<NUM>) for modifying the access rights; and
an interface (<NUM>") between the first data processing circuitry (<NUM>) and the external entity (<NUM>) configured to communicate a portion of the user-specific data to the external entity (<NUM>) in accordance with the access rights.