DETAILED ACTION
Receipt of Applicant’s Amendment, filed July 10, 2025 is acknowledged.
Claims 1 and 14 were amended.
Claims 5-13, 16, 17, 19, and 20 were cancelled.
Claims 1-4, 14, 15, and 18 are pending in this office action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Brooker [8738935] in view of Seema [Data Deletion using NonRetrievable Bit Sequence Overwriting Approach in Cloud Storage] and Tian [A Verifiable Assured Deletion Scheme of Cloud Data Based on Blockchain].
With regard to claim 1 Brooker teaches A method for overwriting-based deletion (Brooker, Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon”) of information as the data stored thereon (Id) and verification of deletion (Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), the method comprising the steps of:
(S1) receiving, at a server as the control plane 206 (Brooker, Column 6, lines 14-17 “The distributed program execution service 200 may further 15 utilize the computing resources to implement a service control plane 206 configured at least to control the computing services.”), a deletion request (Brooker, Column 4, lines 39-42 “In some embodiments, the customer entity requests, or authorizes a request for, data stored upon the storage system to be securely, verifiably or permanently removed or rendered inaccessible.”) for target information as the data stored on the storage system to be removed (Id) and a random seed (Brooker, Column 9, lines 62-65 “wherein each customer entity data request includes a cryptographic entity-generated key, the key being required for the customer entity to obtain or write the data to and/or from the storage system.”) from a verifying terminal as the customer entity (Brooker, Column 14, lines 12-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610.”);
(S2) performing, at a server as control pane 206 (Brooker, Column 6, lines 53-59), [[(Brooker, Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon”) on the target information as the data stored thereon (Id) by [[ as cryptographic key eraser, for example zeroizing (Brooker, Column 3, lines 56-63 “cryptographically based "secure erase" functionality, as is known to those in the art. In some embodiments, such self-encrypting devices are capable of irreversibly removing access to data stored thereon by internally encrypting all data, either in operation or upon command, and physically erasing ( e.g., cryptographically zeroizing) or otherwise disrupting the cryptographic key that is necessary to decrypt the data.”; Column 10, lines 42-44 “As previously alluded to, the key(s) may be persisted anywhere that is readily accessible and verifiably cryptographically zeroizable”);
(S3) initiating, at the verifying terminal as the customer entity (Brooker, Column 5, lines 27-40 “The provision of such information is optionally preceded by any test appropriate for the level of verifiability required or requested. In some embodiments, the customer entity is notified when its secure erasure request is received. In some embodiments, the notification includes verbiage that indicates a guarantee, appropriate to the methodology that was or will be used to destroy or render the data permanently inaccessible, that the data is or will verifiably be disposed of. In some embodiments, the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”), an extraction request as the independently verifying the disposition of the data (Id) for extracting a [[as the pending, occurring or completed state (Brooker, Column 14, lines 12-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610.”; Please note this claim limitation has been interpreted as an intended use of the extraction request, and that the slave node extracts the post-deletion state);
(S4) broadcasting (Brooker, Column 3, lines 28-32 “The storage system may contain any number of storage nodes 108, which, in some embodiments, are interconnected via a network or data connection such that the nodes may communicate, by any appropriate method, with one another.”), from a master node as cryptographic entity 308 (Brooker, Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”) in a source domain as the computer service provided (Brooker, Column 6, lines 14-17 “The distributed program execution service 200 may further 15 utilize the computing resources to implement a service control plane 206 configured at least to control the computing services.”) of the target information as the data stored on the storage node (Brooker, Column 4, lines 59-64 “It is contemplated that in embodiments where the customer entity's data resides across a plurality of self-encrypting devices, an appropriate entity, such as the storage system and/or the customer entity, is configured to track every storage device upon which the customer entity's data has been stored”) in the server as control pane 206 (Brooker, Column 6, lines 53-59), the extraction request to at least one slave node as the storage device itself performing the encrypting/verification, e.g. storage devices 312 (Brooker, Column 5, lines 35-40 “the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”; Column 9, lines 15-16 “The storage nodes 310 are comprised of one or more storage devices 312”), wherein the at least one slave node as the storage device itself performing the encrypting/verification (Brooker, Column 5, lines 35-40 “the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”) sends a post-deletion state feedback as the notification of the pending, occurring, or completed permanent disablement of access to the stored customer data 610 (Brooker, Column 14, lines 14-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610”) to the master node as the cryptographic entity serving as the egress point for the data (Brooker, Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”);
(S5) receiving, at the master node as the cryptographic entity serving as the egress point for the data, means that the information is passed through the cryptographic entity (Brooker, Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”), the post-deletion state feedback as the notification of the pending, occurring, or completed permanent disablement of access to the stored customer data 610 (Brooker, Column 14, lines 14-15); and
(S6) sending (Brooker, Column 5, lines 24-27 “In some embodiments, once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), by the server as control pane 206 (Brooker, Column 6, lines 53-59), the post-deletion state feedback as the notification of the pending, occurring, or completed permanent disablement of access to the stored customer data 610 (Brooker, Column 14, lines 14-15) and a related state-verification parameter as validating matching keys (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”), including a [[ as the customer entity (Brooker, Column 14, lines 12-15), wherein the related state-verification parameter is calculated as calculating that the keys match (Brooker, Column 10, lines 4-8) at least through:
[[as the analogous key (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”) possessed by the master node as cryptographic entity 308 (Column 9, lines 60-61),
[[
[[
(S7) verifying, by the verifying terminal as the customer entity may receive the secure erasure request and independently verify the disposition of the data using an appropriate means (Brooker, Column 5, lines 36-40 “may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”; Column 10, lines 57-62 “Such requests, for ease of example, are herein referred to as "secure erasure requests." In some embodiments, such secure erasure requests may be received by any entity along the data path, including aspects of the computer system (including the customer entity), aspects of the storage system, and/or the cryptographic entity.”), an overwriting result as the data’s inaccessibility (Brooker, Column 14, lines 17-20 “such notifications may include information that allow entities to independently verify the data's inaccessibility, and may include and/or be backed by a service-level agreement or similar guarantee”) based on [[as the customer entity may receive the secure erasure request and independently verify the disposition of the data using an appropriate means (Brooker, Column 5, lines 36-40; Column 14, lines 12-15; Column 10, lines 57-62 “including the customer entity”) verifies the overwriting result as the entity verifying the data’s inaccessibility (Brooker, Column 14, lines 17-20 “such notifications may include information that allow entities to independently verify the data's inaccessibility, and may include and/or be backed by a service-level agreement or similar guarantee”) based on [[
[[
determining whether the post-deletion state as the pending, occurring or completed state (Brooker, Column 14, lines 12-15) and [[
if the post-deletion state as the pending, occurring or completed state (Brooker, Column 14, lines 12-15) and [[verification as validating the keys are analogous (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”; Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”) based on a public key as the customer entity-submitted key (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”) possessed by the verifying terminal as the customer entity submitting the data request (Id), the random seed as the cryptographic entity-generated key(Brooker, Column 9, lines 62-65 “wherein each customer entity data request includes a cryptographic entity-generated key, the key being required for the customer entity to obtain or write the data to and/or from the storage system.”), and [[as the data’s inaccessibility is verified (Brooker, Column 14, lines 17-20 “such notifications may include information that allow entities to independently verify the data's inaccessibility, and may include and/or be backed by a service-level agreement or similar guarantee”) that is either False as the keys not matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”) or True as the keys matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”); and
determining that verification fails as not verifiably destroyed or not made permanently inaccessible (Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), if the verification result is False as the keys not matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”) or determining that verification succeeds as verifiably destroyed or made permanently inaccessible (Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), if the verification result is True as the keys matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”).
Brooker does not explicitly teach performing fine-grained overwriting on the information by means of random overwriting.
Seema teaches (S2) performing fine-grained… overwriting on the information by random overwriting (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the overwrite mechanism taught by Brooker (e.g. the cryptographic key erasure, Column 3, lines 56-63; Column 10 lines 42-44) as the Secure Data Deletion taught by Seema as it yields the predictable results of providing a cost efficient, convenient, and secure means of performing data deletion within a cloud environment (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “This approach of secure data deletion is very cost effective, convenient, users do not require to buy any additional security device and no any dependency of trusted third party.”) The proposed combination involves a simple replacement of one overwrite mechanism (e.g. key zeroizing) with a different overwrite mechanism (e.g. LFSR and right-shift /XOR operations)
Brooker does not explicitly teach (S3) extracting a post-deletion state… (S6)sending… a proof parameter (proof)… calculating a proof using a proof-making algorithm of a verifiable pseudo- random function …, proof = VRF_MakeProof(SK. seed), wherein VRF_MakeProof represents the proof-making algorithm of the verifiable pseudo-random function, and (S7) verifying… the overwriting result based on the verifiable pseudo-random function… the verifiable pseudo-random function through: obtaining a result based on the proof parameter; determining whether the post-deletion state and the result are equal; if the post-deletion state and the result are equal, performing verification based on … the proof parameter.
Tian teaches (S3) … extracting a post-deletion state as the data value x (Tian, Page 9, Section 2.5 “(value, proof ) ← Evaluate(SK, x) :input message x and private key SK , output pseudo-random number value and proof”) … (S6) sending… a related state-verification parameter as the proof calculated by each node (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, Algorithm 1, line 3 “Each node calculates its own (value , proof ) ←Evaluate(SK , Seedᵋ)”), including a proof parameter (proof) as proof (Id)… wherein the related state-verification parameter (Id) is calculated at least through:
calculating a proof as ‘proof ‘(Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”) using a proof-making algorithm of a verifiable pseudo- random function (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”) based on a private key as private key SK (Id)…,
proof = VRF_MakeProof(SK. seed) (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, Algorithm 1, line 3 “Each node calculates its own (value , proof ) ←Evaluate(SK , Seedᵋ)”),
wherein VRF_MakeProof represents the proof-making algorithm of the verifiable pseudo-random function(Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”), and
(S7) verifying… an overwriting result based on the verifiable pseudo-random function (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”) through:
obtaining the overwriting result as value (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, “(value , proof ) ←Evaluate(SK , x)”);
determining whether the post-deletion state as x (Tian, Page 9, Section 2.5 “For any value x”) and the overwriting result as the value (Tian, Page 9, section 2.5) are equal as value corresponding uniquely to x (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof) :use the public key PK to verify value and judge whether value uniquely corresponds to x.”);
if the post-deletion state and the overwriting result are equal as value corresponding uniquely to x (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof) :use the public key PK to verify value and judge whether value uniquely corresponds to x.”), performing verification as 0 meaning false, 1 meaning true (Id; Please note this claim limitation has been read in light of Paragraph [0107] in which the result of True/False means that verification fails or succeeds) based on a public key as public key PK (Id)…, the random seed as private key SK (Tian, Page 9, Section 2.5 “(value, proof ) ← Evaluate(SK, x) :input message x and private key SK , output pseudo-random number value and proof”), and the proof parameter (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof), and producing a verification result as 0 meaning false, 1 meaning true (Id) that is either False as 0 (id) or True as 1 (Id); and
determining that verification fails, if the verification result is False as one of ordinary skill in the art would recognize the binary ‘0’ as meaning ‘false’ (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof) :use the public key PK to verify value and judge whether value uniquely corresponds to x.”) or determining that verification succeeds, if the verification result is True as one of ordinary skill in the art would recognize the binary ‘1’ as meaning ‘true’ (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the verification functionality taught by Brookers using the known VRF as it offers verifiability, randomness and certainty (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30].”) Please note that Brookers states that any appropriate test may be used to achieve the verification (Brookers, Column 5, lines 24-29 “In some embodiments, once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity. The provision of such information is optionally preceded by any test appropriate for the level of verifiability required or requested”), thus one of ordinary skill in the art would consider it obvious to try the VRF method.
With regard to claim 2 the proposed combination further teaches wherein the step of performing fine-grained overwriting (Brooker, Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon”; Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting) on the target information as the data stored thereon (Id) by random overwriting (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) comprises:
determining at least one random overwriting policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”) based on a deletion requirement as the workflow for the deletion operation, such as the timing/delay of the operation (Brooker, Column 7, lines 15-18 “the workflow component 234 may select particular computing resources of the distributed program execution service 200 to execute and/or be assigned to particular tasks.”; Column 11, lines 5-10 “when the invocation of the secure erasure ability is not possible within a period of time after the secure erasure request is made, the request or any related commands are queued, in part or whole, for processing or execution at a later time when such processing or execution becomes possible.”) of the verifying terminal as the customer entity (Brooker, Column 14, lines 12-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610.”), wherein the random overwriting(Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) is based upon the at least one random overwriting (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”).
With regard to claim 14 Brooker teaches. A system for overwriting-based deletion (Brooker, Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon”) of information as the data stored thereon (Id) and verification of deletion (Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”) comprising:
A verifying terminal as the customer entity (Brooker, Column 4, lines 39-42 “In some embodiments, the customer entity requests, or authorizes a request for, data stored upon the storage system to be securely, verifiably or permanently removed or rendered inaccessible.”);
A server as the control plane 206 (Brooker, Column 6, lines 14-17 “The distributed program execution service 200 may further 15 utilize the computing resources to implement a service control plane 206 configured at least to control the computing services.”) comprising a master node as cryptographic entity 308 (Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”) and at least one slave node as the storage device itself performing the encrypting/verification, e.g. storage devices 312 (Brooker, Column 5, lines 35-40 “the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”; Column 9, lines 15-16 “The storage nodes 310 are comprised of one or more storage devices 312”),
wherein the verifying terminal as the customer entity (Brooker, Column 4, lines 39-42) is configured for:
sending a random seed (Brooker, Column 9, lines 62-65 “wherein each customer entity data request includes a cryptographic entity-generated key, the key being required for the customer entity to obtain or write the data to and/or from the storage system.”) and a deletion request (Brooker, Column 4, lines 39-42 “In some embodiments, the customer entity requests, or authorizes a request for, data stored upon the storage system to be securely, verifiably or permanently removed or rendered inaccessible.”) for target information as the data stored on the storage system to be removed (Id) to the server as the control plane 206 (Brooker, Column 6, lines 14-17 “The distributed program execution service 200 may further 15 utilize the computing resources to implement a service control plane 206 configured at least to control the computing services.”);
(S3) sending an extraction request as the customer independently verify the disposition of the data (Brooker, Column 5, lines 27-40 “The provision of such information is optionally preceded by any test appropriate for the level of verifiability required or requested. In some embodiments, the customer entity is notified when its secure erasure request is received. In some embodiments, the notification includes verbiage that indicates a guarantee, appropriate to the methodology that was or will be used to destroy or render the data permanently inaccessible, that the data is or will verifiably be disposed of. In some embodiments, the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”) for extracting a [[as the pending, occurring or completed state (Brooker, Column 14, lines 12-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610.”; Please note this claim limitation has been interpreted as an intended use of the extraction request, and that the slave node extracts the post-deletion state) to the server as control pane 206 (Brooker, Column 6, lines 53-59);
(S5) receiving the post-deletion state as the pending, occurring or completed state (Brooker, Column 14, lines 12-15) and its related verification parameter as validating matching keys (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”) from the server s control pane 206 (Brooker, Column 6, lines 53-59) and verifying overwriting result as the entity verifying the data’s inaccessibility (Brooker, Column 14, lines 17-20 “such notifications may include information that allow entities to independently verify the data's inaccessibility, and may include and/or be backed by a service-level agreement or similar guarantee”) based on a [[
(S6) wherein the related verification parameter as validating matching keys (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”) is calculated at least through:
(S6) [[as the analogous key (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”) possessed by the master node as cryptographic entity 308 (Column 9, lines 60-61),
[[
[[as the customer entity may receive the secure erasure request and independently verify the disposition of the data using an appropriate means (Brooker, Column 5, lines 36-40 “may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”; Column 10, lines 57-62 “Such requests, for ease of example, are herein referred to as "secure erasure requests." In some embodiments, such secure erasure requests may be received by any entity along the data path, including aspects of the computer system (including the customer entity), aspects of the storage system, and/or the cryptographic entity.”) verifies the overwriting result as the entity verifying the data’s inaccessibility (Brooker, Column 14, lines 17-20 “such notifications may include information that allow entities to independently verify the data's inaccessibility, and may include and/or be backed by a service-level agreement or similar guarantee” based on [[
(S6) [[
(S7) determining whether the post-deletion state as the pending, occurring or completed state (Brooker, Column 14, lines 12-15) and [[
(S7) performing verification as validating the keys are analogous (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”; Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”) based on a public key as the customer entity-submitted key (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”) possessed by the verifying terminal as the customer entity submitting the data request (Id), the random seed as the cryptographic entity-generated key(Brooker, Column 9, lines 62-65 “wherein each customer entity data request includes a cryptographic entity-generated key, the key being required for the customer entity to obtain or write the data to and/or from the storage system.”), and [[as the pending, occurring or completed state (Brooker, Column 14, lines 12-15) and [[ as the data’s inaccessibility is verified (Brooker, Column 14, lines 17-20 “such notifications may include information that allow entities to independently verify the data's inaccessibility, and may include and/or be backed by a service-level agreement or similar guarantee”) that is either False as the keys not matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”) or True as the keys matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”); and
(S7) determining that verification fails as not verifiably destroyed or not made permanently inaccessible (Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), if the verification is False as the keys not matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”) or determining that verification succeeds as verifiably destroyed or made permanently inaccessible (Brooker, Column 5, lines 24-28 “once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), if the verification result is True as the keys matching (Brooker, Column 10, lines 6-8 “which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity”), wherein the server as the control plane 206 (Brooker, Column 6, lines 14-17) is configured for:
(S7) receiving the random seed (Brooker, Column 9, lines 62-65 “wherein each customer entity data request includes a cryptographic entity-generated key, the key being required for the customer entity to obtain or write the data to and/or from the storage system.”) and the deletion request (Brooker, Column 4, lines 39-42 “In some embodiments, the customer entity requests, or authorizes a request for, data stored upon the storage system to be securely, verifiably or permanently removed or rendered inaccessible.”) from the verifying terminal as the customer entity (Id);
(S2) performing [[(Brooker, Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon”) on the target information as the data stored thereon (Id) by [[ as cryptographic key eraser, for example zeroizing (Brooker, Column 3, lines 56-63 “cryptographically based "secure erase" functionality, as is known to those in the art. In some embodiments, such self-encrypting devices are capable of irreversibly removing access to data stored thereon by internally encrypting all data, either in operation or upon command, and physically erasing ( e.g., cryptographically zeroizing) or otherwise disrupting the cryptographic key that is necessary to decrypt the data.”; Column 10, lines 42-44 “As previously alluded to, the key(s) may be persisted anywhere that is readily accessible and verifiably cryptographically zeroizable”);
(S3) receiving the extraction request as the customer entity independently verifying the disposition of the data (Brooker, Column 5, lines 27-40 “The provision of such information is optionally preceded by any test appropriate for the level of verifiability required or requested. In some embodiments, the customer entity is notified when its secure erasure request is received. In some embodiments, the notification includes verbiage that indicates a guarantee, appropriate to the methodology that was or will be used to destroy or render the data permanently inaccessible, that the data is or will verifiably be disposed of. In some embodiments, the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”) from the verifying terminal as the customer entity (Id) for extracting the [[as the pending, occurring or completed state (Brooker, Column 14, lines 12-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610.”; Please note this claim limitation has been interpreted as an intended use of the extraction request, and that the slave node extracts the post-deletion state);
(S4) broadcasting (Brooker, Column 3, lines 28-32 “The storage system may contain any number of storage nodes 108, which, in some embodiments, are interconnected via a network or data connection such that the nodes may communicate, by any appropriate method, with one another.”), from a master node as cryptographic entity 308 (Brooker, Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”) in a source domain as the computer service provided (Brooker, Column 6, lines 14-17 “The distributed program execution service 200 may further 15 utilize the computing resources to implement a service control plane 206 configured at least to control the computing services.”) of the target information as the data stored on the storage node (Brooker, Column 4, lines 59-64 “It is contemplated that in embodiments where the customer entity's data resides across a plurality of self-encrypting devices, an appropriate entity, such as the storage system and/or the customer entity, is configured to track every storage device upon which the customer entity's data has been stored”) in the server as control pane 206 (Brooker, Column 6, lines 53-59), the extraction request to at least one slave node as the storage device itself performing the encrypting/verification, e.g. storage devices 312 (Brooker, Column 5, lines 35-40 “the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”; Column 9, lines 15-16 “The storage nodes 310 are comprised of one or more storage devices 312”), wherein the at least one slave node as the storage device itself performing the encrypting/verification (Brooker, Column 5, lines 35-40 “the notification is backed by service level agreement or similar guarantee, and may include information that enables the customer entity to independently verify the disposition of the data (e.g., command responses, from the self-encrypting storage devices, to issued secure erase commands).”) sends a post-deletion state feedback as the notification of the pending, occurring, or completed permanent disablement of access to the stored customer data 610 (Brooker, Column 14, lines 14-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610”) to the master node as the cryptographic entity serving as the egress point for the data (Brooker, Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”); and
(S6) sending (Brooker, Column 5, lines 24-27 “In some embodiments, once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity.”), by the master node as the cryptographic entity serving as the egress point for the data (Brooker, Column 9, lines 60-61 “the cryptographic entity is further operable to serve as an ingress/egress point for data on the storage system”), the post-deletion state feedback as the notification of the pending, occurring, or completed permanent disablement of access to the stored customer data 610 (Brooker, Column 14, lines 14-15) and a related state-verification parameter as validating matching keys (Brooker, Column 10, lines 4-8 “For example, the customer entity may submit data requests, which include an obtained key or keys, to the storage system, which validates the customer entity-submitted key against a matching or analogous key obtained from the cryptographic entity.”), including a [[ as the customer entity (Brooker, Column 14, lines 12-15).
Brooker does not explicitly teach (S3) extracting a post-deletion state … (S5) verifying overwriting results based on a verifiable pseudo-random function… (S6) calculating the proof using a proof-making algorithm of a verifiable pseudo- random function… proof = VRF MakeProof(SK. seed), wherein VRF MakeProof represents the proof-making algorithm of the verifiable pseudo-random function… based on the verifiable pseudo-random function through: obtaining a overwriting result based on the proof parameter; (S7) determining whether the post-deletion state and the overwriting result are equal; (S7) the proof parameter… the overwriting results are equal… (S6) a proof parameter (proof).
Tian teaches (S3) … extracting a post-deletion state as the data value x (Tian, Page 9, Section 2.5 “(value, proof ) ← Evaluate(SK, x) :input message x and private key SK , output pseudo-random number value and proof”)… (S5) verifying overwriting results based on a verifiable pseudo-random function (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”), and wherein the related verification parameter as the proof calculated by each node (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, Algorithm 1, line 3 “Each node calculates its own (value , proof ) ←Evaluate(SK , Seedᵋ)”) is calculated at least through:
calculating the proof as ‘proof ‘(Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”) using a proof-making algorithm of a verifiable pseudo- random function (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”) based on a private key as private key SK (Id)…
proof = VRF_MakeProof(SK. seed) (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, Algorithm 1, line 3 “Each node calculates its own (value , proof ) ←Evaluate(SK , Seedᵋ)”),
wherein VRF_MakeProof represents the proof-making algorithm of the verifiable pseudo-random function(Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”), and
(S7) verifying… the overwriting result based on the verifiable pseudo-random function (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30]. For any value x and private key SK as input, the pseudo-random number value and proof can be output”) through:
obtaining a overwriting result as value (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, “(value , proof ) ←Evaluate(SK , x)”; Please see the 112b above, this claim limitation has been construed in light of Paragraphs [0105] and [0106] of the original specification);
performing verification as 0 meaning false, 1 meaning true (Id; Please note this claim limitation has been read in light of Paragraph [0107] in which the result of True/False means that verification fails or succeeds) based on a public key as public key PK (Id)…, the random seed as private key SK (Tian, Page 9, Section 2.5 “(value, proof ) ← Evaluate(SK, x) :input message x and private key SK , output pseudo-random number value and proof”), and the proof parameter (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof), if the post-deletion state and the overwriting result are equal as value corresponding uniquely to x (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof) :use the public key PK to verify value and judge whether value uniquely corresponds to x.”), and producing a verification result as 0 meaning false, 1 meaning true (Id) that is either False as 0 (id) or True as 1 (Id);
determining that verification fails, if the verification result is False as one of ordinary skill in the art would recognize the binary ‘0’ as meaning ‘false’ (Tian, Page 9, Section 2.5 “(0,1)←Verify (PK, x, value, proof) :use the public key PK to verify value and judge whether value uniquely corresponds to x.”) or determining that verification succeeds, if the verification result is True as one of ordinary skill in the art would recognize the binary ‘1’ as meaning ‘true’ (Id).
(S6) sending… a related state-verification parameter as the proof calculated by each node (Tian, Page 9, section 2.5 “For any value x and private key SK as input, the pseudo-random number value and proof can be output.”; Page 14, Algorithm 1, line 3 “Each node calculates its own (value , proof ) ←Evaluate(SK , Seedᵋ)”), including a proof parameter (proof) as proof (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the verification functionality taught by Brookers using the known VRF as it offers verifiability, randomness and certainty (Tian, Page 9 Section 2.5 “The verifiable random function[29] proposed by Silvio Micali et al. is a verifiable pseudo-random function with verifiability, randomness and certainty[30].”) Please note that Brookers states that any appropriate test may be used to achieve the verification (Brookers, Column 5, lines 24-29 “In some embodiments, once the data has been verifiably destroyed or made permanently inaccessible, information relating to the data's disposition is made available to the customer entity. The provision of such information is optionally preceded by any test appropriate for the level of verifiability required or requested”), thus one of ordinary skill in the art would consider it obvious to try the VRF method.
Brooker does not explicitly teach performing fine-grained overwriting on the information by means of random overwriting.
Seema teaches (S2) performing fine-grained… overwriting on the information by random overwriting (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the overwrite mechanism taught by Brooker (e.g. the cryptographic key erasure, Column 3, lines 56-63; Column 10 lines 42-44) as the Secure Data Deletion taught by Seema as it yields the predictable results of providing a cost efficient, convenient, and secure means of performing data deletion within a cloud environment (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “This approach of secure data deletion is very cost effective, convenient, users do not require to buy any additional security device and no any dependency of trusted third party.”) The proposed combination involves a simple replacement of one overwrite mechanism (e.g. key zeroizing) with a different overwrite mechanism (e.g. LFSR and right-shift /XOR operations).
Claims 3-4, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Brooker in view of Seema, and Tian and Osugi [JP2009230674] (Please note mapping has been made to the Machine Translation provided).
With regard to claims 3 the proposed combination further teaches wherein the random overwriting policy (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) is
(1) a single-time overwriting policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”), which is makes rule-based changes to the random seed (Brooker, Column 10, lines 62-66 “In some embodiments, the requests are serviced by cryptographically zeroizing, erasing, or otherwise permanently disrupting a cryptographic key required to decrypt the stored data, in all locations in which it is persisted.”; Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “a non-retrievable bit sequence generator using 10-bit linear feedback shift register (LFSRs) is proposed to produce true random numbers (TRNs) bit sequence at user-side which is impossible to predict and nondeterministic.”) corresponding to a counter mode as the replication factor (Seema, Page 851 Section 3.1 Secure Data Storage Method: “The data being stored, first encrypted by the existing encryption techniques. The encrypted data then segmented with the help of a replication factor (RF), which results in fixed-size chunks. The overall strategy is used to increase the secure storage and availability of the data in the cloud storage environment [20].”), and overwrites (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”; Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “The secure data overwriting mechanism”) a target storage area in the slave node as all the locations in which the data persists (Brooker, Column 10, lines 62-66; Column 10, lines 50 “tracking of the keys”; Seema, Page 850, Figure 1: see the nodes in the Distributed Cloud storage) in a chunkwise manner as split into chunks (Seema, Page 851 Section 3.1 Secure Data Storage Method: “The data being stored, first encrypted by the existing encryption techniques. The encrypted data then segmented with the help of a replication factor (RF), which results in fixed-size chunks”; Page 851 Figure 1 see Chunks), wherein the target storage area stores the target information (Brooker, Column 10, lines 44-52 “In embodiments where a customer entity connects indirectly or directly to a plurality of storage devices and/or storage nodes, any number of keys may be used to encrypt data stored upon the plurality of devices and/or nodes, although it is generally preferred to keep the quantity and locational diversity of such keys to a minimum, so as to ease tracking of the keys and increase the verifiability of any subsequent request to remove access to the data, as will be discussed below.”); or
(2) a repetitive overwriting policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”), which overwrites (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”) the target storage area (Brooker, Column 10, lines 62-66 “In some embodiments, the requests are serviced by cryptographically zeroizing, erasing, or otherwise permanently disrupting a cryptographic key required to decrypt the stored data, in all locations in which it is persisted.”) by alternately using at least two different overwriting method as the right-shift operation and the XOR operation (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”), and [[ (Read in light of the instant specification: ¶95, ¶96, ¶0132 example of three-times overwriting).
Brooker does not explicitly teach the third overwriting method is used to perform the last overwriting operation of the target storage area.
Osugi teaches which overwrites the target storage area by alternately using at least two different overwriting methods as the first and second times the overwrite is done (Osugi, ¶44 “As a method of overwriting and erasing, for example, a method of overwriting once with zero data, a method using a random number, or the like may be used. There is a method of overwriting three times in the order of a random number and zero data (referred to as an NSA method).”; ¶87), and another overwriting method is used to perform the last overwriting operation of the target storage area as the third overwrite in the three times (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the proposed combination using the known three-times overwriting method taught by Osugi as it yields the predictable result of ensuring the erasure of the data using a known method. The proposed combination may incorporate the overwriting methods taught by Seema and Brooker into the three-times overwriting approach as it would ensure that the data is completely erased.
With regard to claims 4 and 18 the proposed combination further teaches wherein the server receives a random number from the verifying terminal as the seed value generated on the user-side (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “The seed value for LFSR is generated on the user-side”) and wherein the at least two different overwriting as the first and second times the overwrite is done (Osugi, ¶44 “As a method of overwriting and erasing, for example, a method of overwriting once with zero data, a method using a random number, or the like may be used. There is a method of overwriting three times in the order of a random number and zero data (referred to as an NSA method).”; ¶87) methods include a step selected from the group consisting of:
using the random number as the random numbers computed by LFSR (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) to overwrite (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”) the target storage area as all the locations in which the data persists (Brooker, Column 10, lines 62-66; Column 10, lines 50 “tracking of the keys”; interpreted as the first of the two different overwriting means recited in parent claim);
using a bitwise negation result as the XOR operation (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) of the random number as the seed value (Id) to overwrite (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”) the target storage area as all the locations in which the data persists (Brooker, Column 10, lines 62-66; Column 10, lines 50 “tracking of the keys”; interpreted as the second of the two different overwriting means recited in parent claim); and
making rule-based changes to the random seed (Brooker, Column 10, lines 62-66 “In some embodiments, the requests are serviced by cryptographically zeroizing, erasing, or otherwise permanently disrupting a cryptographic key required to decrypt the stored data, in all locations in which it is persisted.”) corresponding to a counter mode as the replication factor (Seema, Page 851 Section 3.1 Secure Data Storage Method: “The data being stored, first encrypted by the existing encryption techniques. The encrypted data then segmented with the help of a replication factor (RF), which results in fixed-size chunks. The overall strategy is used to increase the secure storage and availability of the data in the cloud storage environment [20].”), and overwriting (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”; Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “The secure data overwriting mechanism”) chunks (Seema, Page 850 Figure 1) of the target storage area as all the locations in which the data persists (Brooker, Column 10, lines 62-66; Column 10, lines 50 “tracking of the keys”; Interpreted as the singe-time overwriting policy reciting in parent claim).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the distributed storage environment taught by Brook in the manner depicted by Seema as it provides a means of storing the files in a distributed way (Seema, Page 850 Section 3 Proposed Approach for Assured Data Deletion: “The encrypted file is split into chunks and stored in cloud storage in a distributed way. This concept is applied to achieve the secure storage of the file”).
With regard to claim 15 the proposed combination further teaches wherein the server determines at least one random overwriting policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”) based on a deletion requirement as the workflow for the deletion operation, such as the timing/delay of the operation (Brooker, Column 7, lines 15-18 “the workflow component 234 may select particular computing resources of the distributed program execution service 200 to execute and/or be assigned to particular tasks.”; Column 11, lines 5-10 “when the invocation of the secure erasure ability is not possible within a period of time after the secure erasure request is made, the request or any related commands are queued, in part or whole, for processing or execution at a later time when such processing or execution becomes possible.”) of the verifying terminal as the customer entity (Brooker, Column 14, lines 12-15 “At least upon completion of step 608, the customer entity or connecting user is notified of the pending, occurring, or completed permanent disablement of access to the stored customer data 610.”) and wherein the random overwriting (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) is based upon the at least one random overwriting (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”),
wherein the at least one random overwriting policy (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”) includes:
a single-time overwriting policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”), which is makes rule-based changes to the random seed (Brooker, Column 10, lines 62-66 “In some embodiments, the requests are serviced by cryptographically zeroizing, erasing, or otherwise permanently disrupting a cryptographic key required to decrypt the stored data, in all locations in which it is persisted.”; Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “a non-retrievable bit sequence generator using 10-bit linear feedback shift register (LFSRs) is proposed to produce true random numbers (TRNs) bit sequence at user-side which is impossible to predict and nondeterministic.”) corresponding to a counter mode as the replication factor (Seema, Page 851 Section 3.1 Secure Data Storage Method: “The data being stored, first encrypted by the existing encryption techniques. The encrypted data then segmented with the help of a replication factor (RF), which results in fixed-size chunks. The overall strategy is used to increase the secure storage and availability of the data in the cloud storage environment [20].”), and overwrites (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”; Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “The secure data overwriting mechanism”) a target storage area in the slave node as all the locations in which the data persists (Brooker, Column 10, lines 62-66; Column 10, lines 50 “tracking of the keys”; Seema, Page 850, Figure 1: see the nodes in the Distributed Cloud storage) in a chunkwise manner as split into chunks (Seema, Page 851 Section 3.1 Secure Data Storage Method: “The data being stored, first encrypted by the existing encryption techniques. The encrypted data then segmented with the help of a replication factor (RF), which results in fixed-size chunks”; Page 851 Figure 1 see Chunks), wherein the target storage area stores the target information (Brooker, Column 10, lines 44-52 “In embodiments where a customer entity connects indirectly or directly to a plurality of storage devices and/or storage nodes, any number of keys may be used to encrypt data stored upon the plurality of devices and/or nodes, although it is generally preferred to keep the quantity and locational diversity of such keys to a minimum, so as to ease tracking of the keys and increase the verifiability of any subsequent request to remove access to the data, as will be discussed below.”), or
a repetitive overwriting policy (Brooker, Column 6, lines 42-46 “the service administration interface 208 may be utilized by users and/or administrators of the virtual data store service 204 to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component 218 of the service policy enforcement component 214”), which overwrites (Column 3, lines 50-51 “deleting and/or overwriting at least a portion of the data stored thereon.”) the target storage area (Brooker, Column 10, lines 62-66 “In some embodiments, the requests are serviced by cryptographically zeroizing, erasing, or otherwise permanently disrupting a cryptographic key required to decrypt the stored data, in all locations in which it is persisted.”) by alternately using at least two different overwriting method as the right-shift operation and the XOR operation (Seema, Page 854 Section 3.2 Secure Data Deletion by Overwriting: “Node storages use these seed values to compute random numbers using LFSR. It applies to secure overwriting operation with the right-shift operation and XOR operation for secure deletion.”), and [[ (Read in light of the instant specification: ¶95, ¶96, ¶0132 example of three-times overwriting).
Brooker does not explicitly teach the third overwriting method is used to perform the last overwriting operation of the target storage area.
Osugi teaches which overwrites the target storage area by alternately using at least two different overwriting methods as the first and second times the overwrite is done (Osugi, ¶44 “As a method of overwriting and erasing, for example, a method of overwriting once with zero data, a method using a random number, or the like may be used. There is a method of overwriting three times in the order of a random number and zero data (referred to as an NSA method).”; ¶87), and performs the last overwriting operation of the target storage area with another overwriting method as the third overwrite in the three times (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the proposed combination using the known three-times overwriting method taught by Osugi as it yields the predictable result of ensuring the erasure of the data using a known method. The proposed combination may incorporate the overwriting methods taught by Seema and Brooker into the three-times overwriting approach as it would ensure that the data is completely erased
Response to Arguments
Applicant's arguments filed July 10, 2026 have been fully considered but they are not persuasive. Please note that the claim mapping has been updated in view of the claim amendments.
The objection to the drawings is hereby withdrawn, support for the newly added drawings has been identified within the specification in Paragraphs [0051]-[0057], [0129], [0133]-[0134] for Steps S21-S27. Support has been found in Paragraphs [0065]-[0070] for S31-S34.
With regard to the prior art applicant argues that Tian does not teach a post-deletion state (S3).
In response, it is noted that Brook teaches extracting a state of the data object. Brook gives example states of ‘pending, occurring, or completed permanent disablement of access’. One of ordinary skill in the art would recognize the status of ‘completed permanent disablement of access’ as being substantially similar to a ‘post-deletion’ state, as it reflects the state of the operation. Brooks doesn’t explicitly teach that the state is reflecting verified deletion, but instead teaches the state reflecting permanent disablement of access. Within the proposed combination, Brooks is modified to have the state status reflect the status of data value X taught by Tain. The data value X taught by Tian is the current state of the input message that is being testing. Meaning that once the input message has been deleted (parallel to the data being marked as permanently disabled in Brook), one of ordinary skill in the art would recognize the current state as being a ‘post-deleted’ state. Tian presents a means of testing the input message to verify that the current state of the input message is indeed deleted.
Applicant’s arguments address only Tian and does not address the proposed combination. To be clear, within the proposed combination Brook teaches the ‘state’, and simply fails to acknowledge when that state may be specifically ‘post-deletion’. The combination with Tian addresses this particular situation.
Applicant argues that Tian fails to teach the “random seed”.
In response, the claimed random seed was mapped to the private key SK taught by Tian. Applicant does not appear to address this claim mapping.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANDA WILLIS whose telephone number is (571)270-7691. The examiner can normally be reached Monday-Friday 8am-2pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ajay Bhatia can be reached at 571-272-3906. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMANDA L WILLIS/ Primary Examiner, Art Unit 2156
Prosecution Insights