METHOD AND SYSTEM FOR SHARING DATA

Description

AREA

[0001] This patent application relates to methods and systems for anonymizing data, in particular for the purpose of protecting centrally collected data from access by third parties. BACKGROUND

[0002] Manufacturers of certain computer modules, i.e., software or hardware components, are increasingly interested in their users' usage data, for example, to determine which components are used most frequently. Until now, such data has been sent directly from the component to the manufacturer with the user's consent. Centralized collection of such data for multiple users and different manufacturers has so far been hampered by the fact that merging the data would make it accessible to certain parties for whom it is not intended.

[0003] US 2010 / 0257351 A1 discloses encrypting first data of a first group with first keys and encrypting second data of a second group with second keys. All groups belong to the same "organization," and identifiers are used to assign data to keys. US 2005 / 071632 A1 discloses further prior art. SUMMARY

[0004] The invention disclosed here is based on the object of enabling secure and centralized collection of usage data.

[0005] The invention is defined in the claims.

[0006] Embodiments of the invention relate to a system comprising: a server, a database, and at least one client; wherein one or more keys are stored on the database, which keys are assigned to a respective provider of a respective module that processes data in or on the client; wherein the client is configured to: encrypt data generated by a module in or on the client as first data with a first key assigned to the client, wherein the module is assigned to one of the providers; access the database and read out a second key assigned to the provider and encrypt the data with the second key as second data; and send the first and second data to the server; and wherein the server is configured to: store the first and second data, wherein the first data is assigned to the client, and wherein the second data is assigned to the provider of the module.

[0007] In particular, the server can be configured to look up all data associated with the provider and send it to the provider upon request from one of the providers.

[0008] Advantageously, the client is further configured to send an email address of a user of the module in addition to the first and second data, and the server is configured to also store the first and second data under the email address.

[0009] In a further embodiment, the server is further configured to fully display or fully or partially delete all first and second data stored under the email address upon a request from the module or the user.

[0010] This request preferably contains the user's email address.

[0011] Advantageously, the server is further configured to delete all data associated with the client upon request from a module or user.

[0012] In further embodiments, the server is further configured to transmit an identifier to the client before or after storing the first and second data, wherein the request contains this identifier.

[0013] Embodiments of the invention further relate to a method comprising: encrypting, by a client, data generated by a module in or on the client with a first key associated with the client as first data, wherein the module is associated with one of a plurality of providers; accessing, by the client, a database on which one or more keys associated with the providers are stored and encrypting the data with the second key as second data; sending, by the client, the first and second data to a server; and storing, by the server, the first and second data, wherein the first data is associated with the client and wherein the second data is associated with the provider of this module.

[0014] In particular, the method further comprises looking up, by the server, at a request from one of the providers, all second data associated with the provider and sending the second data to the provider.

[0015] Embodiments of the invention further include that the sending of the first and second data by the client further comprises sending an email address of a user of the module, wherein the storing of the first and second data by the server further comprises storing the first and second data at the email address.

[0016] Advantageously, the method further comprises deleting, by the server upon a request from a module or user, all first and second data associated with the client.

[0017] In particular, the request contains the user’s email address.

[0018] In certain embodiments, the method further comprises deleting, by the server upon a request from the module or the user, all first and second data stored at the email address.

[0019] According to a further embodiment, the server transmits an identifier to the client before or after storing the first and second data, wherein the second data is assigned to the provider of the module.

[0020] Embodiments of the invention further relate to a computer-readable medium having instructions stored thereon that, when executed by a client and / or a server, perform one of the foregoing methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 shows a system according to an embodiment of the invention. Figure 2 shows a method according to an embodiment of the invention. DETAILED DESCRIPTION

[0022] The invention comprises a system consisting of a server, a client, and a database. The server and client are preferably separate computers, including notebooks, PCs, and mobile phones. Alternatively, the server and / or client can also be implemented as software; the term "server-client architecture" encompasses software programs that communicate with each other. If the server and / or client are implemented as software, they can run on the same device and communicate, for example, via one or more common interfaces. If the server and client are implemented as separate devices, they communicate, for example, via a network connection. Multiple clients can be provided. The database can be installed on the same device as the server and / or the client. Alternatively, the database can be located on a separate device.The database is configured to communicate with the client(s), for example via a shared local interface or a network connection.

[0023] The following describes a single client as an example. However, the invention also encompasses embodiments with any number of clients.

[0024] One or more modules are installed on the client according to the invention. The modules can include software components and / or hardware components. Examples of software components include applications, driver programs, operating systems, and virtual machines. Examples of hardware components include microcontrollers, graphics cards, and processors in a client, as well as hardware units with an integrated processor connected to a client.

[0025] The modules can process data independently of one another. Alternatively, a module can be a component of one or more other modules in or on the client. In particular, different modules can come from different manufacturers, also referred to here as providers. A module that is a component of another module can also come from a different provider than the module of which it is a component. A module can be a component of another module, for example, by being made available in or on the other module. Alternatively, such a component can also be firmly integrated into the other module, for example as compiled native code or as bytecode.

[0026] Modules on the client collect and generate data. This data includes, for example, usage data, also referred to here as application data. In particular, the data can indicate that the module in question has been used, for example by the user or by another instance, such as another module. The data can also contain information about when, by whom, or at which geographical location the module was used, which function of the module was called, how long its application lasted, which module was used previously, which manufacturer the module came from, and the like. The data can be created completely automatically or through explicit interaction with a user; for example, the data can contain a user comment on the use of a module.To enter and edit such comments, the invention may include an app that provides the user with a graphical interface for entering, encrypting, and sending their comments. Such an app could be provided separately by providers; alternatively, one app could be used to submit comments for multiple providers or their modules.

[0027] The client is also configured to encrypt the data collected or generated by a module. For this purpose, the client is configured to load a key from the database.

[0028] In the following, a distinction is made between provider keys and client keys. However, embodiments of the invention also include the possibility of assigning keys not to a client, but to a user. In this way, a user can access their data on the server independently of the particular client they are using.

[0029] The database contains one or more keys, each assigned to a provider, which can be looked up using the respective provider. This can be implemented, for example, using unique identifiers for the providers; by specifying an identifier, the corresponding key can be read from the database. The invention preferably uses asymmetric encryption; the keys contained in the database are then public keys, and the corresponding private keys are held by the respective provider to whom a public key is assigned. Alternatively, the invention can also be implemented using symmetric keys. In this case, both looking up keys in the database and looking up first and second data on the server may require the specification of a password.Such a password can be set, for example, by a login process of the client or user or the provider in the database.

[0030] After receiving the key, the client uses it to encrypt the data and send the encrypted data to the server. The server is configured to assign the encrypted data to the provider and the module that generated the underlying data on the client. This can be implemented, for example, using a table that maps the encrypted data to the provider, for example, using the provider identifier explained above. The server can either receive this identifier from the client when sending the encrypted data or determine it from a name given to the encrypted data. The same identifiers as in the database above can be used; alternatively, the server can use its own identifiers for the providers. In any case, these identifiers are known to the respective providers and can be set on the server using a provider registration process.Providers can contact the server, for example via an interface such as HTTP or via an app, and, by specifying their identifier, can read all encrypted data from the server that is associated with that identifier.

[0031] In implementations with asymmetric encryption, the provider possesses the private key and can decrypt all encrypted data read from the server. Since the provider does not have any additional identifiers, it cannot read the encrypted data generated by modules from other providers. Even if it does know these identifiers, it can read the encrypted data of other modules, but is unable to decrypt it due to the lack of the matching private key.

[0032] In embodiments with symmetric encryption, the provider, if he does not already have the key, can read it from the database using its identifier, for example in conjunction with an authentication measure, in particular specifying a password.

[0033] The data generated on the client by modules can, alternatively or in addition to the encryption and sending described above, be encrypted using a key assigned to the client and not to the provider, and then also sent to the server. Unlike encryption using provider keys, the client's key is not retrieved from the database but is available locally to the client. The client uses this key to encrypt the generated data and sends it to the server, where it is stored. The server stores the encrypted data in conjunction with an identifier assigned to the client. This identifier can be determined either by the server based on the client's origin—for example, its IP address or hostname—or by an identifier also sent by the client. The identifier can also be an email address.Another alternative is for the client or user not to specify the identifier, but rather to receive it upon first access to the server. The identifier can then be used for further access to the stored data, for example, to delete the data or to store additional data for that client or user. These measures allow the client to retrieve the data it has sent from the server, for example, by specifying the specified identifier. This way, the client can retrieve all encrypted data it has sent.

[0034] Advantageously, data generated by modules is always encrypted and sent with both a key from the respective provider and a key from the client, so that the server receives first and second data, each encrypted with a separate key. This allows both providers and clients to access the server's data that concerns them, while other parties are excluded from such access. It also ensures that the content of the first and second data is identical, apart from their encryption.

[0035] If the data is generated in the client based on a user command, the invention offers the advantage that the data is encrypted, sent, and stored on the server once for the client and once for the respective provider(s), without the user having to worry about the keys, the encryption processes, and the sending. Thus, the invention enables data to be stored on the server with a single user action and made accessible to both the provider and the client, but not to other providers, other clients, or other parties. In particular, the server itself is excluded from decryption because it does not have access to the keys.

[0036] When modules running in or on clients repeatedly store encrypted data with corresponding provider identifiers on the server, a database is created on the server that can be retrieved by the corresponding providers and used to analyze the use of their modules. To retrieve the data, providers can simply specify their provider identifier and then receive all data stored under this identifier. Clients or their users can also look up the data assigned to them by specifying their identifier. Both providers, clients, and users can also delete data on the server. For this purpose, the identifier is also specified, along with a request to delete it; this can be done, for example, in the form of a database operation or using another predefined command.Such a deletion operation may optionally require the specification of a password, for example, a password defined between the deleting party and the server through a login process. A client or user is thus given the option of deleting all data stored under the respective identifier. Since this data was stored in parallel under provider identifiers, it is not automatically subject to deletion. However, it can be provided that when the first and second data are stored, the second data is also provided with the identifier of the first data. In this embodiment, the deletion operation affects all first and second data that can be traced back to the respective client or user. In this way, the invention enables users optimal control over their data.

[0037] Any provider can view all data stored on the server for that provider's modules by providing their identifier. This data can be used to analyze the use of these modules. For example, user comments on individual modules can be used to create a qualitative assessment of the software components. If the stored data was stored automatically and contains, for example, usage times and technical information about clients, statistics on the use of individual modules can be compiled. Such statistics can indicate, for example, which functions of a module were frequently accessed, how long the functions were used, etc. This allows providers to adapt their products and, for example, remove rarely used functions and prioritize the development of frequently used functions.

[0038] Optionally, some of the data can be present on the server in unencrypted form. This data can, for example, contain information about existing versions of data, in particular the specific version numbers and times of publication of respective data on the server. In such an embodiment, the specific data identified by the version numbers remains encrypted. Unencrypted version data can be used to generate a graphical user interface, for example on the server, and as a response to a corresponding request, for example via HTTP. Such a user interface can access the version data to display a representation of the times and version numbers of respective changes to the (encrypted) data and make this data available via a link.If a user selects such a displayed version in the user interface, the data of this version can be decrypted and displayed using one of the measures described above.

[0039] As can be seen from the embodiments described so far, a client or user can access data stored on the server by specifying an identifier assigned to it. As already explained, this identifier is associated with a key that is used to make the data available to the respective user. Users can transfer the right to access their data to other users by communicating their identifier. This can be done, for example, via email or other means. Alternatively, a user can transfer their own key to others to enable them to request their data from the server.

[0040] Figure 1shows a system 100 according to the invention. The system 100 comprises a server 110, a client 120 and a database 130.

[0041] The client 120 contains one or more modules 140, represented here as modules 1 to i. Each of these modules 140 can generate or capture data 150. This data should be made accessible, for example, to providers of the respective module.

[0042] In the embodiment shown, the data 150 of a module, here the data of module i, are each encrypted once to obtain encrypted data 160 and encrypted data 170. The encrypted data 160 is generated using a key of the client 120; the key is stored locally on the client, for example. This key is used for each of the modules on this client. It is, for example, a public key of the client. Alternatively, the key is not assigned to the client but to a user logged in to the client, and is used for each of the modules that run under a user account of this user or that are accessed from this user account.

[0043] The encrypted data 170 is generated using a key associated with a provider of this module. However, in the embodiment shown here, the key is retrieved from a database 130. However, the key may alternatively be provided in and / or by the module and need not be looked up.

[0044] The database 130 contains a list of keys 180 assigned to respective providers 1 to n. By specifying an identifier for a provider, the relevant key can be read. The client can, for example, query this identifier from the module. Alternatively, the client can pass the name of the installed module to the database; in such an embodiment, the database can map module names to provider identifiers, and these, in turn, to the respective keys. The keys in the database are, in particular, public keys, so that authentication of the client with the database is not required.

[0045] The encrypted data 160 and 170 are sent from the client to the server 110. The encrypted data 160 is stored on the server in conjunction with an identifier of the client so that it can be retrieved under this identifier. The identifier can, for example, be sent by the client itself with the encrypted data 160, or can be determined by the server based on an address or name of the client or user. The encrypted data 170 is stored on the server in conjunction with an identifier of the respective provider so that it can be retrieved under this identifier. The identifier is sent by the client with the encrypted data 170. Optionally, the server can additionally store the encrypted data 170 with the identifier of the client or user.In this embodiment, a provider can read all data from the server that concerns both the provider and this client or user by specifying its identifier and the identifier of the client or user. If only the provider's identifier is stored with the encrypted data 170, the provider can read all data from the server 110 that concerns it, and can thus view all data from all its modules for all clients or users.

[0046] The invention thus makes it possible to make module data centrally accessible to their providers and also to the client or user. Other parties, in particular other providers and clients, and also the server itself, are excluded from such access because they do not have the corresponding keys. Accessing data on the server is particularly convenient for clients and providers because only specifying an identifier for the client or provider is required to retrieve all of the client's or provider's data. The parallel encryption with respective keys in the client remains invisible to the client's users; however, due to this parallel encryption, they can easily view their data on the server. The invention allows users convenient control of the data made available to the providers and enables the providers to track the use of their modules.

[0047] Figure 2 shows a computer-implemented method 200 according to an embodiment of the invention. The method is suitable for execution on a client (steps 210 to 240) and on a server (step 250).

[0048] In step 210, a module generates data in or on a client. For example, this data may be data automatically generated by the module that reflects certain uses of the module, such as certain software functions of the module used, coupled with their temporal use. Alternatively, the generation of the data may be explicitly triggered by a user of the module, for example, by selecting a function of the module for releasing information from the user or the module to a provider of the module, or by invoking a dialog for entering comments.

[0049] In step 220, the data is encrypted with a client key. This can be a public key of the client or a user. Alternatively, it can be a symmetric key of the client or the user. Step 220 is optional; the invention also functions without encrypting data with such a key. However, this step, in combination with the subsequent steps, offers the particular advantage that both users and providers can view the data concerning them without requiring any additional effort on the part of the user or provider.

[0050] In step 230, the data is encrypted with a provider's key. Step 230 may involve looking up this key in a database; in this case, the client can specify an identifier of the module, such as its name, or an identifier of the provider, and obtains the corresponding provider's key from the database. This is preferably a public key. Alternatively, an implementation with a symmetric key is possible. The data encrypted in step 230 is identical to the data encrypted in step 220; only the encryption methods differ.

[0051] In step 240, both the data encrypted in step 220 and step 230 are sent to a server. This can be done in separate operations, for example, as automatically sent emails or via separate database access. Alternative transmission options include SMS, KNX, and HTTP.

[0052] In step 250, the transmitted encrypted data is stored on the server. This step can already be implemented as part of step 240, for example, if step 240 is implemented as a database access that stores the encrypted data directly in a server database. The encrypted data is stored with an identifier of the client or provider so that it can be retrieved under this identifier. Instead of an identifier corresponding to the client, a user name, for example, a user account name under which the module was accessed at the time of encryption, can be used. It is also possible to use both such a user identifier and a client identifier to store the data encrypted in step 220 on the server.Furthermore, embodiments of the invention also include storing the data encrypted in step 230 not only with a provider identifier but also with an identifier of the user and / or client. Embodiments with multiple identifiers not only enable convenient access for users and providers to the data concerning them, but also provide an overview of which functions the user uses on which devices. This allows providers to comprehensively analyze the use of their modules. At the same time, access to the data by other providers, clients, users, or other parties is prevented, even though all data is stored centrally on a server and the data of other providers, clients, etc. is also stored there. Furthermore, apart from the easily determined identifiers, no authentication is required to access the server. Data security is ensured by the different keys.

[0053] Embodiments of the invention also include electronic media having instructions stored thereon that, when executed by one or more processors, perform any of the methods described herein.

Claims

1. A system (100) comprising: a server (110), a database (130) and at least one client (120); wherein one or more public keys (180) are stored on the database (130), which are assigned to this provider by means of a respective identifier of a provider of a module (140), wherein the module (140) processes data in or at the client (120); wherein the client (120) is configured: - to encrypt data (150), which are generated or captured by a module (140) in or at the client (120) for a user, with a public key of the user (120) as first data (160), wherein the module (140) is assigned to the provider of this module (140) by means of an identifier; - to access the database (130) and to read out one of the keys of the providers by means of the identifier of the provider of the module (140) and to encrypt the data (150) with this key as second data (170); and - to send the first and second data (160, 170) as well as the identifier of the provider of the module and an identifier of the user to the server (110); and wherein the server (110) is configured: - to store the first and second data (160, 170), wherein the first data (160) are assigned to the user of the client (120) by means of the identifier of the user, and wherein the second data (170) are assigned to this provider by means of the identifier of the provider of the module (140).

2. The system (100) according to claim 1, wherein the server (110) is further configured, in response to a request of one of the providers, to look up all data which are assigned to the provider and to send them to the provider.

3. The system (100) according to claim 2, wherein the client (120) is further configured, in addition to the first and second data (160, 170), to send an email address of a user of the module (140), and wherein the server (110) is configured to store the first and second data (160, 170) also under the email address.

4. The system (100) according to claim 3, wherein the server (110) is further configured, in response to a request of the module (140) or of the user, to display all the first and second data which are stored under the email address completely or to delete them in whole or in part.

5. The system (100) according to claim 4, wherein the request contains the email address of the user.

6. The system (100) according to any one of claims 1 to 3, wherein the server (110) is further configured, in response to a request of a module (140) or of a user, to delete all the data which are assigned to the client (120).

7. The system (100) according to claim 6, wherein the server (110) is further configured, before or after storing the first and second data (160, 170), to transmit an identifier to the client (120), and wherein the request contains this identifier.

8. A method (200) comprising: encrypting (220), by a client, data, which are generated (210) by a module in or at the client for a user, with a public key of the client as first data, wherein the module is assigned to a provider of the module by means of an identifier; accessing, by the client, a database on which one or more public keys are stored, and reading out one of the keys of the providers by means of the identifier of the provider of the module and encrypting (230) the data with the key as second data; sending (240), by the client, the first and second data as well as the identifier of the provider and an identifier of the user to a server; and storing (250), by the server, the first and second data, wherein the first data are assigned to the user of the client by means of the identifier of the user, and wherein the second data are assigned to this provider by means of the identifier of the provider of the module.

9. The method (200) according to claim 8, further comprising looking up, by the server in response to a request of one of the providers, all the second data which are assigned to the provider and sending the second data to the provider.

10. The method (200) according to claim 9, wherein the sending of the first and second data by the client further comprises sending an email address of a user of the software component, and wherein the storing of the first and second data by the server further comprises storing the first and second data under the email address.

11. The method (200) according to claim 10, further comprising deleting, by the server in response to a request of a module or of a user, all the first and second data which are assigned to the client.

12. The method (200) according to claim 11, wherein the request contains the email address of the user.

13. The method (200) according to any one of claims 10 to 12, further comprising deleting, by the server in response to a request of the module or of the user, all the first and second data which are stored under the email address.

14. The method (200) according to any one of claims 8 to 13, wherein the server transmits an identifier to the client before or after storing the first and second data, and wherein the second data are assigned to the provider of the module.

15. A computer-readable medium having stored thereon instructions which, when executed, perform the method according to any one of claims 8 to 14.