Systems and methods for optimizing storage and retention of deduplicated secondary copies at storage platforms that are write-once read-many (worm) enabled
US-2023147671-A1 · May 11, 2023 · US
US12598082B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-12598082-B2 |
| Application number | US-202418418938-A |
| Country | US |
| Kind code | B2 |
| Filing date | Jan 22, 2024 |
| Priority date | Sep 29, 2023 |
| Publication date | Apr 7, 2026 |
| Grant date | Apr 7, 2026 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
The retention lock (RL) status for a backup file stored in a storage target is certified by obtaining the RL status and encrypting it using an encryption key process to create a certified RL status. This signs the RL status by the entity storing the backup file, rather than an application setting the retention lock. The certified RL status is provided as a token to backup software of a deduplication backup system, wherein it can be made available for inspection and audit. The data may include opaque data that is data not interpreted by the filesystem. The request for RL status includes the opaque data, which is returned as part of the response, and which can be returned in part as cleartext.
Opening claim text (preview).
What is claimed is: 1 . A computer-implemented method to certify retention lock status of a file in a data store containing opaque data and stored in a storage target of a backup system, comprising: storing the file in the backup system and subject to one or more compliance standards regarding storage and protection of data including the file; applying, by the storage target, a retention lock (RL) on the file to define a RL status of the file; configuring the RL status to contain metadata comprising a name and full path for the file, mtime for the file, a checksum for the file and checksum algorithm, and the RL status; incorporating the opaque data with a request from a requestor to obtain the RL status of the file the opaque data comprising data in a read payload that will not be interpreted by a filesystem and proving that an owner of the opaque data had the data at or before the certain time, and wherein the opaque data comprises an encrypted hardware clock time to prove a clock time upon decryption; generating the RL status as cleartext in the storage target; encrypting the RL status using an encryption key process encrypting the cleartext to create a token encoding the RL status to generate an encrypted RL status; generating the token encoding the RL status through a process comprising one of hashing the cleartext and encrypting the hash using a filesystem private key, or encrypting the cleartext using the filesystem private key; and providing, in response to the request, the token to a backup software of the backup system along with the opaque data back to the requestor to verify compliance with the one or more compliance standards. 2 . The method of claim 1 wherein the token is a first type of token, and wherein the response comprises the certificate and an encrypted hash containing the opaque data with the RL status as cleartext. 3 . The method of claim 1 wherein the token comprises a second type of token comprising encrypted text of the RL status plus the opaque data. 4 . The method of claim 3 wherein the encrypted text can be decrypted using a public key of a backup server sending the response. 5 . The method of claim 1 wherein the RL status includes data items of lock or no lock setting, a lock time of the RL, and a lock duration of the RL. 6 . The method of claim 5 wherein the backup system stores the token in a local catalog, and wherein catalog further stores file information including at least one of: storage target name, file name, and file path. 7 . The method of claim 6 further comprising performing a validating process to verify that an application actually did apply the RL, at the lock time and for the lock duration, and that application metadata for the RL status has not been improperly altered. 8 . The method of claim 1 wherein the RL status is provided in the response simultaneously for a plurality of files. 9 . A computer-implemented method to certify retention lock status of a file in a data store containing opaque data and stored in a storage target of a backup system, comprising: first storing one or more files in the storage target, wherein the files are retention locked according to a lock policy and subject to one or more compliance standards regarding storage and protection of data including the file; defining opaque data comprising a read payload that will not be interpreted by a filesystem, the opaque data comprising data in a read payload that will not be interpreted by a filesystem and proving that an owner of the opaque data had the data at or before the certain time, and wherein the opaque data comprises an encrypted hardware clock time to prove a clock time upon decryption; sending a request to obtain a certified retention lock (RL) status of the file to a certifier component of a backup server, wherein the request contains the opaque data, wherein the RL status is generated as cleartext in the storage target, and is configured to contain metadata comprising a name and full path for the file, mtime for the file, a checksum for the file and checksum algorithm, and the RL status; encrypting the RL status using an encryption key process encrypting the cleartext to create a token encoding the RL status to generate an encrypted RL status; receiving, in response to the request, a response type encoding the RL status and the opaque data; and generating the token encoding the RL status through a process comprising one of hashing the cleartext and encrypting the hash using a filesystem private key, or encrypting the cleartext using the filesystem private key. 10 . The method of claim 9 wherein the response type is a first type comprising an RL certificate and an encrypted hash containing the opaque data with the RL status as cleartext. 11 . The method of claim 9 wherein the response type is a second type comprising encrypted text of the RL status plus the opaque data. 12 . The method of claim 11 wherein the encrypted text can be decrypted using a public key of a backup server sending the response. 13 . The method of claim 9 further comprising: embodying the RL status as a certificate token of either a first type or second type; providing, in response to the request, the token to a backup software of the backup system to verify compliance with the one or more compliance standards. 14 . A system for certifying retention lock (RL) status of a file in a data store containing opaque data and stored in a backup system by a backup server, comprising: a storage storing the file in the backup system and subject to one or more compliance standards regarding storage and protection of data including the file; a hardware clock maintaining a time of actions performed by users of the backup system; a requestor requesting the RL status of the file in a request that incorporates the opaque data, wherein the opaque data comprises data in a read payload that will not be interpreted by a filesystem, the opaque data comprising data in a read payload that will not be interpreted by a filesystem and proving that an owner of the opaque data had the data at or before the certain time, and wherein the opaque data comprises an encrypted hardware clock time to prove a clock time of an action upon decryption; a certifier component of the backup server encoding the RL status in a token of either a first type or second type, and wherein creating the token comprises the action proven by the clock time; a generator generating the RL status as cleartext in the storage target; an encryptor encrypting the RL status using an encryption key process encrypting the cleartext to create a token encoding the RL status to generate an encrypted RL status; an interface sending a request to obtain the RL status to the backup server, and receiving back a response type the token encoding the RL status and the opaque data; and generating the token encoding the RL status through a process comprising one of hashing the cleartext and encrypting the hash using a filesystem private key, or encrypting the cleartext using the filesystem private key. 15 . The system of claim 14 wherein the token is a first type, and the response comprises an RL certificate and an encrypted hash containing the opaque data with the RL status as cleartext. 16 . The system of claim 14 wherein the token is a first type, and the response comprises encrypted text of the RL status plus the opaque data, and further wherein the encrypted text can be decrypted using a public key of a backup server sending the response. 17 . The system of claim 14 wherein the RL sta
for networked environments · CPC title
using tickets or tokens, e.g. Kerberos (network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807) · CPC title
Database-specific techniques · CPC title
characterised by the use of retention policies (retention policies for HSM systems G06F16/185) · CPC title
Management of the data involved in backup or backup restore · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.