Device and method for secure storage of media containing personal data and for erasure of stored personal data - Patents.com

Abstract

To provide a device and a method for safely storing media containing personal data and erasing the stored personal data.SOLUTION: When a file to be stored is supplied, a device 410 supplies a file token FileID.m to a one-way function interface 490 that received a private identifier PrivID of a person to obtain a temporary unregistered identifier AnonID.m. The device that has acquired the AnonID.m extracts a personal data item from the supplied file to store them in a first memory 421 along with a corresponding locator Loc.m.n and an item specific unregistered identifier AnonID.m.n. The first memory may subsequently include a triplet of the personal data item, the locator, and the identifier. In parallel, the device stores an unregistered version of the file in a second memory 422.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present disclosure relates to techniques for securely storing and playing media containing personal data, and for securely erasing such personal data on demand. [Background technology]

[0002] The present invention seeks to propose a technique that addresses the storage of media containing a mixture of personal data and other data, and in particular meets identity privacy safeguards as enshrined in legal instruments such as Regulation (EU) 2016 / 679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation (GDPR)), the China Cybersecurity Law, the California Consumer Privacy Act, and other US federal and state laws. Under the GDPR, each person shall have the right to request at any time the complete erasure of his or her stored personal data. This is called the data subject's right to erasure or "right to be forgotten". In existing techniques, however, the right to be forgotten may not be compatible with data version control, an almost essential tool for managing many data sets over time.

[0003] Particular difficulties arise in connection with the storage of non-discrete media such as text, image and video data. In one scenario, a person (data subject) who has previously consented to a company (data recipient) storing a video in which she appears in only a small portion of the frames, contacts the data recipient and requests that it erase her personal data. While the data recipient is in principle entitled to keep all the other frames in which she appears, storing personal identifiers for each of the video frames would be highly problematic from a data protection point of view. This is because storing identified personal data, with its associated higher privacy risk, requires technical configurations that ensure a higher security level that may become unmanageable in practice. To satisfy this person's request for erasure, the data recipient therefore has the option to indiscriminately erase the complete video sequence. This would represent a severe and unjustified loss of useful data. Summary of the Invention

[0004] One objective of the present disclosure is to make available a method and a device for storing a file containing personal data, such that a request of a data subject for the erasure of her personal data can be fulfilled without unnecessarily erasing other data contained in the file. Another objective is to ensure that the file with personal data is securely stored in a form that still lends itself to efficient management and processing until such a request for erasure is made. A particular secure aspect addressed by the present disclosure is to prevent a person who has gained unauthorized access to the stored personal data from identifying the data subject (person) to which it belongs. A particular efficient aspect is to enable version control. Another objective of the present disclosure is to make available a method and a device for efficiently recovering a file with personal data, securely stored using the proposed technique.

[0005] These and other aspects are realised according to the invention as set forth in the independent claims. The dependent claims relate to preferred embodiments of the invention.

[0006] In a first aspect of the invention, there is provided a method for storing a file containing personal data, the method comprising obtaining a temporary anonymous identifier (AnonID.m) of a person, the temporary anonymous identifier (AnonID.m) being dependent on a token (FileID.m) of the file, extracting from the file personal data items associated with the person, generating for each personal data item a locator (Loc.mn) that enables the personal data item to be restored to the file and an item-specific anonymous identifier (AnonID.mn) for the person, the item-specific anonymous identifier being generated by applying a predetermined one-way function to a combination of the temporary anonymous identifier (AnonID.m) and an identifier (n) of the personal data item, storing each personal data item together with its locator and item-specific anonymous identifier in a first memory, and storing an anonymized version of the file without the personal data items in a second memory.

[0007] Since the item-specific anonymous identifier is generated using a one-way function, a person who gains unauthorized access to the first memory cannot easily attribute the stored personal data items to that person. Also, an unauthorized person has no way to collect all of the personal data items associated with the same person. This may be considered as a form of anonymization of the file. Since the file is anonymized before being stored in the second memory, this memory may be subject to less stringent security requirements than the first memory. Since the person is identified by a temporary anonymous identifier, the recipient of the data can execute a method for storing the file without requiring the person to share her own non-anonymized identifier. Finally, since each personal data item is stored with an item-specific anonymous identifier, comprehensive and highly accurate erasure of all items related to a particular person is possible on request.

[0008] In a second aspect, a method is provided for erasing personal data associated with a person from a first memory that stores personal data items together with corresponding locators (Loc.mn) and item-specific anonymous identifiers (AnonID.mn) of the person associated with those personal data items. The method includes obtaining a private identifier (PrivID) for the person, obtaining all tokens (FileID.m) of files from which the personal data items may be extracted, and for each one of the files, obtaining all identifiers (n) of personal data items associated with the person and which may be extracted from the file, generating a temporary anonymous identifier (AnonID.m) for the person by applying a predetermined one-way function to a combination of the obtained private identifier (PrivID) and the obtained file token (FileID.m), generating, for each of the person's generated temporary anonymous identifiers (AnonID.m), an item-specific anonymous identifier (AnonID.mn) for the person by applying a predetermined one-way function to a combination of the temporary anonymous identifier (AnonID.m) and the obtained identifiers (n) of the personal data items, and erasing all personal data items that match any of the person's generated item-specific anonymous identifiers (AnonID.mn) from the first memory.

[0009] The fact that each personal data item is stored with an anonymous identifier unique to the item allows for a comprehensive and highly accurate locating and erasing of all items related to a particular person. This erasure method according to the second aspect does not require modifying or erasing any anonymized version of those files from which the personal data items have been extracted. This leaves the recipient of the data free to decide how and to what extent the files are restored after erasure of the person's personal data items. The recipient of the data may decide to reconstruct and use a subset of the files after erasure according to a degree of granularity that suits the type of data in question and the intended use case. To mention a few examples, for example, after erasure of a person's face from an image, a cropped version of this image may be kept for further use. After erasure of a person's face from a particular frame in a video sequence, all of the remaining video frames or each of a consecutive video subsequence of at least N remaining frames may be kept. After erasure of a person's name from a row of a database, other rows of the database may be kept. After the person's authentication information has been erased from the document, other sections of the document may be retained. This erasure method does not in itself entail any significant technical limitations in recovering the file. Finally, to verify that execution of the method has completely erased all of the personal data associated with the person, it is sufficient to prove that none of the generated item-specific anonymous identifiers match any of those personal data items that remain stored in the first memory.

[0010] In a third aspect, a method is provided for restoring personal data to a file, the method comprising retrieving personal data items extracted from the file and corresponding locators from a first memory storing the personal data items extracted from the file together with corresponding locators (Loc.mn) and item-specific anonymous identifiers (AnonID.mn) of the person associated with the personal data items, retrieving an anonymized version of the file that does not include the personal data items from a second memory, and restoring the personal data items to the anonymized version according to their corresponding locators.

[0011] Since these personal data items are stored with their corresponding locators and item-specific anonymous identifiers, these personal data items can be correctly restored to the anonymized version of the file without endangering the privacy of those persons associated therewith. This restoration method can be performed by the recipient of the data without requiring her to share her own non-anonymized identifier. Moreover, since this restoration method uses the anonymized version of the file as input, the method will be performed reliably even if some or all of these personal data are erased from the first memory, for example upon request by the associated person. In that case, more precisely, the method may be performed reliably and end up returning a usable file version (consistent, readable, editable, etc.) that does not have the corrupting effect of the parts from which the erased personal data items were erased.

[0012] Used together, these three aspects of the invention form a data storage ecosystem that is privacy by design.

[0013] There is further provided a device comprising a processing circuit communicatively connected to the first and second memories and arranged to perform the method of the first, second or third aspect. The invention further relates to a computer or, in particular, a computer program comprising instructions for causing said device to perform the method of the first, second or third aspect. This computer program may be stored on or distributed by a data carrier. As used herein, a "data carrier" may be a transitory data carrier, such as a modulated electromagnetic or light wave, or a non-transitory data carrier. Non-transitory data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical or solid-state type. Still within the scope of "data carrier", such memories may be fixedly mounted or may be portable.

[0014] In this disclosure, "file" is used broadly to refer to any data set that can be stored and / or processed independently in a file system, including in a database, file archive, or other data storage context. In the interest of avoiding unnecessarily deleting data in response to a request for erasure, the recipient of the data will typically want to treat the media containing the personal data in as small chunks as practical, that is, typically by file. The present invention is consistent with this requirement insofar as it allows not only files, but even subsets of files, to be restored after a person's personal data has been erased. Referring again to the examples listed above, a file may correspond, for example, to an image, a video sequence, a database, or a document.

[0015] This disclosure seeks to use the terms "personal data," "data subject" (i.e., a natural person), "data recipient" (i.e., a person to whom personal data is at least disclosed), and "anonymization" consistently with their meanings under the GDPR. As a result, a "personal data item" is an item of "personal data," e.g., an area of ​​an image containing a person's face, a video frame showing the license plate of a personally owned vehicle, a row in a database containing a person's name, or a section of a document containing a person's authentication information.

[0016] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the art, unless expressly defined herein. Any reference to "a / an / the element, device, component, means, step, etc." is openly interpreted as referring to at least one example of that element, device, component, means, step, etc., unless expressly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless expressly stated.

[0017] Aspects and embodiments are described below, by way of example only, and with reference to the accompanying drawings. [Brief description of the drawings]

[0018] [Figure 1] 1 is a flow chart of a method for storing files containing personal data. [Diagram 2] 1 is a flow chart of a method for erasing personal data associated with a person. [Diagram 3] 4 is a flow chart of a method for restoring personal data to an archived file. [Figure 4] 2 is a functional block diagram of a device for performing at least the method shown in FIG. 1. [Diagram 5] A key derivation structure is shown in which each arrow represents a one-way mapping. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] Aspects of the present disclosure will be described in more detail below with reference to the accompanying drawings, which show specific embodiments of the present invention. These aspects may, however, be embodied in many different forms and should not be construed as limiting. Rather, these embodiments are provided for illustrative purposes so that this disclosure will be thorough and complete, and will fully convey the full scope of the aspects of the present invention to those skilled in the art. Like reference numerals refer to like elements throughout this specification. Save files containing personal data

[0020] FIG. 1 shows a method 100 for storing a file containing personal data. Method 100 may be performed by or on behalf of a data recipient, a natural or legal person, who has received or generated the file and has further obtained a person's consent to store her personal data in the file. This consent may cover not only the personal data in the file to be stored, but also additional files as well. Method 100 is conceived to handle the scenario where the person revokes her consent. This revocation may be equivalent to a request for the complete erasure of the person's personal data.

[0021] In an initial, optional step 110, a one-way function interface (see element 490 of FIG. 4) configured with a predefined one-way function is made available to the person to enable her to generate a temporary anonymous identifier (AnonID.m) based on a combination of a private identifier (PrivID) and a token (FileID.m) for the file to be stored. The one-way function interface is available as locally installed software or an online interface that allows the person to generate a temporary anonymous identifier (AnonID.m) without sharing the private identifier (PrivID) with the recipient of the data. Sharing the private identifier (PrivID) may only be necessary if the person wishes her personal data to be erased, as described below with reference to FIG. 2.

[0022] As a one-way function, implementing the method 100 may use a hash function, in particular a cryptographic hash function that offers a level of security that is considered adequate, taking into account the sensitivity of the personal data stored. Two examples of these are SHA-256 and SHA3-512. The one-way function is predefined (e.g. it is regenerative) so that the temporary anonymous identifier (AnonID.m) can be regenerated when a request for deletion is performed.

[0023] The one-way function interface made available to the person in step 110 may further enable the person to generate a private identifier (PrivID) based on the personal identifier (ID). The personal identifier (ID) may be a civilian or official identifier, such as an identification number, a social security number, a passport number, a name and date of birth combination, etc., that the person can reconstruct without actively archiving it. If this advantage is not considered important, the person may provide the one-way function interface with any bit pattern as the private identifier (PrivID), so long as the person is confident that she will be able to reconstruct the bit pattern in connection with a future request for erasure, and that the bit pattern will be reasonably difficult for a third party to reconstruct. The mapping from personal identifier (ID) to private identifier (PrivID) may be the same one-way function used to map the private identifier (PrivID) to the temporary anonymous identifier (AnonID.m). Alternatively, a different one-way function may be used. Either way, unless the person has securely stored the private identifier (PrivID), she should be sure that she has future access to the same one-way function or functions and can still direct the deletion of her personal data.

[0024] The token (FileID.m) of the file that is stored is arbitrary, as long as it can be reconstructed based on information about the file stored in the second memory. The token (FileID.m) may be a running sequence number. To allow for a retroactive inventory (e.g., when erasure is requested), the token is preferably a discrete quantity. Exemplary tokens include file creation date, media recording date, file size (of an anonymized version of the file), size bin (e.g., size in MB in ranges [0, 10), [10, 20), [20, 30), etc.) that the file size belongs to a set of predefined size bins, a fingerprint / digest of the file contents, a file name that identifies the file in the file system, etc. To accomplish erasure of personal data, the data recipient may retroactively obtain the complete set of values ​​of these tokens by sending a query to the file system for all files stored in the second memory. If the file creation date is used as a token, the complete set of values ​​over which the file is stored corresponds to the data range that can be retrieved from the worklog, for example in digital or non-digital format. While not essential to the invention, the use of a unique token for each of the files (i.e., the identifier) ​​has some advantages, since it ensures that there are no mismatches between the item-specific anonymous identifiers (AnonID.mn). Alternatively, the same token (FileID.m) may be used for a cluster of files stored at the same time or close to each other, avoiding the need to store sensitive, temporary anonymous identifiers (AnonID.m). However, it is not wise to use a constant token for all of the files, since this would imply that all of the item-specific anonymous identifiers belong to a common sequence, making efficient documentation of the total amount of stored personal data items impossible. Such documentation would be of great help when complete erasure is required.

[0025] If the token (FileID.m) of the file being saved is unknown to the person, e.g., other than today's date, that value may be shared with the person, or it may be provided directly to a one-way function interface in a second optional step 112. A temporary anonymous identifier (AnonID.m) may then be generated correctly based on the combination of the private identifier (PrivID) and the token (FileID.m). Method 100 may or may not include step 110 or step 112, or a combination of those steps.

[0026] In a next step 114 of method 100, a temporary anonymous identifier (AnonID.m) is obtained for the person. The temporary anonymous identifier (AnonID.m) varies with the file's token (FileID.m). The preferred way to obtain the temporary anonymous identifier (AnonID.m) is to receive it from the person. In this way, the person does not need to share a private or personal identifier with the recipient of the data performing method 100.

[0027] In step 116, personal data items associated with that person are extracted.

[0028] In step 118, for each personal data item extracted in step 116, a locator (Loc.mn) and the person's item-specific anonymous identifier (AnonID.mn) are generated.

[0029] The locator (Loc.mn) allows the personal data item to be restored in a file. Its structure may depend on the type of media the file is associated with. If the personal data item is an area of ​​an image, the locator (Loc.mn) may indicate that area in the image, for example in terms of the coordinates of its bounding box. For video data, a locator allowing recovery of an extracted area in a frame corresponding to the person's face or the license plate of her car may indicate the sequence number of the frame and the image coordinates of the extracted area.

[0030] The person's item-specific anonymous identifier (AnonID.mn) is generated in step 118 by applying a predefined one-way function to the combination of the temporary anonymous identifier (AnonID.m) and the personal data item identifier (n). The one-way function may be the same as the one used to generate the person's temporary anonymous identifier (AnonID.m). Or it may be a different one-way function with similar properties. The personal data item identifier (n) may be a file-specific sequence number. That is, a sequence counter is reset for each new file that is saved, or possibly for each cluster of files that are saved simultaneously, so that each identifier is unique within the file (file cluster). However, personal data items belonging to two different files (file clusters) may have the same identifier. The identifier (n) may also be a global sequence number. Or it may be the complete identifier of the personal data item at the level of the operating system or another relevant namespace. Instead of a numerical counter, one may equally use an alphabetical counter, or a counter that takes on values ​​in any suitable discrete set or space. The counter may be incremented according to predefined enumeration (or increment) rules. You may use TIFF0007606481000001.tif9170.

[0031] In a further development of method 100, where successive versions of a file can each be saved, step 118 is repeated once a new version has been saved, so that the locators of those personal data items are further dependent on the version (or commit) v of the file, i.e., Loc.mnv. This supports the implementation of version control in the second memory.

[0032] See Figure 5. This shows how the identifiers ID, PrivID, AnonID.m, and AnonID.mn are related. Each downward arrow corresponds to the application of a one-way function. The letters on the left side of Figure 5 further indicate which entities have access to the corresponding identifiers. A: The private identifier (ID) remains with the data subject. It does not need to be shared with the recipient of the data. B: The data subject stores the private identifier (PrivID) until consent to storing the personal data is revoked, at which point the data subject shares the private identifier (PrivID) with the data recipient to enable the data recipient to erase her personal data according to method 200. C: When a data subject shares one of the temporary anonymous identifiers (AnonID.m) with a data recipient, this is equivalent to consenting to the storage of the file with her personal data. The data recipient uses this identifier and performs the storage of the file according to method 100. D: The recipient of the data stores item-specific anonymous identifiers (AnonID.mn) in the first memory together with the extracted personal data items, which identifiers cannot be erased until the personal data items are deleted, to enable the recipient of the data to effect the requested erasure of those personal data items in accordance with method 200.

[0033] Returning to Figure 1, the method 100 further comprises a step 120, where each of the personal data items is stored in a first memory (see element 421 in Figure 4) together with a locator (Loc.mn or Loc.mnv) and an anonymous identifier (AnonID.mn) specific to the item. For this storage operation, a relational database may be used. This may be visualized as a table with the following general appearance: TIFF0007606481000002.tif36170

[0034] In an optional step 122, a counter entry for the person is stored, for example in the first memory or any other. The counter entry allows verification of the comprehensiveness of the list of all personal data items associated with the person. To this end, the counter entry may indicate: - the total number of personal data items, in which case the erasure method applies pre-agreed inventory and initiation rules. the first and last personal data items (for example by their unique anonymous identifiers, AnonID.mn, or by their locators, Loc.mn). In this case the deletion method applies the enumeration rule. - a complete list of personal data items, in which case the erasure method can be independent; or A list of all locations of personal data items or their locations. In this case, the erasure method can be independent. Preferably, one counter entry is stored for each file containing personal data of that person or for each new file token (FileID.m) used.

[0035] In some embodiments, the counter entry includes the person's recognizable anonymous identifier (RecAnonID.m), which is generated by applying a one-way function to the temporary anonymous identifier (AnonID.m), as also shown by the dotted arrow in FIG. 5. Because the recognizable anonymous identifier (RecAnonID.m) was generated using a one-way function, it cannot be attributed to the person. The recognizable anonymous identifier (RecAnonID.m) does, however, allow for verification that the correct person's counter entry is being found in connection with fulfilling an erase request. When a counter entry includes a recognizable anonymous identifier (RecAnonID.m), it may have the following structure: TIFF0007606481000003.tif36170This may be understood as follows: the file or files in which the token FileID.1 is used contain exactly N1 personal data items associated with that person. The file or files in which the token FileID.2 is used contain exactly N2 personal data items associated with that person. And so on.

[0036] In a further optional step 124 of the method 100, action is taken to prevent non-volatile storage of the temporary anonymous identifier (AnonID.m). Such protective measures may include erasing the identifier in the runtime memory or overwriting it. Alternatively, a gatekeeper function is provided that refuses to store data having the data type of the temporary anonymous identifier (AnonID.m) in the first and second memories and any available further non-volatile memories. In this way, if a new file is to be saved at a later date, which period is assumed to be too long to keep the identifier in the runtime memory, a new, temporary anonymous identifier (AnonID.(m+1)) needs to be obtained, i.e. step 114 needs to be performed anew.

[0037] At this point, in step 126, it is assessed whether the file to be saved contains personal data associated with any further person. In this case (branch Y), execution returns to the loop and performs steps 114, 116, 118 and 120 (together with optional steps 110 and 112, if included) for the further person. As a result, a temporary anonymous identifier (AnonID'.m) for the further person is obtained. The personal data items associated with the further person are extracted. Then, a locator (Loc.mn) and an item-specific anonymous identifier (AnonID'.mn) of the further person are generated for each of the personal data items. Note that the locators of both these persons may depend on an identifier (n) belonging to the same sequence.

[0038] If there are no further persons to be considered for the file to be stored (branch N from step 126), execution of method 100 continues to optional step 128, where the personal data items in the file are deleted and an anonymized (or truncated) version of the file is obtained. This deletion may be achieved by at least one of deleting (erasing) the personal data items, destroying possible recognizable factors in the personal data items, hiding, editing, masking, replacing or overwriting the personal data items, or by further applying suitable filtering or image processing. Suitable filtering and image processing include those that impart blurring, pixelating, distorting or other effects that tend to render the personal data unidentifiable. Such filtering or image processing is typically of the data destruction type, resulting in a reduction of the information content of the file.

[0039] In a subsequent step 130, an anonymized version of the file without those personal data items is stored in a second memory (see element 422 of FIG. 4). The second memory may be the same memory as the first memory. However, in some embodiments, the second memory is different from the first memory.

[0040] Within step 130, all locators (Loc.mn) of the extracted personal data items may optionally be stored together with the anonymized version of the file. In other words, this option means that the locators (Loc.mn) are stored in both the first and second memory. Access to the spare copy of the locator (Loc.mn) is useful when the file is reconstructed in the situation where some of the personal data it originally contained has been erased, and this erasure was done by expunging all of the rows of Table 1 associated with the requesting person that contain the locators. The spare copy of the locator (Loc.mn) then allows the corresponding locations to be marked as empty / modified / invalidated despite their erasure. Alternatively, the same marking function can be performed when the locators are preserved even though an erasure operation has been performed (i.e., it still leaves the first column of Table 1 intact).

[0041] This completes the saving of the first version of the file.

[0042] Optionally, the method 100 may also extend to the storage of a second file, which also contains personal data associated with the person. The second file may be related to the first one by belonging to the same temporal, spatial or subject context. For example, these files may represent images acquired at successive times, or video sequences following one another. These files may further relate to different sub-areas of the imaged space, which have been partitioned to obtain manageable file sizes, granularity, or the like.

[0043] As a result, in step 132 it is assessed whether the second file is to be saved. In this case (branch Y), execution returns to its loop and starts at step 114. In this execution round, a second temporary anonymous identifier (AnonID.(m+1)) of the person is obtained. The temporary anonymous identifier (AnonID.(m+1)) depends on the token of the second file (FileID.(m+1)). The personal data items associated with the person are extracted from the second file. For each extracted personal data item, a locator (Loc.(m+1).n) and an item-specific anonymous identifier (AnonID.(m+1).n) of the person are generated. Each personal data item is saved in the first memory together with its locator and its item-specific anonymous identifier. Finally, an anonymized version of the second file without the personal data items is saved in the second memory.

[0044] If there are no more files to be saved (branch N from step 132), execution of method 100 may end.

[0045] In an optional additional step 134 of the method 100, an updated anonymized version of the file is stored in the second memory. The updated anonymized version may be stored under version control, i.e. the previous anonymized version is not erased from the second memory. The storage of the updated anonymized version may be performed without necessarily updating the information in the first memory, which remains valid. This fact advantageously makes it possible to limit the circle of staff entrusted with the processing of personal data.

[0046] Optionally, step 134 affects data in both the first and second memory. Assuming that it is desired to increase the brightness in the video sequence, this image processing operation may be applied to all of the frames of the video sequence and all of the cropped images (i.e. the extracted personal data items) in the first memory. The anonymized video sequence is stored as a new version in the versioned second memory. A new locator (Loc.mn2) is generated for the new version (v=2), stored in a new row in the data structure of the first memory. Each new row contains the modified (lightened) cropped images, but the AnonID.mn is the same as for the first version. This is possible without compromising the protection of the person's privacy. Erase personal data associated with a person

[0047] 2 illustrates, in flow chart form, a method 200 for erasing personal data associated with a person from a first memory. The method 200 begins when the memory stores personal data items along with corresponding locators (Loc.mn) and item-specific anonymous identifiers (AnonID.mn) of the person associated with those personal data items. This content may have been loaded into the memory as a result of executing the method 100 for storing files containing personal data described above.

[0048] Method 200 may be performed, for example, by or on behalf of a data recipient, a natural or legal person, who has previously received or created one or more files and has obtained that person's consent to store her personal data contained in those files. Method 200 for erasing personal data associated with that person may be performed when that person requests to be "forgotten" (have her personal data erased) or, equivalently, when that person revokes consent previously given.

[0049] In a first step 210 of method 200, the person's private identifier (PrivID) is obtained. Because the recipient of the data will not receive any private identifier (PrivID) from the person during normal execution of method 100 for storing the file, and such sharing would not improve the person's privacy, step 210 typically entails receiving the private identifier (PrivID) from the person or retrieving the private identifier (PrivID) from a shared memory to which the person has granted read access to the recipient of the data.

[0050] In a second step 212, all tokens (FileID.m) of files from which those personal data items can be extracted are obtained. In this step 212, the recipient of the data may regenerate the tokens (FileID.m) according to the rules and / or documentation regarding the storage of the file or files in which the personal data was included. Alternatively, the tokens (FileID.m) are received or fetched from memory.

[0051] In principle, the person could keep her own register of the token (FileID.m) that she shares with the recipient of the data in relation to the request for erasure. This would allow the person to limit her request to partial erasure of personal data contained in files recorded on a particular date, for example. If the recipient of the data is a professional entity, however, a more convenient option may be to store to the recipient of the data enough information to enable it to reproduce the token (FileID.m) in its entirety, without any other input from the person, other than the private identifier (PrivID). The storage of this information should make the storage of private data at least reliable and / or long-lasting, whereas if the information is lost, there is no convenient way to perform knowledge-based selective erasure of private data related to a particular person. A more attractive option that can be implemented when the token (FileID.m) is based on file names, original file sizes, creation dates, or other file attributes, is to send a query to the recipient of the data to a second memory that stores anonymized versions of their files from which their personal data items have been extracted. Then, in sub-step 212.1, the query may include an ls or dir command issued to the file system of the second memory, which will be successful so long as the second memory stores the relevant file. Since the token resulting from the output of the query is matched against the item-specific anonymous identifier (AnonID.mn) generated in the following step 224, it is of very little concern whether the query to the second memory returns additional file attributes not related to the person as a by-product.

[0052] In a next step 214, for each of those file tokens (FileID.m), all identifiers (n) of those personal data items that are associated with the person and that can be extracted from the corresponding file or files are obtained. Obtaining those identifiers (n) may involve retrieving them from a memory or other entity, or may be based on a recovery process. The recovery process may be controlled by a private identifier (PrivID) received from the person and may further depend on information stored in a memory held by the recipient of the data.

[0053] For example, the identifiers (n) of those personal data items to be erased may be obtained by performing sub-step 214.1 in which the counter entries for the person are retrieved. The concept of counter entries was introduced above in relation to step 122 of the method 100 for storing with an exemplary data structure optionally including a recognizable anonymous identifier (RecAnonID.m). To find the correct counter entry for a file among the multiple stored counter entries, the data recipient regenerates the recognizable anonymous identifier (RecAnonID.m) by first applying a one-way function to the combination of the private identifier (PrivID) and the token of the file (FileID.m), which returns a temporary anonymous identifier (AnonID.m), and subsequently applying the one-way function to the temporary anonymous identifier (AnonID.m). The data recipient matches the output of this operation with the relevant fields (columns) of the multiple stored counter entries. Another field of the matching counter entry may represent the total number of personal data items, the first and last personal data items in the sequence determined by predefined enumeration rules, the complete list of personal data items, or any of the other options listed under step 122. As a result, one counter entry is expected for each temporary anonymous identifier (AnonID.m), so substep 214.1 returns one set of identifiers (n) for each temporary anonymous identifier (AnonID.m).

[0054] To indicate this, a counter entry is added to the identifier of the first personal data item that was saved. TIFF0007606481000004.tif8170 and the identifier of the last personal data item TIFF0007606481000005.tif8170, where "first" and "last" refer to the sequence of the list of identifiers, and not necessarily to the time at which those personal data items were stored. In this case, the erasure method 200 uses listing rules that are the same or equal to the corresponding listing rules used in the preservation method 100. Apply this list rule to the identifier of the first personal data item TIFF0007606481000007.tif9170, followed by the identifier of the last personal data item The recipient of the data may regenerate all of the identifiers by applying it recursively to successive outputs until it reaches TIFF0007606481000008.tif8170. The identifier of the last personal data item stored in the counter entry TIFF0007606481000009.tif8170 serves to verify the comprehensiveness of the listed identifiers. In a variation of this reproduction process, the identifier of the first personal data item TIFF0007606481000010.tif8170 may be pre-agreed or pre-specified. Still alternatively, the counter entry indicating the total number of identifiers may be the identifier of the last personal data item stored. It would be beneficial to know TIFF0007606481000011.tif9170.

[0055] In a further step 216, a temporary anonymous identifier (AnonID.m) for the person is generated by applying a predetermined one-way function to the combination of the obtained private identifier (PrivID) and the obtained file token (FileID.m). The one-way function is predetermined in the sense that the one-way function is equal to the one-way function used to generate the temporary anonymous identifier (AnonID.m) when the file or files containing personal data were saved.

[0056] Those skilled in the art will appreciate that steps 214 and 216 can be performed in either order or in parallel. Because the temporary anonymous identifier (AnonID.m) generated in step 216 may be used as an input in sub-step 214.1, performing in parallel may reduce the total number of times the one-way function must be evaluated.

[0057] Then follows step 218 of generating item-specific anonymous identifiers (AnonID.mn) for the person. This proceeds by applying, for each generated temporary anonymous identifier (AnonID.m) for the person, a predefined one-way function to the combination of the temporary anonymous identifier (AnonID.m) and the obtained identifiers (n) of those personal data items. To ensure complete erasure, step 218 should generate the complete collection of those item-specific anonymous identifiers (AnonID.mn) that were used to store the personal data items associated with the person. If the identifiers (n) have been obtained using sub-step 214.1, there is one set of identifiers (n) for each temporary anonymous identifier (AnonID.m). It should then be sufficient to combine the identifiers (n) in one of those sets with the corresponding temporary anonymous identifier (AnonID.m). On the other hand, combining it with a different temporary anonymous identifier (AnonID.m') is unlikely to provide a further item-specific anonymous identifier that matches any of the stored personal data items.

[0058] In step 220 it is assessed whether any further generated temporary anonymous identifiers (AnonID.m) of the person continue to be processed in step 218. If not (branch N), it is assessed in step 222 whether there are any further file tokens (FileID.m) that have been used to store personal data items associated with the person. If such further file tokens (FileID.m) are found to exist (branch Y), steps 214 et seq. are performed again for each further file token (FileID.m).

[0059] Once all of the file tokens (FileID.m) have been processed, the method 200 proceeds to step 224, where all of the personal data items that match any of the person's generated item-specific anonymous identifiers (AnonID.mn) are erased from the first memory. This erasure may be for the personal data items only, or the corresponding locators and / or item-specific anonymous identifiers may be erased altogether. The latter option corresponds to completely erasing the rows of the data structure shown in Table 1 above. In case it is desired to find the parts of the file from which those personal data items were extracted (e.g., for marking purposes), those locators should be left intact, or recovered in some other way, unless copies of those locators have been saved somewhere. Recover your personal data to a saved file

[0060] Fig. 3 is a flow chart of a method 300 for restoring personal data to a file. The method 300 starts when a first memory has stored personal data items together with their corresponding locators (Loc.mn) and item-specific anonymous identifiers (AnonID.mn) of the persons associated with those personal data items, and a second memory has stored an anonymized version of the file. These memories may have received this content as a result of the execution of the method 100 for storing a file containing personal data described above. From the time of storing the file, the method 200 for erasing personal data associated with a person may be further executed. In this case, the first memory already contains an incomplete collection of those personal data items extracted from the file when the method 100 for storing was executed.

[0061] In a first step 310 of the method 300, those personal data items extracted from the file and the corresponding locators (Loc.mn) are retrieved from the first memory. If the locators (Loc.mn) are also stored in a location other than the first memory, such as in a second memory, they may equally be retrieved from there.

[0062] In a second step 312, an anonymized version of the file that does not include those personal data items is retrieved from the second memory.

[0063] Those personal data items are then restored to the anonymized version of the file in step 314 according to the corresponding locators (Loc.mn). For example, a cropped area of ​​a video frame corresponding to a person's face may be pasted back into the video frame as shown in the locator (Loc.mn). This restores the video frame to look similar to its original state. The restored video frame may differ from the original state if a later version of the file has been saved, for example as a result of image processing or video editing. Step 314 may entail fully restoring the file, i.e. by restoring all of the personal data items regardless of the person they are associated with.

[0064] Sub-step 314.1 represents a preferred way of performing step 314, where all of the retrieved personal data items are traversed in turn. Step 314 ends after the last item. Sub-step 314.1 is performed reliably even if some or all of the personal data has been erased from the first memory, for example upon request by an associated person. It can be configured to return a usable file (uncorrupted, readable, editable, etc.) along with some remaining portion corresponding to those erased personal data items. The remaining portion may include any output of deleting, hiding, editing, masking, replacing, overwriting, filtering and image processing applied in the execution of the preservation method 100.

[0065] In optional step 316, those portions of the anonymized version from which a personal data item has been extracted but not recovered are identified.

[0066] In a further optional step 318, downstream utility processing steps are notified of the sites identified in step 316. The identified sites may be understood as invalid or artificially altered data, as opposed to natural or surrogate data. For example, if downstream processing includes training a machine learning (ML) model, the identified sites may be excluded from the training data sent to the ML model. Alternatively, any updates to the ML model resulting from the identified sites (e.g., as represented by a set of updated weights, or calculated gradients, or generated errors for a neural network) may be cancelled, neutralized, or reverted to previous values.

[0067] The file with the recovered personal data items is kept in the runtime memory of the processor executing the method 300. To enhance the privacy of the data subjects, the method 300 may optionally include a final step 320 of taking action to prevent non-volatile storage of the file with those recovered personal data items. Such action may include erasing the file in the runtime memory or overwriting it after it has been processed. Alternatively, a gatekeeper function is provided in the first and second memories and in any available further non-volatile memory to prevent storage of the file. Further alternatively, a cleanup based on dependency tracking techniques may be performed. Device implementation

[0068] FIG. 4 shows a device 410 including a processing circuit 411 communicatively connected to a first and a second memory 421, 422 and arranged to perform the preservation method 100, the erasure method 200, and / or the recovery method 300. The processing circuit 411 may include application specific or programmable circuits. Or they may be executed in a distributed manner using networked ("cloud") resources. The processing circuit 411 may include a volatile run-time memory. Alternatively, the memory may be non-volatile and may be provided with a gatekeeper or covered by dependency tracking. The first memory 421 may be used to store the extracted personal data items, locators and item-specific anonymous identifiers extracted from the files. Since the first memory 421 is used for relatively sensitive content, it should preferably have a high resistance against intrusion attacks. Similarly, the communication connection to the first memory 421, for example via a network, should be protected against eavesdropping. The second memory 422 may be used to store an anonymized version (or multiple anonymized versions) of the file. Both memories 421, 422 may be non-volatile memories. The second memory 422 may be subject to version control. The first memory 421 need not be subject to version control.

[0069] FIG. 4 is annotated with data labels showing how the preservation method 100 may be performed. The file to be preserved is provided at the top left side of the device 410. At the bottom left side, a temporary anonymous identifier (AnonID.m) is provided. The temporary anonymous identifier (AnonID.m) may be generated by or for the person associated with the private data using a one-way function interface 490. As shown, the one-way function interface 490 receives as input the person's private identifier (PrivID), which is further modified according to the file token (FileID.m) provided by the device 410. The person may generate the private identifier (PrivID) based on a personal identifier (ID) using the one-way function interface 490 (shown in FIG. 4 as a further example thereof). Based on those inputs, the device 410 extracts the personal data items (symbolized in FIG. 4 as rectangles and circles) from the provided file and stores them together with their corresponding locators (Loc.mn) and the item-specific anonymous identifiers (AnonID.mn) in a first memory 421. The first memory may then contain the triplets of personal data item, locator, and identifier. In parallel, the device 410 stores an anonymized version of the file in a second memory 422.

[0070] When the device 410 executes the erase method 200, it may receive the requester's private identifier (PrivID). It then issues a wipe command to the first memory 421. When the device 410 executes the restore method 300, it retrieves data from the first memory 421 and the second memory 422 and outputs the restored files. Numbered embodiments

[0071] Embodiment 1. A method (100) for storing files containing personal data, comprising: Obtaining (114) a temporary anonymous identifier (AnonID.m) for a person, the temporary anonymous identifier (AnonID.m) depending on the token (FileID.m) for the file; Extracting from the file (116) personal data items associated with the person; generating (118) for each personal data item a locator (Loc.mn) that enables the personal data item to be restored to the file, and an item-specific anonymous identifier (AnonID.mn) for the person, the item-specific anonymous identifier being generated by applying a predetermined one-way function to a combination of the temporary anonymous identifier (AnonID.m) and the identifier (n) of the personal data item; storing (120) each personal data item together with its locator and an anonymous identifier unique to that item in a first memory; storing (130) an anonymized version of the file without those personal data items in a second memory; The method includes:

[0072] Embodiment 2. 2. The method of embodiment 1 for further storing a second file including personal data associated with the person, comprising: obtaining (114) a second temporary anonymous identifier (AnonID.(m+1)) for the person, the second temporary anonymous identifier (AnonID.(m+1)) being dependent on the token of the second file (FileID.(m+1)); Extracting (116) personal data items associated with the person from the second file; generating (118) for each personal data item a locator (Loc.(m+1).n) and an item-specific anonymous identifier (AnonID.(m+1).n) for the person, where the item-specific anonymous identifier is generated by applying a one-way function to a combination of the second temporary anonymous identifier (AnonID.(m+1)) and the identifier (n) for the personal data item; storing (120) each personal data item together with its locator and an anonymous identifier unique to that item in a first memory; storing (130) an anonymized version of the second file in a second memory that does not include those personal data items; The method includes:

[0073] Embodiment 3. Obtaining (114) a temporary anonymous identifier (AnonID'.m) of a further person, the temporary anonymous identifier (AnonID'.m) depending on the token (FileID.m) of the file; Extracting (116) from the file personal data items associated with the further person; generating (118) for each personal data item a locator (Loc.mn) and an item-specific anonymous identifier (AnonID'.mn) of the further person, the item-specific anonymous identifier being generated by applying a one-way function to a combination of the temporary anonymous identifier (AnonID'.m) and the identifier (n) of the personal data item; storing (120) each personal data item together with its locator and an anonymous identifier unique to that item in a first memory; Further comprising: wherein an anonymised version of the file is stored in a second memory, without the personal data items associated with the person and without the personal data items associated with the further person; The method of embodiment 1 or embodiment 2.

[0074] Embodiment 4. 13. A method of any one of the preceding embodiments, wherein the second memory, but not the first memory, is subject to version control.

[0075] Embodiment 5. 13. The method of any one of the preceding embodiments, wherein the first and second memories are non-volatile.

[0076] Embodiment 6. At least one of the personal data items is an area of ​​the image; The locator (Loc.mn) points to that area in the image. 2. The method of any one of the preceding embodiments.

[0077] Embodiment 7. A method (300) for recovering personal data to a file, comprising: Retrieving (310) the personal data items extracted from the file and the corresponding locators from a first memory storing the personal data items extracted from the file together with the corresponding locators (Loc.mn) and item-specific anonymous identifiers (AnonID.mn) of the person associated with the personal data items; retrieving (312) from the second memory an anonymized version of the file that does not include those personal data items; Restoring (314) those personal data items in anonymized versions according to their corresponding locators; The method includes:

[0078] Embodiment 8. 8. The method of embodiment 7, wherein the recovering includes recovering the retrieved personal data items sequentially (314.1) and terminating after the last item.

[0079] Embodiment 9. Identifying those portions of the anonymized version from which a personal data item has been extracted but not recovered (316); notifying downstream utility processing steps of those identified sites (318); The method of embodiment 7 or embodiment 8, further comprising:

[0080] Embodiment 10. 10. The method of any of embodiments 7 to 9, further comprising taking an action to prevent non-volatile storage of the file with those recovered personal data items (320).

[0081] Aspects of the present disclosure have been primarily described above with reference to certain embodiments, however, as will be readily apparent to one skilled in the art, other embodiments different from those disclosed above are equally possible within the scope of the present invention, as defined by the claims.

Claims

1. A method (100) for storing files containing personal data, comprising: Obtaining (114) a temporary anonymous identifier (AnonID.m) of a person, the temporary anonymous identifier (AnonID.m) depending on the token (FileID.m) of the file; Extracting (116) personal data items associated with the person from the file; generating (118) for each of said personal data items a locator (Loc.m.n) that allows said personal data item to be restored to said file, and an item-specific anonymous identifier (AnonID.m.n) of said person, said item-specific anonymous identifier being generated by applying a predetermined one-way function to a combination of said temporary anonymous identifier (AnonID.m) and said personal data item identifier (n); storing (120) each of said personal data items in a first memory together with said locator and an anonymous identifier unique to said item; storing (130) an anonymized version of the file without the personal data item in a second memory; A method comprising:

2. 2. The method of claim 1, further comprising: storing (122) a counter entry for the person, the counter entry enabling verification of comprehensiveness of a list of all of the personal data items associated with the person.

3. 3. The method of claim 2, wherein the counter entry comprises a recognizable anonymous identifier (RecAnonID.m) of the person generated by applying the one-way function to the temporary anonymous identifier (AnonID.m).

4. carried out by the recipient of the data, making available (110) a one-way function interface configured with the predetermined one-way function to allow a person to generate the temporary anonymous identifier (AnonID.m) based on a combination of a private identifier (PrivID) and the token (FileID.m) of the file without sharing the private identifier with a recipient of the data; Optionally sharing (112) the token (FileID.m) of the file with the person or the one-way function interface; The method of claim 1 , further comprising:

5. The method of claim 4 , wherein the one-way function interface is further configured to enable the person to generate the private identifier (PrivID) based on a personal identifier (ID).

6. The method of claim 1 , further comprising taking an action to prevent non-volatile storage of the temporary anonymous identifier (AnonID.m) (124).

7. 7. The method of claim 1, further comprising removing (128) the personal data items in the file by anonymization operations including at least one of deleting, hiding, editing, masking, replacing, overwriting, filtering, and imaging to obtain the anonymized version of the file.

8. The method of claim 1 , further comprising: saving (134) an updated, anonymized version of the file in the second memory.

9. at least one of said personal data items is an area of ​​a frame in a video sequence; said locator (Loc.m.n) indicating said frame in said video sequence and further indicating said area in said frame; 9. The method according to any one of claims 1 to 8.

10. A method (200) for erasing personal data associated with a person from a first memory in which personal data items have been previously stored in a manner as claimed in claim 1 together with a corresponding locator (Loc.m.n) and an item-specific anonymous identifier (AnonID.m.n) of the person associated with said personal data items, comprising: Obtaining (210) a private identifier (PrivID) of the person; Obtaining (212) tokens (FileID.m) of all files from which the personal data item may be extracted; obtaining (214) for each one of the file tokens (FileID.m) identifiers (n) of all the personal data items associated with the person and that may be extracted from the corresponding file; generating (216) a temporary anonymous identifier (AnonID.m) for the person by applying a predetermined one-way function to a combination of the obtained private identifier (PrivID) and the obtained file token (FileID.m); for each generated temporary anonymous identifier (AnonID.m) of the person, generating (218) an item-specific anonymous identifier (AnonID.m.n) of the person by applying the predetermined one-way function to a combination of the temporary anonymous identifier (AnonID.m) and the obtained identifier (n) of the personal data item; erasing (224) all of the personal data items from the first memory that match any of the person's generated item-specific anonymous identifiers (AnonID.m.n); A method comprising:

11. 11. The method according to claim 10, wherein the tokens (FileID.m) of all files from which the personal data items may be extracted are obtained by sending a query (212.1) to a second memory in which anonymized versions of the files from which the personal data items were extracted have been previously stored according to the method of claim 1.

12. 12. The method according to claim 10 or 11, wherein the identifiers (n) of all the personal data items are obtained by retrieving (214.1) counter entries for the person.

13. listing the identifiers (n) of all the personal data items associated with the person; verifying the comprehensiveness of the listed identifiers based on the retrieved counter entries; The method of claim 12 further comprising:

14. A device (410) comprising a processing circuit (411) communicatively connected to first and second memories (421, 422) and arranged to perform the method of any one of claims 1 to 13.

15. A computer program comprising instructions which, when said program is executed by a computer, cause said computer to carry out the method according to any one of claims 1 to 13.

Images