DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Final Office Action is in response to the application 18/735,479 filed on 05/07/2026.
Status of Claims:
Claims 1, 6, 10, 15, and 19 are amended in this Office Action.
Claims 2, 4, 11, 13, and 20 are canceled in this Office Action.
Claims 24-25 are new in this Office Action.
Claims 1, 3, 5-10, 12, 14-19, and 21-25 are pending in this Office Action.
Response to Arguments
After closely reviewing the Applicant’s arguments filed in the remarks filed 05/07/2026 (pages 7-10) regarding to claims 1, 10 and 19, the Examiner respectfully submits that the arguments are not persuasive.
Regarding claims 1, 10 and 19:
The applicant argued that the prior arts of record do not teach “wherein the data destruction object is linked to the custom object using a first user interface”. The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Shah discloses “[0047] In alternative embodiments, process 200 allows or enables a user to optionally cancel the pending in step 250. As such, the deletion of the LUN by the storage management controller 120 (step 260) may be configured as automatic or requiring a user to approve the scheduled deletion.”. The system of Shah is directed to deleting data according to a created profile with self-destruction properties. Also, the system incorporates user’s involvement in the deleting process such as cancel or approve the deletion process. Although Shah does not explicitly disclose the term “a first user interface”, one of ordinary skills in the art can understand that user’s interactions such as canceling and approving deletion of data with respective profiles can correspond to a first user interface in an environment with data destruction object and custom object. Therefore, Shah at least teaches “wherein the data destruction object is linked to the custom object using a first user interface”.
The applicant argued that the prior arts of record do not teach “wherein the information lifecycle management object is linked to the data destruction object using a second user interface”. The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Shah discloses “[0045] Once the LUN has been provisioned, the storage management controller 120 creates for the LUN a profile (in respective meta-data structure 170) that includes indications of self-destruction properties (parameter values 172) in step 220. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties (parameter values 172) or may be specified by a user during step 220”. The system of Shah is directed to deleting data according to a created profile with self-destruction properties wherein self-destruction properties of a profile can be specified by a user. Although Shah does not explicitly disclose the term “a second user interface”, one of ordinary skills in the art can understand that user’s interactions with a profile with self-destruction properties that eventually used to execute the deletion process can correspond to a second user interface in an environment with information lifecycle management object and data destruction object. Therefore, Shah at least teaches “wherein the information lifecycle management object is linked to the data destruction object using a second user interface”.
The applicant argued that the prior arts of record do not teach “user interface comprises an audit area, and wherein other information lifecycle management objects having a similar context are displayed within the audit area”. The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Todd discloses “(Fig. 8 & [0111] When a host sends a request to store a CDF on the storage system, the host may indicate a retention class for the unit of data. The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years, and a unit of data in the "Financial Records" class is assigned a retention period of five years. When the storage system receives a request to delete a unit of data, the storage system may first determine which retention class the unit of data is in, and then determine the value of the retention period for that unit of data (e.g., based on record 801). The storage system may then determine if the retention period has expired, and if it has not, deny the deletion request in the manner described above…[0114] In record 801, retention classes are identified by a name, such as "E-mail" or "Financial Records." However, it should be appreciated that retention classes need not be identified by a human-readable name, as any suitable identifier, such as a string of number and/or characters, may be used”. The system of Todd is directed to grouping data with similar characteristics such as class and assign corresponding retention period for each available class. A class of Todd can be equivalent to an audit area wherein data within each class shares similar context such as data’s metadata relating to e-mail or financial records. Therefore, Shah in view of Todd at least teaches “user interface comprises an audit area, and wherein other information lifecycle management objects having a similar context are displayed within the audit area”.
Applicant’s arguments filed on 05/07/2026 (pages 10-11) regarding newly added claims 24 and 25 have been fully considered. However, after further examination, new grounds of rejection are presented necessitated by applicant’s newly added claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 3, 5-10, 12, 14-19, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Shah (US PGPUB 20150127902) “Shah” in view of Todd et al. (US PGPUB 20050160120) “Todd”, Khadiwala et al.(US PGPUB 20180101328) “Khadiwala”, and Fernando et al. (US PGPUB 20190236198) “Fernando”.
Regarding claim 1, Shah teaches a computer-implemented method, comprising: creating a data destruction object linked to a custom object ([0045] Once the LUN (custom object) has been provisioned, the storage management controller creates for the LUN a profile (data destruction object) that includes indications of self-destruction properties... The profile may be associated with one or more LUNs in this step… Examiner’s note: Thus, the created profile can be equivalent to a data destruction object because it can contain information relating to a data destruction and the profile is associated with the corresponding object), wherein the data destruction object is linked to the custom object using a first user interface ([0047] In alternative embodiments, process 200 allows or enables a user to optionally cancel the pending in step 250. As such, the deletion of the LUN by the storage management controller 120 (step 260) may be configured as automatic or requiring a user to approve the scheduled deletion... Examiner’s note: User’s involvements in the deletion process such as approving a deletion can correspond to a first user interface incorporated between data destruction object and the custom object); creating an information lifecycle management object linked to the data destruction object ([0045]: The storage management controller creates for the LUN a profile that includes indications of self-destruction properties (information lifecycle management object). The self-destruction properties include an expiration date for the LUN, preferably according to data contained or to be contained in the LUN... Examiner’s note: Thus, self-destruction properties within a profile is equivalent to the information lifecycle management object linked to the data destruction object), wherein the information lifecycle management object is linked to the data destruction object using a second user interface ([0045] Once the LUN has been provisioned, the storage management controller 120 creates for the LUN a profile that includes indications of self-destruction properties in step 220. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties (parameter values 172) or may be specified by a user… Examiner’s note: A profile that containing self-destruction properties indicating how LUNs are deleted can be specified by a user thus can correspond to a second user interface incorporated between the information lifecycle management object and data destruction object); scheduling a data destruction batch job selecting the data destruction object for destruction ([0046]: The storage management controller monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value of the self-destruction properties of each LUN. If the LUN has a self-destruction date past the current date, the storage management controller 120 marks the LUN as a past-due LUN… [0047]: As such, the deletion of the LUN by the storage management controller 120 may be configured as automatic or requiring a user to approve the scheduled deletion… Examiner’s note: Thus, a deletion on the object can be scheduled automatically or by a user after a determination is made such as objects that have a self-destruction date past the current date); and destroying, based on the scheduling, one or more data of the custom object ([0046]: The storage management controller destroys any marked past-due LUNs by performing a deletion of the LUN. The LUN deletion is preferably one of a secure delete, soft delete, or normal delete.); wherein each of the data destruction object, custom object, the information lifecycle management object, and information lifecycle management object having the similar context comprises data and logic defining a runtime implementation ([0046] In step 240, the storage management controller 120 monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value 172 of the self-destruction properties of each LUN. If the LUN has a self-destruction date 172 past the current date, the storage management controller 120 marks the LUN as a past-due LUN in step 250. In step 260 the storage management controller 120 destroys any marked past-due LUNs by performing a deletion of the LUN. The LUN deletion is preferably one of a secure delete, soft delete, or normal delete. A secure delete involves over-writing the data of the past-due LUN and addressing the physical data locations of the LUN as free space. A normal delete only addresses the physical data locations of the LUN as free space. A soft delete marks the LUN identifier as deleted but allows a user to undo the operation at a later date… Examiner’s note: After the creation and assigning of profiles to LUNs wherein profiles can contain self-destruction parameters, the system can begin the monitoring and marking steps that results in the destroying step. Steps 240 to 260 of fig. 2 can be equivalent to runtime implementation where a data destruction job can be started. During these steps, LUNs, self-destruction parameters of profiles are used to monitor and mark LUNs for destroying jobs and this can be equivalent to data destruction object, custom object, the information lifecycle management object comprising data and logic defining a runtime implementation ) .
Shah does not explicitly teach wherein the second user interface comprises an audit area, and wherein other information lifecycle management objects having a similar context are displayed within the audit area; grouping the information lifecycle management object into an audit area, wherein a data retention policy is created, while in the audit area, for the information lifecycle management object; and verifying the destroy based on a check of a destruction log; wherein information lifecycle management object having the similar context comprises data and logic defining a runtime implementation; and wherein the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object.
Todd teaches user interface comprises an audit area, and wherein other information lifecycle management objects having a similar context are displayed within the audit area; grouping the information lifecycle management object into an audit area, wherein a data retention policy is created, while in the audit area, for the information lifecycle management object (Fig. 8 & [0111] When a host sends a request to store a CDF on the storage system, the host may indicate a retention class (audit area) for the unit of data. The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years (data retention policy), and a unit of data in the "Financial Records" class is assigned a retention period of five years. When the storage system receives a request to delete a unit of data, the storage system may first determine which retention class the unit of data is in, and then determine the value of the retention period for that unit of data (e.g., based on record 801). The storage system may then determine if the retention period has expired, and if it has not, deny the deletion request in the manner described above…[0114] In record 801, retention classes are identified by a name, such as "E-mail" or "Financial Records." However, it should be appreciated that retention classes need not be identified by a human-readable name, as any suitable identifier, such as a string of number and/or characters, may be used… Examiner’s note: Thus, data can be grouped to a class or an area that indicates its corresponding retention period. The class or area can have similar contexts such as data relating to email or financial records); wherein information lifecycle management object having the similar context comprises data and logic defining a runtime implementation ([0111]: The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years, and a unit of data in the "Financial Records" class is assigned a retention period of five years. When the storage system receives a request to delete a unit of data, the storage system may first determine which retention class the unit of data is in, and then determine the value of the retention period for that unit of data (e.g., based on record 801)…Examiner’s note: The system contains retention classes wherein each retention class describe data that share the same context. Each retention class is defined with a retention period that determines when a unit of data in the class can be deleted which can be equivalent data and logic defining a runtime implementation). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Todd teachings in the Shah system. Skilled artisan would have been motivated to incorporate assigning a retention class to data taught by Todd in the Shah system to effectively assign a retention period for the particular data and improves organization of the system by grouping data with similar class characteristics to a corresponding retention period . This close relation between both of the references highly suggests an expectation of success.
Shah in view of Todd does not explicitly teach verifying the destroy based on a check of a destruction log; and wherein the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object.
Khadiwala teaches verifying the destroy based on a check of a destruction log ([0139]: When the intent to delete is in the delete log (destruction log), the method continues to step where the computing device skips the data access request. When the intent to delete is not in the delete log, the method branches back to where the computing device executes the data access request. When the data element is confirmed to be deleted the computing device updates the delete log to remove the intent to delete… Examiner’s note: Thus, the system can verify that a delete or destroy based on a check from a log and the delete or destroy can be confirmed when an intent to delete is removed from the log). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Khadiwala teachings in the Shah and Todd system. Skilled artisan would have been motivated to incorporate verification of destroy operation based on a log taught by Khadiwala in the Shah and Todd system to ensure the destroy/delete process is completed, thus enhances security and reduces risks within the system . This close relation between of the references highly suggests an expectation of success.
Shah in view of Todd and Khadiwala does not explicitly teach wherein the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object.
Fernando teaches the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object ([0018] Accordingly, some implementations of the present disclosure provide an efficient mechanism for performing operations such as a delete operation for records of a data object within a multi-tenant database system. For example, the mechanism may introduce a new delete operation (e.g. method, function, call, class, verb, etc.) to one or more protocols or APIs (Application Programming Interface) used by an application platform of a database system. For example, some implementations may extend the capabilities of SOAP (Simple Object Access Protocol), REST (Representational state transfer), or an application platform specific programming language. In one implementation, the delete operation is configured to allow records to be identified by using a matching technique from information provided to the delete operation. For example, information may be provided in the form of a data structure such as an object that is passed as an argument to the delete operation. In one implementation, the information may specify values related to primary keys or unique record identifiers for the records to be deleted.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Fernando teachings in the Shah and Todd and Khadiwala system. Skilled artisan would have been motivated to incorporate an API in association with a delete operation taught by Fernando in the Shah and Todd and Khadiwala system to enable the automation of tasks and data exchange between different entities, reducing manual intervention, minimizing errors. Also, this leads to increased operational efficiency and cost savings. This close relation between of the references highly suggests an expectation of success.
Regarding claim 3, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein an application using the custom object is deployed in a container, wherein the container further includes the data destruction object and the information lifecycle management object ([0046]: The storage management controller monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value of the self-destruction properties of each LUN. If the LUN has a self-destruction date past the current date, the storage management controller marks the LUN as a past-due LUN… Examiner’s note: Thus, properties or information relating to the object such as self-destruction date and whether the objected is marked for destruction can be determined and attached to the object. The determined properties can be equivalent to data destruction object and the information lifecycle management object of the objects).
Shah in view of Todd does not explicitly teach the custom object is deployed in a container to a destination cloud platform.
Khadiwala teaches custom object is deployed in a container to a destination cloud platform ([0006]: For large services, applications, and/or functions, cloud computing may be performed by multiple cloud computing resources in a distributed manner to improve the response time for completion of the service, application, and/or function. For example, Hadoop is an open source software framework that supports distributed applications enabling application execution by thousands of computers…[0007] In addition to cloud computing, a computer may use “cloud storage” as part of its memory system. As is known, cloud storage enables a user, via its computer, to store files, applications, etc., on an Internet storage system…[0141]: Note that if the processing module, module, processing circuit, and/or processing unit includes more than one processing device, the processing devices may be centrally located (e.g., directly coupled together via a wired and/or wireless bus structure) or may be distributed located (e.g., cloud computing via indirect coupling via a local area network and/or a wide area network)). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Khadiwala teachings in the Shah and Todd and Fernando system. Skilled artisan would have been motivated to incorporate a cloud platform taught by Khadiwala in the Shah and Todd and Fernando system to improve the response time for completion of the service, application, and/or function, as recognized by Khadiwala ([0006]). This close relation between of the references highly suggests an expectation of success.
Regarding claim 5, Shah in view of Todd, Khadiwala, and Ferando teaches all of the limitations of claim 1. Shah further wherein there is a 1-1 mapping between the information lifecycle management object and the data destruction object ( [0045]: The storage management controller creates for the LUN a profile that includes indications of self-destruction properties. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties or may be specified by a user. Preferably the self-destruction properties include an expiration date for the LUN, preferably according to data contained or to be contained in the LUN. Once a profile has been created, the storage management controller 120 associates the profile with the LUN in step… Examiner’s note: Thus, a profile created can include indications of self-destruction properties and expiration date for the LUN and the properties are associated to each other within a profile of an object. Therefore, an equivalent to 1-1 mapping between the information lifecycle management object and the data destruction object can be presented by the profile created).
Regarding claim 6, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein the first user interface comprises an information area in which an indication of data destruction logic associated with the data destruction object is displayed ([0045] Once the LUN has been provisioned, the storage management controller 120 creates for the LUN a profile (in respective meta-data structure 170) that includes indications of self-destruction properties (parameter values 172) in step 220. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties (parameter values 172) or may be specified by a user during step 220. Preferably the self-destruction properties include an expiration date for the LUN, preferably according to data contained or to be contained in the LUN… Examiner’s note: Self-destruction properties in a profile can correspond to data destruction logic associated with the data destruction object).
Regarding claim 7, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah does not explicitly teach wherein the similar context comprises a financial audit area, a tax audit area, or a human resource audit.
Todd teaches wherein the similar context comprises a financial audit area, a tax audit area, or a human resource audit (Fig. 8 & [0111]: When a host sends a request to store a CDF on the storage system, the host may indicate a retention class (area) for the unit of data. The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years, and a unit of data in the "Financial Records" class (a financial audit area) is assigned a retention period of five years… Examiner’s note: Thus, the similar context can include at least a financial audit area). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Todd teachings in the Shah, Khadiwala, and Fernando system. Skilled artisan would have been motivated to incorporate determining specific classes or areas taught by Todd in the Shah, Khadiwala, and Fernando system to increase efficiency in determining a retention period for an object thus improves the organization and performance of the system. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 8, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein the data retention policy is created, while in the audit area, for the information lifecycle management object using a fourth user interface ([0035] The client may be a general-purpose computer configured to execute applications. Moreover, the client may interact with the storage controller in accordance with a client/server model of information delivery. That is, the client may request the services of the storage controller, and the system may return the results of the services requested by the client, by exchanging packets over the network... Examiner’s note: Thus the system provides an interface for a user such as application to communicate with the controller to request the services of the storage controller).
Regarding claim 9, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 8. Shah further teaches wherein the data retention policy specifies at least a time when the destroying can occur ([0045]: Preferably the self-destruction properties include an expiration date (a time when the destroying can occur) for the LUN, preferably according to data contained or to be contained in the LUN… [0046]: The storage management controller monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value of the self-destruction properties of each LUN. If the LUN has a self-destruction date past the current date, the storage management controller marks the LUN as a past-due LUN. The storage management controller destroys any marked past-due LUNs by performing a deletion of the LUN).
Regarding claim 10, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 12, note the rejections of claim 3. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 14, note the rejections of claim 5. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 15, note the rejections of claim 6. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 16, note the rejections of claim 7. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 17, note the rejections of claim 8. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 18, note the rejections of claim 9. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 19, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 21, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah in view of Todd does not explicitly teach wherein calling the API at runtime to initiate the data destruction of the data destruction object further initiates creation of the destruction log for monitoring the destroy.
Khadiwala teaches initiates creation of the destruction log for monitoring the destroy ([0124] When determining to queue the delete slice requests, the processing module 84 updates a delete log 474 within the memory 88 to include the delete slice request. For example, the processing module 84 adds the slice name and the revision level to a list of encoded data slices for deletion within the delete log 474… [0127] When the other encoded data slice is probably deleted, the processing module 84 verifies deletion. As a specific example of the verification, the processing module 84 accesses the delete log 474 and indicates that the other encoded data slice has been deleted when the other revision level and other slice name combination is not present…Examiner’s note: A destruction log or delete log is utilized as part of a deletion process to monitor the destroy or deletion process). Please refer to claim 1 for the motivational statement.
Regarding claim 22, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah in view of Todd does not explicitly teach wherein calling the API at runtime to initiate the data destruction of the data destruction object further enables persistent storage of data destruction metadata.
Khadiwala teaches enables persistent storage of data destruction metadata ([0124]: The processing module 84 updates a delete log 474 within the memory 88 to include the delete slice request…[0141]: Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Khadiwala teachings in the Shah and Todd system. Skilled artisan would have been motivated to incorporate storing data or metadata in persistent storage taught by Khadiwala in the Shah and Todd system to provide long-term data durability and enhances data integrity. This close relation between of the references highly suggests an expectation of success.
Regarding claim 22, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein calling the API at
runtime to initiate the data destruction of the data destruction object further initiates performance of a data retention check for the information lifecycle management object ([0046] In step 240, the storage management controller 120 monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value 172 of the self-destruction properties of each LUN. If the LUN has a self-destruction date 172 past the current date, the storage management controller 120 marks the LUN as a past-due LUN in step 250. In step 260 the storage management controller 120 destroys any marked past-due LUNs by performing a deletion of the LUN. The LUN deletion is preferably one of a secure delete, soft delete, or normal delete).
Regarding claim 24, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 8. Shah further teaches wherein the data retention policy specifies an event in response to which the destroying occurs immediately ([0029]: The storage controller monitors the LUNs at a given frequency and updates the last access date of the LUN if necessary. The storage controller flags (or marks) for deletion any LUNs having a past-due self-destruction parameter and optionally notifies a user, client, or the data handling system of the pending LUN deletion. The storage controller can immediately delete the past-due LUN or wait a predetermined period of time to allow a user to respond, or hold the delete indefinitely until a user permits the pending deletion... Examiner’s note: The system monitors the LUNs and detect events such as past-due self-destruction and immediately delete the past-due LUN).
Claims 25 are rejected under 35 U.S.C. 103 as being unpatentable over Shah (US PGPUB 20150127902) “Shah” in view of Todd et al. (US PGPUB 20050160120) “Todd”, Khadiwala et al.(US PGPUB 20180101328) “Khadiwala”, and Fernando et al. (US PGPUB 20190236198) “Fernando” and Bhaskara et al. (US PGPUB 20190057218) “Bhaskara”.
Regarding claim 25, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 24. Shah in view of Todd, Khadiwala, and Fernando does not explicitly teach wherein the event comprises termination of an employee associated with the data destruction object.
Bhaskara teaches the event comprises termination of an employee associated with the data destruction object ([0028] FIG. 1 shows an example of a system 100 where data retention is provided as a service. Data retention is an example of a DPP compliance requirement. For example, when a person's data is stored in the system 100 it may be necessary to archive and/or delete the data after a specified amount of time. For example, the time can be triggered by an event, including, but not limited to, that the employee retires from the organization or is terminated). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Bhaskara teachings in the Shah in view of Todd, Khadiwala, and Fernando system. Skilled artisan would have been motivated to incorporate data destruction based on employee retires from the organization or is terminated taught by Bhaskara in the Shah in view of Todd, Khadiwala, and Fernando system to reduce unwanted data, thus can improve storage space and reduce the cost of the system. This close relation between of the references highly suggests an expectation of success.
Prior Art
The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure. See form PTO-892.
Kim et al. (US PGPUB 20200350074) is directed to deletion date information includes information indicating when the message or data structure is “deleted” because the user has left the company (e.g., the employee resigns, retires, or is terminated). Deletion in this context means that the message or data structure is made unavailable to the selected recipients, that the message or data structure is still available to the selected recipients but their emotion selections are not considered in the group-wide or company-wide aggregation data, or that the message or data structure is made unavailable to the selected recipients and the emotion selections are not considered in the group-wide or company-wide aggregation data. The processing system may achieve “deletion” by moving the messages or data structures of the former employee to a separate location that is not accessible by the data structures. Deletion date may indicate the time on which those the messages or data structures are put into that location.
Chaiken et al. (US PGPUB 20210240490) is directed to ability to control unauthorized access to data or render at least a portion of the portable computing system unusable in certain situations such as when the portable computing system is misplaced, lost, or stolen is important. Other situations that may prompt an owner of the portable computing system to at least restrict access to the portable computing system or a portion thereof may include an employer terminating an employee, a parent restricting access of a child, etc. handling system allow for remotely securing the information handling system by applying one or more security features to limit access or render one or more components of the information handling system unusable. The system and method of the current disclosure may also download the data in the information handling system or forensically destroy the data, encrypt the data, and/or render the data inaccessible. These security features may be applied to the compromised information handling system without deploying an agent or initial setup to the information handling system prior to the it being compromised.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAO DANG VUONG whose telephone number is (571)272-1812. The examiner can normally be reached on M-F 7:30-5 EST.
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, Kavita Stanley can be reached at (571) 272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.D.V./Examiner, Art Unit 2153 07/15/2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights